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.

DP83826E: DP83826E

Part Number: DP83826E

Hi,

We have this design based on DP83826ERHBT

Hardware side :

Schematic:

Ethernet - DP83826E.pdf

Layout: RMII trace length

We have termination resistors on RMII line 

Can you advice if we have any Layout problems  ?

All line 50 ohm control impedance

Traces length are in picture above 

Software side :

We did some test on our board

We did loopback between PHY to PC  -- Works very well under load test

We did loopback between MAC TO PHY -- we have lose packet

We are experiencing an issue with the DP83826 connected to the Xilinx zc7000 series(7030).

It appears that not all received packets (Rx packets) are being captured by the MAC.

To rule out any cable-related problems, I have disconnected Ethernet cables and placed the PHY into digital loopback mode (0x16=0x104).

Even in this configuration, I am still encountering data loss. As a validation test, I put the MAC into loopback mode itself, and my tester successfully recognizes all the data.

 

The occurrence of data loss does not follow a consistent pattern in terms of the amount of data sent before the receiving stops.

It can happen after one second or even after a few minutes. After ignoring any incoming data for a few minutes, it starts receiving again until the next receiving break.

 

Interestingly, I observe the same behavior when the Ethernet link is fully established. The MAC receives a few packets, then pauses the receiving process (while it still sending data) for a period of time,

and eventually resumes receiving.

 

I have also conducted a loopback test with 10M and half-duplex settings, but the results remain consistent.

 

I have attached the MII registers for your reference. However, I don't believe this is the root cause of the issue since the channel is functional approximately 60% of the time.

I doubt that the MII settings are responsible for this behavior.

Moreover, the problem appear also with the Linux driver (u-boot,kernel) provided by TI

Attached Registers Dump 

