DP83867IS: The short cable issue

Hi Shane,

Thanks for your reply.

Customer also tested competitor device and didn't find the packet loss w/ short cable. Does that mean the competitor optimize for short cable? I'm curious why TI don't optimize for short cable? Is it conflict for the optimization of short cable and mid-long cable?

BTW, All TI PHY are optimized for mid-long cable? or just DP83867?

BRs,

Rannie

Hi Rannie,

Rannie Zhou said:

Does that mean the competitor optimize for short cable?

The competitor may be optimizing for short cable or may be using a longer link training process to converge to the right SNR settings.

Rannie Zhou said:

I'm curious why TI don't optimize for short cable?

The majority of our customers use cables 3M and above, sometimes up to 100M cables. I believe that by optimizing the PHY for these lengths, we can spend less time in the link training stage and support faster link-up times. By 'short cable' we're mainly referring to cables 1M or less. These cables can still be supported, but you should increase the link training time so the PHY can find the appropriate signal recovery settings.

Rannie Zhou said:

BTW, All TI PHY are optimized for mid-long cable? or just DP83867?

I have not heard of this short cable issue on other standard ethernet PHYs thus far. 

Best,

Shane

Hi Shane,

Thanks for your kindly reply. There are 2 questions from customer side. Could you please have a look?

1. After switching the server rate several times, ping fails.
---- Connect DP83867 network port of the test machine to the server and set the test machine network port to adaptive. After changing the server rate from 1Gbps to 100Mbps, the test machine adapts to 100Mbps and can ping. At this time, change the server rate from 100Mbps to 1Gbps and then 1Gbps to 100Mbps to perform a ping test again. It is highly likely that ping will fail. Repeat this several times and you will definitely be able to replicate the phenomenon of being unable to ping.

2. After adjusting the test machine rate to 100Mbps, ping 65500 packets to the server, and it will fail. Chips from other manufacturers have not yet been replicated to similar problems.

BRs,

Rannie

Hi Rannie,

1. In this testing, you're switching the link speed between 100M and 1G multiple times then seeing ping fail?

Typically the PHY will link up in one speed and remain at that speed until it is disconnected. For better context, what end equipment is the 867 used on that requires adaptive link speeds?

• Does ping work if the cable is disconnected between link speed changes?
• Can you provide the register dump when the failure is observed?

2. Does the ping fail every time or is there a failure rate? Is this tested before or after running test #1 (above)?

Best,

Shane

Hi Shane,

Shane Hauser said:

ou're switching the link speed between 100M and 1G multiple times then seeing ping fail?

Yes

Shane Hauser said:

ypically the PHY will link up in one speed and remain at that speed until it is disconnected

But in DS, it can auto-negotiation the speed rate according to the MDI side speed, right? Does DP83867 support?

Shane Hauser said:

what end equipment is the 867 used on that requires adaptive link speeds?

The industrial PC on power delivery system, the CPU is Intel X86 series. Customer changed many boards with different CPU platform and the issue behavior was same.

Shane Hauser said:

Can you provide the register dump when the failure is observed?

Do you need all the registers or the register in Trouble shooting guide?

Shane Hauser said:

Does the ping fail every time or is there a failure rate? Is this tested before or after running test #1

This Ping failed every time and this is independent from issue 1. Can you help to reproduce this issue and check in TI Lab?

BRs,

Rannie

Hi Rannie,

Rannie Zhou said:

But in DS, it can auto-negotiation the speed rate according to the MDI side speed, right?

Yes the SGMII auto negotiation speed is based on the MDI resolved speed at link up. When you change the MDI speed, can you check the SPEED SELECTION register to ensure the PHY is tracking this speed change correctly?

Rannie Zhou said:

Do you need all the registers or the register in Trouble shooting guide?

The troubleshooting guide registers should be sufficient.

Rannie Zhou said:

This Ping failed every time and this is independent from issue 1. Can you help to reproduce this issue and check in TI Lab?

If you're unable to ping through the PHY at a 100Mbps link there could be an implementation issue. I've tested ping through the DP83867ERGZ-S-EVM and it has worked at 100Mbps. In my test setup, there are two EVMs with the SGMII interfaces connected back-to-back. A PC on one end is able to ping a PC on the other end with no issues.

