DP83867E: Link becomes not established

Hi Hayashi, 

Thank you for submitting your query, I will gladly assist. I want to clarify a few things about customer setup

Hideki Hayashi1 said:

but Link UP and Down are repeated

Hideki Hayashi1 said:

link is established at 1G by auto-negotiation

Is this referring to 2 different PHYs, one where link is established but ping is not working, and one where link is switching between up and down?

What cable is being used for this test? What is the cable length?

Has the customer tried linking with another PHY instead of a PC as a link partner?

Can the customer provide register dumps for both cases, where link is not being established at all and with the intermittent link? Specifically, I want to take a look at registers 0x00 - 0x1F, 0x6E, 0x6F. 

Please note that the latter 2 registers (0x6E, 0x6F) are extended registers and need to be accessed accordingly. More information about this can be found at this FAQ.

These registers would tell us more about the general status of the PHY, as well as the modes that the PHY is strapped in to make sure everything adds up.

Hideki Hayashi1 said:

Customer refers Revision C

Is this referring to the datasheet revision? I believe the latest datasheet revision is Rev. E which can be found here.

Best,

Vivaan

Hi Vivaan,

Vivaan Jaiswal said:

Is this referring to the datasheet revision? I believe the latest datasheet revision is Rev. E which can be found here.

Yes, it is the datasheet revision. The information can be hints for issue if it comes from errata after Rev.C.

I will let customer to answer those.

Regards,

Hayashi.

Hi Hayashi, 

Got it, all the updated documentation and support can be found for this part on the product page. Looking forward for the customer to clarify the setup

Best,

Vivaan

Hi Vivaan,

Vivaan Jaiswal said:

Is this referring to 2 different PHYs, one where link is established but ping is not working, and one where link is switching between up and down?

No, a single chip behave differently.

Vivaan Jaiswal said:

What cable is being used for this test? What is the cable length?

Cat 6 cable from Buffalo

Vivaan Jaiswal said:

Has the customer tried linking with another PHY instead of a PC as a link partner?

Yes they tried linking with DP83867ERGZT.

Vivaan Jaiswal said:

an the customer provide register dumps for both cases, where link is not being established at all and with the intermittent link? Specifically, I want to take a look at registers 0x00 - 0x1F, 0x6E, 0x6F. 

Please note that the latter 2 registers (0x6E, 0x6F) are extended registers and need to be accessed accordingly. More information about this can be found at this FAQ.

Please see the following registers which is different situation.

When the link is up after unit startup and pinging is performed, but it almost never passes.: 

LAN,REG,VAL
02,0000,1000
02,0001,796D
02,0002,2000
02,0003,A231
02,0004,01E1
02,0005,CDE1
02,0006,006D
02,0007,2001
02,0008,4006
02,0009,0300
02,000A,78FF
02,000B,0000
02,000C,0000
02,000D,401F
02,000E,0100
02,000F,3000
02,0010,5860
02,0011,AF02
02,0012,0000
02,0013,0184
02,0014,0AC7
02,0015,0000
02,0016,0000
02,0017,0040
02,0018,6158
02,0019,4444
02,001A,0002
02,001B,0000
02,001C,0000
02,001D,0000
02,001E,0082
02,001F,0000

LAN,MMD,REG,VAL
02,001F,006E,0803
02,001F,006F,0100

When pinging is performed after link up, down, and up, but almost never passes.: 

LAN,REG,VAL
02,0000,1000
02,0001,796D
02,0002,2000
02,0003,A231
02,0004,01E1
02,0005,CDE1
02,0006,006F
02,0007,2001
02,0008,4006
02,0009,0300
02,000A,78FF
02,000B,0000
02,000C,0000
02,000D,401F
02,000E,0100
02,000F,3000
02,0010,5860
02,0011,BF02
02,0012,0000
02,0013,9DC4
02,0014,0AC7
02,0015,0000
02,0016,0000
02,0017,0040
02,0018,6158
02,0019,4444
02,001A,0002
02,001B,0000
02,001C,0000
02,001D,0000
02,001E,0082
02,001F,0000

