• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1391 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DP83TC811R-Q1: Tx Errors and Limited Tx Throughput

Steve Patterson
Intellectual 570 points
Part Number: DP83TC811R-Q1
Other Parts Discussed in Thread: DP83TC811S-Q1

We're testing this 100BaseT1 PHY using Linux iperf3 to verify the link robustness and throughput.  But we're getting a packet error rate of around 1.5% average (.5 to 3% over test runs) in the transmit direction.  Note that some of the 80 packet groups get thru error-free, where most have 1-15% error rate (which I assume means bad packet rate).  Also, the throughput is 41.7M bps average and surprisingly consistent. The 1% error rate doesn't line up with a less than 50% throughput, but there may be some mechanism in iperf3 that causes this mismatch.  

On the receive side the link runs error-free and at >90M bps.  

The MAC is in an Artik-7 module and we've eliminated all external devices and cables by testing different configurations and far-end devices.  The actual command we're using is: iperf3 -u -c 192.168.3.100 -b 100M -l 63k -t 60.  So far we've tried the following:

  • Varied the link impedance control from 34 to 70 ohms, with no noticeable difference.
  • Varied the RGMII Tx Clock delay over 0 to 4ns, with no noticeable difference.
  • The RGMII Rx Clock delay was very particular and the link does not run at all if this is not set to a specific value.  We believe this is not related to the Tx problem.

Has anyone seen similar problems and/or have further suggestions?

  • 0
    TI__Mastermind 23675 points
    Hi Steve,

    Please send me the schematic and layout.
    Also, please send me the driver you are using for the 811 (if you are using one).

    Can you provide scope shots of the RGMII? I want to see the setup/hold for RX in relation to RX_CLK and same for TX side.
  • 0 in reply to Ross Pimentel
    Intellectual 570 points

    DP83TC811R Schematic Excerpts.pdfRoss,  Thanks for following up.  We're using a generic driver in Linux, with modifications specific to the 811.  Let me know if you want more details and I'll get source code from SW.

    I've attached schematic excerpts, which hopefully you can follow.  The PHY is on a board with the Artik-7, and the analog IF is on another board very near by, connected thru a SamTec high-speed connector (not shown) and then to an external connector (also not shown).

    I'll work on scope shots, but it may take a few days.

    Note that all the built-in link diags indicate that the link is very healthy, so our suspicions are currently on the RGMII, register values, or internal PHY issues.  iperf3 runs error free near 1G bps on the Artik-7 with a 1GE interface instead of the 100BaseT1.

    One detail I forgot to include is that we're using the RadMoon converter which actually runs Broad-Reach instead of 100BaseT1.  I have read that they're almost identical, but are there any issues with inter-operatability?

  • 0 in reply to Steve Patterson
    TI__Mastermind 23675 points
    Hi Steve,

    The DP83TC811R-Q1 and the DP83TC811S-Q1 are fully interoperable with other certified 100BASE-T1 PHYs.
    It is also interoperable with a BroadR-Reach PHY. They are essentially identical, except for a few differences, which don't cause interoperability issues. We have RadMoon here and have verified that the 811 has no issues at 100% utilization with it.

    The 811 has been verified at UNH, C&S and FTZ for conformance to IEEE802.3bw, interoperability with other PHYs, and EMI/EMC conformance to the OPEN Alliance standards.

    If you see a stable link on the MDI, the issue is certainly on the RGMII. It might be a timing issue.
    Are you implementing any internal delay in the Artik-7? Are there any internal pull resistors in the Artik-7 on the receive path?
    The reason why I ask is that the 811 has bootstraps on the RX pins and the Artik-7 could be fighting the pulls in the 811.
    Can you send me a register dump from 0x0 to 0x1F and also include 0x467?
    For register 0x467, you need to implement extended register access (outlined in the datasheet).

    Have you tried implementing a reverse loopback? This will loop the data received on the MDI back to the link partner, but the data will traverse the entire PHY blocks. It will help confirm the issue is on the RGMII.

    If possible, can you implement additional delay in the Artik-7?
  • 0 in reply to Ross Pimentel
    Intellectual 570 points

    Thanks for the clear Broad-Reach to 100BaseT1 interoperability statement, Ross.  That removes this from the possibilities.

    The register dump is attached.  

    I'll investigate the Artik-7 PU/PD situation to verify that the bootstrap modes are correct, but please verify this in the registers as well.  The 1G PHY on 1G similar product works fine, and although it's a different PHY as I recall the bootstrapping is very similar.  I'll also look for Artik-7 RGMII delay possibilities.

    We can and want to implement remote loopback, but Linux tools recognize the loopback and so do the loopback in SW, never using the PHY.  Any suggestions of a Linux tool to test the operation in remote loopback that won't get "shorted out" by Linux?

    Still working on getting a good scope to capture the RGMII signals.

    Additional clue:  the error rate depends on traffic in the opposite direction.  It runs almost error-free if we reduce the traffic going the other way (like use a physical serial port instead of a virtual one on the link). 

    Fullscreen hydra_t1_reg_dump.txt Download 
     96.200000] PHY Register 0x0 val = 0x2100                                    