Can you share the schematic for this design? I will check whether there is a implementation issue here.

Best,

Shane

Hi Shane,

Shane Hauser said:

If you're unable to ping through the PHY at a 100Mbps link there could be an implementation issue. I've tested ping through the DP83867ERGZ-S-EVM and it has worked at 100Mbps. In my test setup, there are two EVMs with the SGMII interfaces connected back-to-back. A PC on one end is able to ping a PC on the other end with no issues.

Customer cannot ping with 65500 packets. May I ask the test in TI Lab is also with the same size data packets?

I will ask customer to provide the register and schematics soon. Thanks!

BRs,

Rannie

Hi Rannie,

Is the ping packet size 65500 bytes, or are you sending 65500 smaller packets? From this E2E, the DP83867 can only support packet sizes up to 13500 bytes maximum. I've tested ping with this packet size and am getting no packet loss.

Best,

Shane

Hi Shane,

Sorry for the late response.

Please find the register dump for issue and normal case:

Log1: After switching the server rate multiple times (100Mbps 1Gbps), pinging failed and then capture the register value. 

read phy addr: 0x0 reg: 0x11 value : 0x6c02
read phy addr: 0x0 reg: 0x0 value : 0x1140
read phy addr: 0x0 reg: 0x1 value : 0x796d
read phy addr: 0x0 reg: 0x3 value : 0xa231
read phy addr: 0x0 reg: 0x4 value : 0xd41
read phy addr: 0x0 reg: 0x5 value : 0xcd01
read phy addr: 0x0 reg: 0x9 value : 0x200
read phy addr: 0x0 reg: 0xa value : 0x0
read phy addr: 0x0 reg: 0x10 value : 0x848
read phy addr: 0x0 reg: 0x11 value : 0x6c02
read phy addr: 0x0 reg: 0x12 value : 0x0
read phy addr: 0x0 reg: 0x13 value : 0x5d44
read phy addr: 0x0 reg: 0x14 value : 0x2bc7
read phy addr: 0x0 reg: 0x15 value : 0x0
read phy addr: 0x0 reg: 0x16 value : 0x0
read phy addr: 0x0 reg: 0x17 value : 0x40
read phy addr: 0x0 reg: 0x18 value : 0x6b10
read phy addr: 0x0 reg: 0x19 value : 0x4004
read phy addr: 0x0 reg: 0x1e value : 0x202
read phy addr: 0x0 reg: 0x6e value : 0x800
read phy addr: 0x0 reg: 0x6f value : 0x100

read phy addr: 0x0 reg: 0x11 value : 0x6c02
read phy addr: 0x0 reg: 0x0 value : 0x1140
read phy addr: 0x0 reg: 0x1 value : 0x796d
read phy addr: 0x0 reg: 0x3 value : 0xa231
read phy addr: 0x0 reg: 0x4 value : 0xd41
read phy addr: 0x0 reg: 0x5 value : 0xcd01
read phy addr: 0x0 reg: 0x9 value : 0x200
read phy addr: 0x0 reg: 0xa value : 0x0
read phy addr: 0x0 reg: 0x10 value : 0x848
read phy addr: 0x0 reg: 0x11 value : 0x6c02
read phy addr: 0x0 reg: 0x12 value : 0x0
read phy addr: 0x0 reg: 0x13 value : 0x1c44
read phy addr: 0x0 reg: 0x14 value : 0x2bc7
read phy addr: 0x0 reg: 0x15 value : 0x0
read phy addr: 0x0 reg: 0x16 value : 0x0
read phy addr: 0x0 reg: 0x17 value : 0x40
read phy addr: 0x0 reg: 0x18 value : 0x6b10
read phy addr: 0x0 reg: 0x19 value : 0x4004
read phy addr: 0x0 reg: 0x1e value : 0x202
read phy addr: 0x0 reg: 0x6e value : 0x800
read phy addr: 0x0 reg: 0x6f value : 0x100

Log3: When the ping 10000 packet is OK, the register value captured 

