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.

DP83867CR: DP83867 packet loss issue on Agilex platform...

Part Number: DP83867CR

Tool/software:

Hi TEAM,

customer found the DP83867 packet loss issue and did some test.

The connector of RJ45 they used is 8207S-81000075-1 including the  transformers

1. test FPGA MAC and DP83867CR MII lookpack and digital loopback, no packet loss. It seems not RGMII issue for packet loss

2. connect using 2pcs DP83867CR board, and set reverse loopback mode for 1 board, no packet loss issue occurred.

3. Bridge 2pcs DP83867 boards with TP-Link TL-SG108 (1G Switch), it works fine

4. Bridge 2pcs DP83867 boards with ZYXEL XGS1250-12 (Multi-Gig Switch) or TP-Link TL-SG108-M2 (2.5G Switch), there was around 0.5% packet loss

check related registers for the above connection test, the loop quality is around 40~90

It seems that packet loss occurs when connected to specific Multi-Gigabit switches (ZYXEL XGS1250-12, TP-Link TL-SG108-M2), but is normal when tested with a standard 1G switch (TP-Link TL-SG108) or PHY Direct Loopback/Reverse Loopback, does the DP83867CR have specific register configurations, known compatibility issues, or recommended debugging directions?

Please help!

Thanks.

  • Hi,

    For the Bridge 2pcs DP83867 boards with ZYXEL XGS1250-12 (Multi-Gig Switch) or TP-Link TL-SG108-M2 (2.5G Switch), there was around 0.5% packet loss, 

    • Can you please share a picture of the overall connection?
    • If you enable DP83867 reverse loopback, are you seeing any packet loss?
    • Can you also share the register dump from 0x00 to 0x1F between the Multi-Gig Switch and the 1G Switch? 
    • Can you also measure the CLK_OUT frequency between the Multi-Gig Switch and the 1G Switch?

    Can you also try the two scripts in section 3.1 and 3.2 of this app note and see if it is able to resolve the packet drop issue?

    Thanks

    David

  • Hi David,

    Thanks for your questions! Here's what we found in our tests and the info you asked for:

    Our test setup: one DP83867 board is configured as a reverse loopback fixture, and the other acts as the DUT for testing.

    1. Here's the overall connection diagram.

    2. When the reverse loopback fixture is connected directly to the DUT, we didn't see any packet loss.

    3. The register dumps are attached:

      • TL-SG108-M2.txt (Multi-Gig Switch)
      • TL-SG108.txt (1G Switch)
    4. Our current schematic doesn't have a test point for DP83867 CLK_OUT, so we'll get a DP83867ERGZ EVM to take those measurements.

    5. The scripts from app note sections 3.1 and 3.2 fixed the packet loss issue for the ZYXEL XGS1250-12. However, there was no improvement observed for the TP-Link TL-SG108-M2.

    Let me know if you have any more questions!

    Jim

    After Link-up
    Value at register 0x0000 : 0x1140
    Value at register 0x0001 : 0x796d
    Value at register 0x0002 : 0x2000
    Value at register 0x0003 : 0xa231
    Value at register 0x0004 : 0x01e1
    Value at register 0x0005 : 0xc5e1
    Value at register 0x0006 : 0x006f
    Value at register 0x0007 : 0x2001
    Value at register 0x0008 : 0x6801
    Value at register 0x0009 : 0x0300
    Value at register 0x000a : 0x3800
    Value at register 0x000b : 0x0000
    Value at register 0x000c : 0x0000
    Value at register 0x000d : 0x401f
    Value at register 0x000e : 0x0045
    Value at register 0x000f : 0x3000
    Value at register 0x0010 : 0x5048
    Value at register 0x0011 : 0xac02
    Value at register 0x0012 : 0x0000
    Value at register 0x0013 : 0x1c40
    Value at register 0x0014 : 0x29c7
    Value at register 0x0015 : 0x0000
    Value at register 0x0016 : 0x0000
    Value at register 0x0017 : 0x0040
    Value at register 0x0018 : 0x6150
    Value at register 0x0019 : 0x4444
    Value at register 0x001a : 0x0002
    Value at register 0x001b : 0x0000
    Value at register 0x001c : 0x0000
    Value at register 0x001d : 0x0000
    Value at register 0x001e : 0x0002
    Value at register 0x001f : 0x0000
    
    After transmitting 100,000 packets
    Value at register 0x0000 : 0x1140
    Value at register 0x0001 : 0x796d
    Value at register 0x0002 : 0x2000
    Value at register 0x0003 : 0xa231
    Value at register 0x0004 : 0x01e1
    Value at register 0x0005 : 0xc5e1
    Value at register 0x0006 : 0x006d
    Value at register 0x0007 : 0x2001
    Value at register 0x0008 : 0x6801
    Value at register 0x0009 : 0x0300
    Value at register 0x000a : 0x3800
    Value at register 0x000b : 0x0000
    Value at register 0x000c : 0x0000
    Value at register 0x000d : 0x401f
    Value at register 0x000e : 0x0044
    Value at register 0x000f : 0x3000
    Value at register 0x0010 : 0x5048
    Value at register 0x0011 : 0xac02
    Value at register 0x0012 : 0x0000
    Value at register 0x0013 : 0x0000
    Value at register 0x0014 : 0x29c7
    Value at register 0x0015 : 0x0000
    Value at register 0x0016 : 0x0000
    Value at register 0x0017 : 0x0040
    Value at register 0x0018 : 0x6150
    Value at register 0x0019 : 0x4444
    Value at register 0x001a : 0x0002
    Value at register 0x001b : 0x0000
    Value at register 0x001c : 0x0000
    Value at register 0x001d : 0x0000
    Value at register 0x001e : 0x0002
    Value at register 0x001f : 0x0000
    
    After Link-up
    Value at register 0x0000 : 0x1140
    Value at register 0x0001 : 0x796d
    Value at register 0x0002 : 0x2000
    Value at register 0x0003 : 0xa231
    Value at register 0x0004 : 0x01e1
    Value at register 0x0005 : 0xcd81
    Value at register 0x0006 : 0x006f
    Value at register 0x0007 : 0x2001
    Value at register 0x0008 : 0x6001
    Value at register 0x0009 : 0x0300
    Value at register 0x000a : 0x3800
    Value at register 0x000b : 0x0000
    Value at register 0x000c : 0x0000
    Value at register 0x000d : 0x401f
    Value at register 0x000e : 0x0038
    Value at register 0x000f : 0x3000
    Value at register 0x0010 : 0x5048
    Value at register 0x0011 : 0xaf02
    Value at register 0x0012 : 0x0000
    Value at register 0x0013 : 0x1c40
    Value at register 0x0014 : 0x29c7
    Value at register 0x0015 : 0x0000
    Value at register 0x0016 : 0x0000
    Value at register 0x0017 : 0x0040
    Value at register 0x0018 : 0x6150
    Value at register 0x0019 : 0x4444
    Value at register 0x001a : 0x0002
    Value at register 0x001b : 0x0000
    Value at register 0x001c : 0x0000
    Value at register 0x001d : 0x0000
    Value at register 0x001e : 0x0002
    Value at register 0x001f : 0x0000
    
    After transmitting 100,000 packets
    Value at register 0x0000 : 0x1140
    Value at register 0x0001 : 0x796d
    Value at register 0x0002 : 0x2000
    Value at register 0x0003 : 0xa231
    Value at register 0x0004 : 0x01e1
    Value at register 0x0005 : 0xcd81
    Value at register 0x0006 : 0x006d
    Value at register 0x0007 : 0x2001
    Value at register 0x0008 : 0x6001
    Value at register 0x0009 : 0x0300
    Value at register 0x000a : 0x38ff
    Value at register 0x000b : 0x0000
    Value at register 0x000c : 0x0000
    Value at register 0x000d : 0x401f
    Value at register 0x000e : 0x0037
    Value at register 0x000f : 0x3000
    Value at register 0x0010 : 0x5048
    Value at register 0x0011 : 0xaf02
    Value at register 0x0012 : 0x0000
    Value at register 0x0013 : 0x0100
    Value at register 0x0014 : 0x29c7
    Value at register 0x0015 : 0x009c
    Value at register 0x0016 : 0x0000
    Value at register 0x0017 : 0x0040
    Value at register 0x0018 : 0x6150
    Value at register 0x0019 : 0x4444
    Value at register 0x001a : 0x0002
    Value at register 0x001b : 0x0000
    Value at register 0x001c : 0x0000
    Value at register 0x001d : 0x0000
    Value at register 0x001e : 0x0002
    Value at register 0x001f : 0x0000
    

  • Jim

    With the TP-Link TL-SG108-M2 switch, are you not seeing any packet loss improvement with both scripts? Is it possible that you can try with a 35m, 45m, or 50m Ethernet cable, do you see the packet loss gets worse or better with the longer cable? 

    Also, can you write to register 0x53 bit [3:0] to change the inter-packet gap and see if it solves the packet loss issue? Please note register 0x53 is an extended register and you have to use extended register access to write to this register.

    Thanks

    David

  • Hi David:


    Thanks for following up! Regarding the TP-Link TL-SG108-M2, we have some further test results for you:

    1. The script from Section 3.1 definitely helped, reducing packet loss from 0.6% down to 0.15%.
    2. However, the script from Section 3.2 didn't show any improvement.
    3. For your cable length question, comparing a 15m Ethernet cable to a 0.5m one, the packet loss increased by roughly 0.03% to 0.09%.
    4. We also tried tweaking the inter-packet gap at register 0x53. After changing it from the default 0x5 to 0x4, packet loss dropped from 0.69% to 0.18%. Just a heads-up, this setting is actually included in the Section 3.1 script, so the results are quite similar.

    You can find the detailed test logs in the attached file: packets_loss_20250612.xlsx.

    Hope this helps! Let me know if you have any more questions.

    Jim

    packets_loss_20250612.xlsx

  • Additionally, customer like to confirm whether it’s mandatory to use an RJ45 connector with 2% Turns Ratio tolerance for this application. We’re currently using a 5% tolerance connector (please refer to the attached datasheet for more details), and it has been quite challenging to source a pin-to-pin replacement with 2% tolerance.

    If the 2% tolerance is indeed a critical requirement, we would need to redesign the PCB layout to accommodate a compatible connector. In addition to the extra time needed for redesign and revalidation, the higher cost of the 2% connector is also a concern for us.

  • Jim

    Can you change the inter-packet gap to a value of 0x3, basically write 0x2053 to register 0x53 and if it improves the packet loss? 

    Bonnie

    We have only characterized our PHY with a 2% tolerance transformer, so I can't honestly say what the impact will be with a 5% tolerance transformer. But the specified turn ratio helps ensure our PHY can communicate correctly with the link partner. Using a different ratio can affect compatibility, potentially leading to performance issues including packet loss. I would recommend to use our EVM first with this TP-Link TL-SG108-M2 switch and see if the packet loss issue can be observed. If not, then change the 5% transformer to the 2% transform on this design and see if the packet loss issue can be repeated.

    Thanks

    David  

  • Hi David,

    Thanks for your suggestion! We've tested with an inter-packet gap of 0x3, and here are the results:

    After changing the inter-packet gap to 0x3, the packet loss rate on the TP-Link TL-SG108-M2 significantly improved, dropping to below 0.0001%! However, the datasheet doesn't explain the meaning of the 0x3 value. Do you happen to have any more detailed information on this?

    Regarding the EVM test, we expect to receive the EVM next week. We'll then compare the EVM's performance with our current board to analyze if the compatibility issue is caused by the 5% tolerance transformer.

    Thanks again for your help!

    Jim

  • Jim

    It is good news that you are seeing the packet loss drop to below 0.0001% with Inter Packet Gap(IPG) set to 3. With packet loss drop to below 0.0001%, is this an acceptable solution?

    The Inter Packet Gap refers to the minimum time allowed between the transmission of Ethernet frames. DP83867 supports the expected 12 byte IPG at the MDI as well as lower amounts in some conditions. This number comes from IEEE802.3 section 4.4.2 which sets out that the minimum IPG for a transmitted frame is 12 bytes on the TX lines of the MAC. When the data comes to a PHY, there is a handoff of clocking domains and thus there is potential for IPG to be 11 bytes when sent on MDI line. In cases where the IPG is smaller, Reg 0x53[3:0] can help increase margin in these applications with no drawback on performance. The lowest that this can be set is to 0x3 (default is 0x5) which has been seen to support 11 IPG. 

    What this tells me is that the switch is too aggressive, it is transmitting with a smaller interpacket gap to achieve higher data transfer rates which can lead to packet loss. Is there a way you can lower the switch data transfer rate?

    Thanks

    David