[   96.204000] PHY Register 0x1 val = 0x61                                      
[   96.208000] PHY Register 0x2 val = 0x2000                                    
[   96.212000] PHY Register 0x3 val = 0xa253                                    
[   96.216000] PHY Register 0x4 val = 0x1                                       
[   96.216000] PHY Register 0x5 val = 0x0                                       
[   96.220000] PHY Register 0x6 val = 0x0                                       
[   96.224000] PHY Register 0x7 val = 0x2001                                    
[   96.228000] PHY Register 0x8 val = 0x0                                       
[   96.232000] PHY Register 0x9 val = 0x2000                                    
[   96.236000] PHY Register 0xA val = 0x100                                     
[   96.240000] PHY Register 0xB val = 0x1000                                    
[   96.244000] PHY Register 0xC val = 0x0                                       
[   96.248000] PHY Register 0xD val = 0x401f                                    
[   96.252000] PHY Register 0xE val = 0x34b                                     
[   96.256000] PHY Register 0xF val = 0x0                                       
[   96.260000] PHY Register 0x10 val = 0x1085                                   
[   96.264000] PHY Register 0x11 val = 0x10b                                    
[   96.268000] PHY Register 0x12 val = 0x6400                                   
[   96.272000] PHY Register 0x13 val = 0x4200                                   
[   96.276000] PHY Register 0x14 val = 0x0                                      
[   96.280000] PHY Register 0x15 val = 0x0                                      
[   96.284000] PHY Register 0x16 val = 0x100                                    
[   96.288000] PHY Register 0x17 val = 0x5a41                                   
[   96.292000] PHY Register 0x18 val = 0x1010                                   
[   96.296000] PHY Register 0x19 val = 0xc00                                    
[   96.300000] PHY Register 0x1A val = 0x10                                     
[   96.304000] PHY Register 0x1B val = 0x7d                                     
[   96.308000] PHY Register 0x1C val = 0x5ee                                    
[   96.312000] PHY Register 0x1D val = 0x0                                      
[   96.316000] PHY Register 0x1E val = 0x0                                      
[   96.320000] PHY Register 0x1F val = 0x0                                      
[   96.324000] Strap Register 0x467 val = 0xC

  • 0 in reply to Steve Patterson
    TI__Mastermind 23675 points
    Hi Steve,

    Based on the register settings, you are bootstrapping to RGMII with TX delay only.
    However, you said that you have also tried using internal delay up to 4ns.

    It would help to get the scope shots because 4ns should be more than enough to close on timing.

    When enabling a reverse loopback, you can use a tool like Ostinato. This allows you to control your NIC and receive the same frames you sent.
  • 0 in reply to Ross Pimentel
    Intellectual 570 points

    Ross,

    We're playing with Ostinato now to see if that tool helps and RGMII scope shots are making progress.

    When interoperating with the RadMoon, is the RadMoon in half or full duplex mode?  Thanks.

  • 0 in reply to Steve Patterson
    TI__Mastermind 23675 points
    Hi Steve,

    We can interoperate at 100% utilization Full-Duplex with the RadMoon, no issues seen.
  • 0 in reply to Ross Pimentel
    Intellectual 570 points

    We found the issue.  Because the 811 doesn't support auto-negotiation, the Linux driver gets conservative and sets the MAC for half-duplex mode, hence the packet drops related to reverse traffic.  Does the 811 not support auto-negotiation because it only supports one rate and T1 is full-duplex by definition, or another reason?  I'll mark this as resolved after learning the auto-negotiation details.

  • 0 in reply to Steve Patterson
    TI__Mastermind 23675 points

    Hi Steve,

    I am glad you found the resolution.
    There is no auto-negotiation for 100BASE-T1 PHYs.
    IEEE802.3bw is a fixed speed interface and only supports 100Mbps Full-Duplex.

    There is link training for 100BASE-T1 PHYs, which is how a Master and Slave establish link, but it is not auto-negotiation.