read phy addr: 0x0 reg: 0x11 value : 0x6f02
read phy addr: 0x0 reg: 0x0 value : 0x1140
read phy addr: 0x0 reg: 0x1 value : 0x796d
read phy addr: 0x0 reg: 0x3 value : 0xa231
read phy addr: 0x0 reg: 0x4 value : 0xd01
read phy addr: 0x0 reg: 0x5 value : 0xc141
read phy addr: 0x0 reg: 0x9 value : 0x0
read phy addr: 0x0 reg: 0xa value : 0x800
read phy addr: 0x0 reg: 0x10 value : 0x848
read phy addr: 0x0 reg: 0x11 value : 0x6f02
read phy addr: 0x0 reg: 0x12 value : 0x0
read phy addr: 0x0 reg: 0x13 value : 0x4
read phy addr: 0x0 reg: 0x14 value : 0x2bc7
read phy addr: 0x0 reg: 0x15 value : 0x3
read phy addr: 0x0 reg: 0x16 value : 0x0
read phy addr: 0x0 reg: 0x17 value : 0x40
read phy addr: 0x0 reg: 0x18 value : 0x6b10
read phy addr: 0x0 reg: 0x19 value : 0x4004
read phy addr: 0x0 reg: 0x1e value : 0x202
read phy addr: 0x0 reg: 0x6e value : 0x800
read phy addr: 0x0 reg: 0x6f value : 0x100

read phy addr: 0x0 reg: 0x11 value : 0x6f02
read phy addr: 0x0 reg: 0x0 value : 0x1140
read phy addr: 0x0 reg: 0x1 value : 0x796d
read phy addr: 0x0 reg: 0x3 value : 0xa231
read phy addr: 0x0 reg: 0x4 value : 0xd01
read phy addr: 0x0 reg: 0x5 value : 0xc141
read phy addr: 0x0 reg: 0x9 value : 0x0
read phy addr: 0x0 reg: 0xa value : 0x800
read phy addr: 0x0 reg: 0x10 value : 0x848
read phy addr: 0x0 reg: 0x11 value : 0x6f02
read phy addr: 0x0 reg: 0x12 value : 0x0
read phy addr: 0x0 reg: 0x13 value : 0x4
read phy addr: 0x0 reg: 0x14 value : 0x2bc7
read phy addr: 0x0 reg: 0x15 value : 0x0
read phy addr: 0x0 reg: 0x16 value : 0x0
read phy addr: 0x0 reg: 0x17 value : 0x40
read phy addr: 0x0 reg: 0x18 value : 0x6b10
read phy addr: 0x0 reg: 0x19 value : 0x4004
read phy addr: 0x0 reg: 0x1e value : 0x202
read phy addr: 0x0 reg: 0x6e value : 0x800
read phy addr: 0x0 reg: 0x6f value : 0x100

The schematics for DP83867: dp83867 (1).pdf

BRs,

Rannie

Hi Rannie,

Thank you for these logs and schematic, here are my comments:

1. The Bob-smith termination on the magnetic center taps is incorrect. The resistors R1120 - 1123 should be 75ohms, not 0ohms.

2. I still do not understand what you mean by '65500 packet' failure. Is the customer sending 65500 packets or is the packet size 65500 bytes?

3. All register logs show the auto negotiation resolving to 100Mbps speeds. When you switch between 1G and 100M, do you see register 0x0011[15:14] track the speed correctly? I see there was a speed change interrupt in the first log (0x13[14]) so I believe the PHY is tracking correctly but would like to confirm this.

Best,

Shane

Hi Shane,

Thanks for your kindly reply.

Shane Hauser said:

2. I still do not understand what you mean by '65500 packet' failure. Is the customer sending 65500 packets or is the packet size 65500 bytes?

It's 655500 bytes. Do we have the PHY that can support bigger packets?

Shane Hauser said:

1. The Bob-smith termination on the magnetic center taps is incorrect. The resistors R1120 - 1123 should be 75ohms, not 0ohms.

What's problem will be caused if the resistor is 75Ohm not 0Ohm?

BRs,

Rannie

Rannie

The four 75 Ohm resistors (2 for Rx, 2 for Tx) and a capacitor to provide an impedance-matched path back to a ground point in the system. 

If they reduce the packet size down to 13500 bytes, do they see this ping failure?

Thanks

David

Hi David,

Thanks for your reply.

For the impendence match, customer feedback that they thought 0Ohm has no problem here. So that's why I would like to confirm with you whether this problem will be caused if the resistor is 75Ohm not 0Ohm?

