• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 34 subscribers
  • Views 1241 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.

DP83867IR: dp83867 can work well at 100Mbps，but can't work well at 1000Mbps!

user5062059
Prodigy 20 points
Part Number: DP83867IR

hi TI,

Now,I draw a sch about 7ev(arm+fpga)+3*dp83867.two dp83867 are connected to the ARM side,the other dp83867 is connected to the fpga side.

the three dp83867s can work well at 100Mbps mode,but  can't work well at 1000Mbps mode.I did some experiments as follow:

1、our card is connected to the PC，then ping the three eth，it's ok；

2、we use the iperf3 command to test the eth，the rx speed is only 230Mbps.and the tx speed is 170Mbps.

3、the voltage and the 25MHz reference clk are good.

4、the RGMII length is about 3000mil（clk,data).

5、I test the  Far-End (Reverse) Loopback，the link partner can generate the original data，and can receive the data without err.

6、release the loopback， then use the iperf3 command to test the eth，the rx speed is about 230Mbps.and the tx speed is about 170Mbps.

check the ifconfig，RX receive errors=overruns+frame.then Modify the MTU and ring buffer，the effect is not good.

Can you give me the idea about debug the dp83867 at 1000M mode?thank you.

  • 0
    TI__Expert 3595 points

    Hi!

    I have a few follow up questions to better understand what is going on. Are you using an RGMII internal delay? Did you opt to add delay on the clock PCB trace?

    Is the issue that there are lost packets? Lots of errors? Or complete link loss?

    Could you also share what strap settings you have (regs 0x6e and 0x6f)? And the register confirguations for RGMII (reg 0x32)?

    Also, the clock on pin RX_CLK should be 125MHz, not 25MHz, for 1G operation.

    Thanks,

    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 20 points

    1、I use an RGMII internal delay in the dp83867.and don't  add delay on the clock PCB trace.the length of clock and data[0,1,2,3] PCB trace is the same.

    2、check the ifconfig，RX receive errors=overruns+frame. Lots of errors,and Lots of overruns.a bittle of frame.

    3、reg 0x32 is 0x00d3，and reg 0x86 is 0x98. reg 0x6e is 0x000c，and reg 0x6f is 0x0000. 

    4、 RX_CLK is 125MHz

  • 0 in reply to user5062059
    TI__Expert 3595 points

    Hi, I see you marked this as resolved? I wanted to make sure this was intentional?

  • 0 in reply to Lysny Woodahl
    Prodigy 20 points

    I am sorry，this problem is unresolved.I need your help.

    the voltage,the value of reg are checked about phy dp83867,but i can't find the result.

  • 0 in reply to user5062059
    TI__Expert 3595 points

    Hi, 

    I suggest that we look into the delays a little more. At 1G, the system will be slightly more sensitive than it would be at 100M. Can you share what the delay is on the ARM processor and on the FPGA? It seems most likely that the errors are originating from the RGMII interface, as you said the reverse loopback is good.

    I would recommend changing reg 0x86 so that the delay for the tx and for the rx is 2ns total, including any delay from the MAC interface (ARM and FPGA).

    Let me know your results with this!

    Thanks,

    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 20 points

    HI,

    On the fpga side：

    1、I test the  Far-End (Reverse) Loopback，the link partner can generate the original data，and can receive the data without err.

    2、as following pciture，GMII can be loopback，the link partner can generate the original data，and can receive the data without err.

    3、I think RGMII is ok from item 1 and 2.

    4、At now，we only do some experiments on the FPGA(eth0).and just test the speed of eth1,the2(on the arm).the speed of three eth are same.

    Can you call me to talk about the problem?my number is 18906819845. 

  • 0 in reply to user5062059
    TI__Expert 3595 points

    Hi,

    If you are talking about far end reverse loopback, like mentioned in our datasheet, that does not go through the RGMII interface. If you set up a loopback though in the FPGA, then yes, point 3 makes sense. If point 3 makes sense, then I believe the PHY is working correctly and the error is most likely in the software on the ARM/FPGA side.

    Please let me know the results of your delay testing.

    Thanks,

    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 20 points

    HI,

    I'm think so.the error is from the software.what do you  want to know about the results of your delay testing.Now the reg 0x32 is 0x00d3，and reg 0x86 is 0x98.

    Now,I want to know how to config the phy and mac in 1000M mode？

  • 0 in reply to user5062059
    TI__Expert 3595 points

    Hi,

    From the testing / research you should know the added delay from the FPGA and from the ARM processors. The delay needs to equal 2ns. So reg 0x86 should be adjusted.

    I thought that you were already operating in 1000M mode? Were you not previously?

    Thanks,

    Lysny

  • 0 in reply to Lysny Woodahl
    Prodigy 20 points

    the speed is 230Mbps at rx direction，and 130Mbps at tx direction.but I have read the status of phy.It's 1000M mode.

    the added delay from the FPGA and from the ARM processors is adjusted by data stream.

  • 0 in reply to user5062059
    TI__Expert 3595 points

    Hi,

    LED_1 will indicate when 1000M link is established (unless default is changed via registers).

    Could you also tell me what the RX CLK frequency is and the TX CLK frequency is by probing the corresponding PHY pin?

    Also, I see that you said the delay is adjusted by data stream, can you make sure that the adjusted delay is resulting in a 2ns delay? The reg 0x86 should need to be changed. 0x98 is too high.

    I am also linking an RGMII app note that might provide some more information. www.ti.com/.../snla243.pdf