Zynq> mii read 1 0
2100
Zynq> mii read 1 1
7849
Zynq> mii read 1 2
2000
Zynq> mii read 1 3
A111
Zynq> mii read 1 4
00A1
Zynq> mii read 1 5
0000
Zynq> mii read 1 6
0004
Zynq> mii read 1 7
2001
Zynq> mii read 1 8
0000
Zynq> mii read 1 9
0000
Zynq> mii read 1 a
0102
Zynq> mii read 1 b
0009
Zynq> mii read 1 c
0000
Zynq> mii read 1 d
0000
Zynq> mii read 1 e
0000
Zynq> mii read 1 10
1205
Zynq> mii read 1 11
010B
Zynq> mii read 1 12
7800
Zynq> mii read 1 13
0A00
Zynq> mii read 1 14
0000
Zynq> mii read 1 15
0000
Zynq> mii read 1 16
0108
Zynq> mii read 1 17
0041
Zynq> mii read 1 18
0400
Zynq> mii read 1 19
8401
Zynq> mii read 1 1a
0010
Zynq> mii read 1 1b
007D
Zynq> mii read 1 1c
05EE
Zynq> mii read 1 1d
0000
Zynq> mii read 1 1e
0102

 

  • Hi Meri,

    Regarding to your schematic and layout concern, we do have schematic and layout checklist which I attached below. Please take a look if you have some concern:

    0882.DP83826_Schematic_Design_Review_Checklist.xlsx8765.IndustrialPHY_Layout Review Checklist.xlsx

    Regarding to your concern of package loss on digital loopback, May I ask couple questions:

    • Which MAC interface are you using? (MII or RMII)
    • For digital loopback, did you configure the following script?
    • If your configuration is right, could you do a MII loopback to see rather you are still see packet loss?

    --

    Thank you,

    Hillman Lin

  • Hi Hillman,

    Thanks for your fast response 

    We did your suggestion (MII loopback) - but we got same results

    Lose of some of the packet  - part of packet are correct  and some of them corrupted   

    Any other ideas ? 

    How we can set  pins RX_ERR and TX_ERR to function as error indication   if there is corrupted   packet  ?

    Thanks in advance,

    Meir

  • Hi Meir,

    It seems to be some layout routing issue between MII/RMII interface. 

    • May I ask are you using RMII interface?
    • Could you check the length, length matching, impedance matching of the MAC interface on your layout?
    • Could you also check the clock signal of the PHY on the CLK_OUT pin?
    • Could you also probe and double check the MII interface to see rather it meet VOD, VID, VOH, VIH specification

    --

    Regards,

    Hillman Lin

  • Hi Hillman Lin,

    • We are working in MII, Basic Mode  
    • The line are 50 ohm impedance control
    • Trace length are as this picture blow

    PYH to Termination resistor      length of the traces    70mil to 236mil

    Termination to MAC    length of the traces  2549mil to 2686mil

     PHY on the CLK_OUT 

    When there is packet broadcasting  the pin 31 is "1"

    When there is no packet broadcasting  the pin 31 is "0"

    Q :  VOD, VID, VOH, VIH specification

    RX_CLK

    TX_CLK

    Probe on Termination Resistor

    TXD[0] :

     

    RXD[0]:

    Is there any more suggestion how to figure out what wrong ?

    Many thanks,

    Meir

  • Hi Hillman Lin,

    • We are working in MII, Basic Mode  
    • The line are 50 ohm impedance control
    • Trace length are as this picture blow

    PYH to Termination resistor      length of the traces    70mil to 236mil

    Termination to MAC    length of the traces  2549mil to 2686mil

     PHY on the CLK_OUT 

    When there is packet broadcasting  the pin 31 is "1"

    When there is no packet broadcasting  the pin 31 is "0"

    Q :  VOD, VID, VOH, VIH specification

    RX_CLK

    TX_CLK

    Probe on Termination Resistor

    TXD[0] :

     

    RXD[0]:

    Is there any more suggestion how to figure out what wrong ?

    Many thanks,

    Meir

    HI Hillman Lin,

    Do have any suggestion or solution for our problem ?

     

    Meir

  • Hi Meir,

    The MAC interface can be validated using IBIS simulation. It is strange, however, that communication will fully stop and resume at random points in time. This makes me think link may be dropping. Is the register dump you shared during a time of good communication or bad communication? Can you please take another register dump so we can compare good vs bad side by side? Please include registers 0x467 and 0x468 in the register dump so we can check the strapping.

    Please also share the full schematic in pdf form. 

    Thanks,

    David

  • Hi David,

    Test scenario:

    We trying to ping  and read in the same time   PHY registers -- dump all the registers 

    in the log there 50 dump's of all the registers 

    1016.teraterm.log

    Good Communication 

    Bad Communication 

    In the log  (Good communication and Bad communication)

    REG 0x467: 0x87
    REG 0x468: 0x185

    Schematic 

    7635.Ethernet - DP83826E.pdf

    RMII Trace length

    If you can review those trace length.

    Another issue when We connect scope probe to see waveform of the signals sometime it improve  the statistics of the ping request 

    Can we add delay from DP83826  to RX_CLK TX_CLK ?

    Maybe we have layout issue  - how we can troubleshot it ?

    Many thanks for help,

    Meir

  • Hi Meir,

    • From the register read on 0x467, we can see that your PHY is always operate in MII mode so it is not the strapping issue on the PHY side.
    • From the layout length match, we do see the difference between TX_CLK to TX_D3 and TX_D2 are more then 100mil that might result in some communication problems in the MAC interface.
    • Your TX_CLK and Data also seem to be distorted. May I ask where did you probe the signal for both RX and TX. Is it near the PHY or the MAC side?
    • How much packets loss are you receiving on MII communication?
    • Did you have a solid ground separation for the MII communication?
    • We do not have any skew option for the MII communication through register read and write. Unfortunately, Changing layout would be the option to improve the MAC communication.
    • We do have Appnote and Layout checklist for the MAC interface. Hopefully would help:

    IndustrialPHY_Layout Review Checklist (1).xlsx

    --

    Thank you,

    Hillman Lin

  • Hi Hillman Lin,

    • The termination are near the PHY and we probe them on PHY side.

    • Most of the time when we probe the RX_CLK  there was start of good series of PING's.

    Sometime probing TX_CLK also improve the PING's (less than RX_CLK) but nothing consistently and continuously. (very strange behavior..)

    • We did some Loopback test 

    PHY to PC  working very well under load test 

    MAC --> PHY --> PC    working well

    it seems that we have problem from PHY to MAC

    • 40% to 70% packet loss

    • MII Signals are in layer 4 -- We have  solid GND from top Layer 3 and from Bottom  Layer 5 closed both sides.

    • In that situation  PCB Layout  can we add some 20pF cap on line to make RX_CLK and TX_CLK slower than RXD[0..3]  TXD[0..3]   ??

    • In the next revision of the PCB  we need to make TX_CLK RX_CLK to be longer trace  than the data line RXD[0..3]  TXD[0..3]  ?

    or just match them in 100 mil  (TX_CLK & RX_CLK   trace are the longest in the group)

    • Attached our Layout review

    please check it

    SLVRBN4_DP83826_Schematic_Design_Review_Checklist_08062023.xlsx

    Thanks for help,

    Meir

  • Hi Meir,

    • Are you able to probe the RX_CLK traces near the connector side to see is there any distortion like you probed in TX_CLK traces?
    • Could you also double check to make sure RX and TX vias are not close to any other signal vias?
    • In your schematic review, you said Rbias is 10mV. Have you check the Rbias Resistor is actually 6.49ohms with 1% tolerance?

    --

    Regards,

    Hillman Lin