LAN,MMD,REG,VAL
02,001F,006E,0803
02,001F,006F,0100

LAN: Port number

REG: Register address

VAL: register value

Best regards,

Hayashi

Hi Hayashi, 

Thank you for clarifying the setup. 

Looking into the registers, I found that the straps are being set for enabling both RGMII and SGMII modes. What MII interface is the customer using for this project?

Are there any distinguishing factors that make the PHY behave in the 2 different ways described above, or is the behaviour random between both?

Hideki Hayashi1 said:

Cat 6 cable from Buffalo

I also wanted to clarify what is the cable length being used for this setup?

Hideki Hayashi1 said:

Yes they tried linking with DP83867ERGZT.

Is the same issue with intermittent link occurring for this setup as well?

How is the link being recognized? From the register dump I am able to see link in both cases. Is the customer using register 0x01 for checking link status, or the LED, or the link partner side?

Also, would it be possible for the customer to share the schematic? Kindly ask the customer to use the following checklist to also make sure that the design criteria were met. 

SLVRBN1A.xlsx

Best,

Vivaan

Hi Vivaan,

Sorry for late reply. customer send me a schematic and checklist as below. There are two LAN ports uses DP83867 in same PCB in same schematic and almost same layout. But port1 sometimes fails and the other doesn't, OR port2 sometimes fails and the other doesn't. it happens randomly. 

DP83867 2ports schematic.pdfSLVRBN1A_answered.xlsx

Other infomation.

1. The lot # of the issued device is 3056433EM3.

2.  Datasheet Revision update (3.4 Unstable Link Up Debug in 1Gbps communication) -> When Link is not established, after trying this, they can link up, but PING is still not passing.

3. Datasheet Revision update (3.5 DP83867PHY and DP83867PHY Cannot Link Up in 1Gbps) -> A231. no relation.

4. Waveform at GBE2_SGMII_RXN/GBE2_SGMII_RXP are below. Left is good. Right is not good.

5. Status Register 1 [7:0] IDE ERROR COUNTER is different. Good one is 00, Not good one is FF.

6. Interrupt Status Register is different. Good one is 0x0000, Not good one is following

From left to right, "port1 correct value", "port2 PING, once", "port2 PING, twice", "port2 PING once per 20 times success"

Could you advise why the device doesn't work as expected?

Regards,

Hayashi

Hi Hayashi, 

Thank you for all the detailed information. 

You mention that both DUTs are on the same PCB. Are both devices interfacing with the same SoC as well? 

Hideki Hayashi1 said:

Waveform at GBE2_SGMII_RXN/GBE2_SGMII_RXP

The waveforms both look like they shouldn't be causing such behaviour

Hideki Hayashi1 said:

Datasheet Revision update (3.4 Unstable Link Up Debug in 1Gbps communication) -> When Link is not established, after trying this, they can link up, but PING is still not passing.

Glad that this helped solve at least the link up behaviour. 

As you mention, the issue happens on either port 1, or port 2. Are you testing both PHYs at the same time? If so, have you tried only testing one PHY at a time?

Additionally, I would like to do a reverse loopback test as well. This can be set with register 0x16[5:2]. Using this, we can try sending out packets from the PC (Link Partner) which would then be internally routed back to the PC from the PHY. By comparing the packets sent and the packets received, we can verify the integrity of the MDI side of the data path. 

Best,

Vivaan

Hi Vivaan,

Vivaan Jaiswal said:

As you mention, the issue happens on either port 1, or port 2. Are you testing both PHYs at the same time? If so, have you tried only testing one PHY at a time?

Sorry I was wrong that the issue only happen at port 2 even though the schematic and layout is similar. And they test at only one port, the another port has not connected to PC but PHY itself it power-on.

Vivaan Jaiswal said:

Are both devices interfacing with the same SoC as well? 

Correct

Vivaan Jaiswal said:

Additionally, I would like to do a reverse loopback test as well. This can be set with register 0x16[5:2]. Using this, we can try sending out packets from the PC (Link Partner) which would then be internally routed back to the PC from the PHY. By comparing the packets sent and the packets received, we can verify the integrity of the MDI side of the data path. 

In loopback test, what should do at PC side? Could you explain further about the procedure of the test? Customer and I read 7.4.4 Loopback mode, but we're not sure.

Best regards,

Hayashi

Hi Hayashi, 

Thanks for clarifying that the behaviour is only seen on port 2. 

Has the customer tested port 1 with the same PC/cable and it works as expected?

Since the idle error counter reads as FF in some failure cases. This can be due to the cable signal quality degradation, FIFO buffer overflow, or incorrect IPG. I wanted to at least verify that this is not caused by cable damage, can the customer test using a different cable? Additionally, we can also try increasing the FIFO depth using register 0x10[15:12] and see if that helps with the idle errors. 

Hideki Hayashi1 said:

In loopback test, what should do at PC side? Could you explain further about the procedure of the test? Customer and I read 7.4.4 Loopback mode, but we're not sure.

After loopback is set up on the PHY, the customer can send any kind of data to the PHY which would then be routed back to the PC. Using a program like wireshark, or any other program, they could see the sent and received packet. If the same sent packet is received, we can validate that the MDI line of the PHY is working as expected. This could even be a ping request packet, but instead of a ping response we would expect the request itself to be routed back to the PC. 

I also wanted to check the SGMII lines themselves. If customer could probe the SGMII RX and TX lines during the ping request without any loopbacks enabled, it would let us know if the SoC is even getting the request, and if it is replying to the received request. 

Best,

Vivaan

Hi Vivaan,

Customer set the PHY as "1Gbps/full" and "Far-end (Reverse Loopback)" and uses Data Quality Analyzer (MD1230B) to see data loss by sending frames.

Port1 can be confirmed as al frames are returns in error free.

Port2 loss about 80%. Sent frames count is 9,940,424 and received frame count is 2,045,727.

Customer believe it is from the chip-to-chip variation. What do you think?

Regards,

Hayashi

Hi Hayashi, 

Thank you for the reverse loopback test result. 

I wanted to make sure that the other factors in this test were the same for both ports, including the same cable, same link partner/port, etc

Based on this result, it does look like the MDI side is the cause of this packet loss. 

I wanted to confirm whether this packet loss behaviour is seen only in gigabit speeds, same as the ping loss. Would it be possible to run the same test with port 2 with a link speed of 100M instead?

Hideki Hayashi1 said:

Customer believe it is from the chip-to-chip variation. What do you think?

It could also be a chip-to-chip variation. The best way to test this, if it is possible, would be to perform an ABA swap on the PHY itself, changing the port 1 PHY to port 2, and the port 2 PHY to port 1. Then, we can repeat the same series of tests and if the packet loss issue now appears on port 1, we would know that it is likely a PHY behaviour, otherwise, if the packet loss issue still stays on port 2, it would likely be an application level behaviour. 

Best,

Vivaan

Hi Vivann,

They confirmed they can see this issue only 1000M, they cannot see any loss at 100/10M with same setting. As of now, ABA swap is difficult at customer side because they need some internal alignment to do this. Could you please give us your opinion how to move this forward?

Regards,

Kotaro Yamashita

Hi Yamashita, 

Is this behaviour consistent across different boards? Are you able to see the same packet loss on port 2 of other boards as well? This should give us a little more insight into whether this behaviour is chip level or application level.

Thank you for confirming that the issue is only seen on gigabit speeds. Since the schematics of both ports look identical, I wanted to take a closer look at the layout. I have attached the layout checklist below, kindly take ask the customer to go through it and fill it out. 

SNLR048A.xlsx

Best,

Vivaan