This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83822I: Frame drop on the RGMII interface to/from AM5708

Part Number: DP83822I
Other Parts Discussed in Thread: AM5708, AM5728

All,

Currently I am integrating a DP83822i Phy which is connected by means of a RGMII interface to a AM5708.
During our bringup the PHY is there but apparently there seems to be packet/frame drop causing timeouts on our network interface.
Besides this I see that that on certain systems the Phy is having difficulty to maintain it's link or even to get a link (It might be we have two issues).

In order to differentiate the issues, I a have tried to pinpoint the issue to a specific interface, therefore I have created a test which is sending raw packets of 60 bytes which are being received and accounted for, when missed the test application counts the number of missing frame.

Using the guidelines available within the "DP83822 IEEE 802.3u Compliance and Debug manual" (snla266), I have made use of several loopbacks where running these tests:

- Using an external ethernet loopback,  I encounter frame drop about 1,2 %

- Using an MII loopback, I still encounter frame drop of about 0,12 %

- In order to rule out the PHY/ethernet side I have also used the PHY-reverse loopback, where my connected PC is perfroming the same test application, here I see no frame drop

For me this seems to point to RGMII interface or earlier in the chain (GMAC_SW).

My question is whether there is a procedure to analyse and debug the RGMII interface and or GMAC and to know which registers or measurements are relevant to take into account.

Below I have copied a snapshot of the PHY-s registers (Here a PC is connected) where you clearly see an  error count on the receive side (0x15,RECR) is increasing.

0x0000 0x00003100
0x0001 0x0000786d
0x0002 0x00002000
0x0003 0x0000a240
0x0004 0x000001e1
0x0005 0x0000cde1
0x0006 0x0000000d
0x0007 0x00002001
0x0008 0x00004141
0x0009 0x00000000
0x000a 0x00000100
0x000b 0x00001000
0x000c 0x00000000
0x000d 0x00000000
0x000e 0x00000000
0x000f 0x00000000
0x0010 0x00002c15
0x0011 0x00000108
0x0012 0x00008200
0x0013 0x00000000
0x0014 0x000000ff
0x0015 0x00000180
0x0016 0x00000100
0x0017 0x00000249
0x0018 0x00000400
0x0019 0x00008c01
0x001a 0x00000000
0x001b 0x0000007d
0x001c 0x000005ee
0x001d 0x00000000
0x001e 0x00000102
0x001f 0x00000000

Any help with this issue would be appreciated.

With many thanks,

Patrick Klok

  • Hi Patrick,

    Is there any way you can provide a schematic as well?
    Thank you for attaching the register dump! Where do you want to implement the clock delay for RGMII interface?
    Do you want delay included within the MAC or the PHY? How you currently have it is delay for transmit path but not the receive path.

    Do you mind providing a screen capture of the setup/hold time at the TX pins of the PHY and at the RX pins of the MAC?
    Can you also probe the XI pin and show me the reference clock? I am curious if this is a crystal stability issue.

    Best regards,
    Ross
  • Hi Patrick,

    I just reviewed your schematic and waveforms.
    Please populate the pull-down on LED_1. This is a requirement for LED pins (it is not related to the RGMII though).

    The schematic looks good to me, however, can you please change the series termination resistors on your board to 0 ohm and re-take the waveform images?

    Also, do you have the ability to enable internal delay within your AM5728?

    Best regards,
    Ross
  • Hi Ross,

    Thank you for your suggestion.

    We have replaced the resistors on the receive path to 0 Ohm, the 20/80 timing seems to slightly increase the rise time, nevertheless it is now around 1.95 ns, where we see some reflection.

    On the receiving side I still have the same amount of frames being dropped.

    Tomorrow we will modify the receive delay. I will keep you up to date.

    Many thanks,

    Patrick Klok