Is there any document to clarify the maximum of 13500bytes except the E2E reply?

BRs,

Rannie

Hi Rannie,

1. 0 ohms can have issues because the termination will be incorrect. This will add reflections to the signal and reduce signal quality.

2. I can look to see if we have this but would like more understanding on the customer need. 13500 bytes is already a very large frame size (IEEE802.3 spec maximum is 1518 bytes for reference).

Does the customer's application require frames with 65500 bytes? These are called 'super jumbo frames' and are not a common use case for our PHYs. What end application is the customer using that would need frames this large?

Hi Shane,

Thanks for your reply.

Shane Hauser said:

1. 0 ohms can have issues because the termination will be incorrect. This will add reflections to the signal and reduce signal quality.

Customer feedback that they think 0Ohm is OK because only "ping" failed so that the signal integrity is well. 

66550 is a test standard in customer test. I'm checking with them about teh reason for such a large size packet.

In addition, customer found that after modifying the register (importing the solution for unstable 1m connection (4) DP83867IR: The communication is unstable with short cable - Interface forum - Interface - TI E2E support forums), the stability of the network chip was worse. The test results are shown in the figure below. Can you help to check the reason?

with solution for short cable issue: The Tx rate should be increased with the packet size. They tested 3 times and found the Tx rate drop happened on 512 or 1024 or 1280.

without solution:

BRs,

Rannie

Hi Rannie,

Rannie Zhou said:

Customer feedback that they think 0Ohm is OK because only "ping" failed so that the signal integrity is well. 

If the signal integrity is good and you are using a supported packet size, the ping would not fail. I recommend fixing this bob smith termination and reducing the frame size to within 13500 bytes. We have not validated DP83867 with frames over 13500 bytes and cannot guarantee the functionality.

Rannie Zhou said:

The test results are shown in the figure below. Can you help to check the reason?

Can you explain what 'TX Rate' is referring to specifically? It is not clear what this metric is showing (packet loss, throughput,...).

Best,

Shane

Hi Shane,

Will push customer to change resistor and feedback the results to you.

The "TX rate" means the packet loss rate...

BRs,

Rannie

Hi Rannie,

Shane is OoO until Thursday. Please expect a delay in response.

Sincerely,
Gerome

Rannie

Please push customer to change the termination to 75ohm and reduce the packet size, and see if the packet loss still happens.

Thanks

David

Hi David,

The packet in packet loss test is 1518bytes max in the list, which don't exceed the maximum value of DP83867. Should customer still reduce the packet size? 

Customer feedback that changing the resistor to 75Ohm has no improvement. Can you help to check is there any other debug direction?

BRs,

Rannie

Rannie

Can you please explain to me the meaning the TX Rate(%) and RX_Through from their test result? Does 100% means 100% bandwidth utilization or 100% Ping Packet Drop? How does they from the result that the Ping has failed?

Can they please put DP83867 into reverse packet? The reverse loopback will help isolating the issue between the SGMII and MDI. Please see this e2e FAQ on how to enabled the BIST and Reverse Loopback function.

Thanks

David

Hi David,

Can you help to support an online meeting with customer to discuss this issue? So that we can fully understand customer application and test condition? I will send the invitation through another separate email. Thanks!

Up to now, there are only 2 questions need be clarified:

1, pin fail when changing rate between 1Gbps and 100Mbps. 

2, packet loss related:

Test summary:

1. Test board in Lab send packet and read back and check the packet loss
2. The loading (bandwidth occupied rate) is increasing until reporting the packet loss. Tx rate is that critical value, the maximum loading in a certain frame size.
3. For example, 34.4% means that when the frame size is 66bytes and the loading is 34.4%, the packet loss reported.
4. In customer understanding, the frame size is larger, it’s difficult to see packet loss. So, the 87.402% in 1280bytes is unexpectable.
5. BTW, this issue only happened after customer modify the register and fix the short cable issue.

BRs,

Rannie

Rannie

Instead using BW utilization to indicate the packet loss, can they please check the MAC or the test board to see if there is actually packet loss?

Please also put the DP83867 into reverse loopback mode, this will help isolating the issue between the MDI and MAC interface.

Thanks

David