DP83TD510E: DP83TD510E Media-Converter RGMII Problem

Hi Pourya,

Please share a register dump for both PHYs from addresses 0 to 1E. The issue may only be between the MAC & PHY - further information about the PHY's configuration will help diagnose this.

Thank you,

Evan

Hi Evan,

Thanks for your reply, and happy new year!

Attached you can find two sets of Register-Dumps for both PHYs. One set contains register values read directly after PHYs initialization, the other set contains register values read a few seconds after the Initialization (so that the Link can be build up, as can be seen in register 0x10 of DP83TD510E).

Thank you in advance,

Pourya

Initailization_Phase_Dump.zipRunTime_Phase_Dump.zip

Hi Pourya,

Happy new year! Thank you for sharing the register dumps.

Are the RGMII input timing requirements being met? Specifically >40ns setup and hold times (section 6.6).

The data and clock in the waveform shared appear aligned, and the 510 is programmed correctly in align mode, so I would like to verify these timing requirements as the next step.

In addition, please verify the MDI and MII data paths with the following loopback modes:

- Perform reverse loopback on the KSZ, transmitting and receiving packets from its link partner (validates MII).

- Perform digital loopback on the 510, transmitting and receiving packets from the KSZ's link partner (validates MDI & MII).

These two loopback tests will help isolate the issue to a specific part of the data path.

Thank you,

Evan

Hi Evan,

The timing requirement are being met, but we will do more test nonetheless and inform you if we detect any deviation.

I also ran the Loopback tests, correct me if I have misunderstood you about the tests:

• Perform reverse loopback on the KSZ: 510ePHY->configured as normal, KSZ->With reverse loopback, that is, whatever 510ePHY sends will be looped back to 510ePHY. -> Result: Not successful, could not receive any data back.
• Perform digital loopback on the 510: KSZ->Configured as normal, 510ePHY configured with Digital loopback (BISCR(0x16) = 4h) and Register-0x0883[0] = 0x1.
  That is, whatever KSZ sends will be looped back to KSZ.
  Result: Not successful (I don’t see the Register description in address 0x0883 in datasheet, but anyway I tested one without any changes in this register and one with it, none of them worked)

Best regards,
Pourya

Hi Pourya,

For your reverse loopback test, how are you sending and checking the data on the 510 end?

Please verify the speed is 10M on KSZ, and also try disabling advertisements for 100M/1G speeds.

Thank you,

Evan

Hi Evan,

The KSZ is configured with 10M and auto-negotiation is disabled and the local (digital) loopback is activated (Reg 0h = 4100h).

As for sending and receiving on the 510 side, I have another Media-Converter form Arrow-Electronics which has T1L capability, the twisted pair is connected to our Media-Converter, That means we know that if we Ping from the Arrow-Box-Media-Converter, the data will be also received at our Media-Converter twisted-pairs end, the 510 now should convert and send the data through RGMII to the other PHY, as the KSZ is in loopback mode, I should receive whatever I sent and see it on Arrow-Box side, which I don’t unfortunately.

In 510 side I also activated LED0 to blink in Rx or Tx activities (Reg 460h = Ah or Bh) It does not blink in any of those.

Interesting enough, in “digital loopback on the 510 Mode” (510 in Loopback, KSZ normal mode), if I ping from KSZ side, the LED on 510 side does blink in both Rx and Tx modes (Reg 460h = Ah or Bh)

best regards,

Pourya

Hi Pourya,

Reverse loopback will send data back through the MDI. From my understanding of your configuration for this test, data was sent from Media converter -> (MDI) -> 510 -> (MII) -> KSZ without being looped back. This would align with the result of not seeing data on the media converter side. Could you perform this same test with the KSZ set in digital loopback, and note whether the same 510 LED shows TX/RX activity?

From the results of your digital loopback test, it is possible the RX data path of 510 is not valid. Are the TX/RX waveforms shared in the initial post captured from the 510 or KSZ end of the board, and where was the data sent from?

Thank you,

Evan

Hi Evan

Yes, the configuration of this test was Media Converter->(MDI) -> 510 -> (RGMII) -> KSZ, and the KSZ was configured in Digital loopback mode. I didn’t understand what you mean by configuring KSZ in digital loopback mode, it was already in that mode.

Regarding the Waveform captures, if you save the Pictures, you see that they are named according to where the Oscilloscope probes were placed, namely:

In picture “r300_r305_10B-T_TX” R300 is the resistor connected to 510 RX_CLK pin and R305 is connected to 510 RXD[3].

And in picture „r400_r402_10B-T_RX” R400 is the resistor connected to KSZ RX_CLK and R402 connected to KSZ RXD[1].

Thank you,

Pourya

Hi Pourya,

Please verify the 510 and KSZ are following the configurations specified in this FAQ:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1099945/faq-how-to-select-correct-rgmii-delay-mode-for-phy-and-mac

Thank you,

Evan

Hi Evan,

We have tested various Align/Shift configurations in Both PHYs, as mentioned in the FAQ. But none of them has resolved the issue.

We have used KSZ before in previous Projects without any Problem in RGMII, I wonder if in general there are known issues in 510 PHY regarding RGMII communication that I should take into consideration (Other than the General guid line mentioned in the FAQ) ?

Best Regards,

Pourya

Hi Pourya,

Due to U.S. holiday, please allow me until tomorrow 1/17 to discuss with the team and get back to you.

Thank you,

Evan

Hi Pourya,

There are no known issues in the 510 regarding RGMII - if the PHYs are programmed in the correct mode following the FAQ and the input waveforms are following the timing requirements, the communication should work.

Please share which mode the 510 and KSZ are programmed in for the usual case, with waveforms captured on the input ends of 510 and KSZ for this case. Decreasing the time scale of these waveform captures will help us review and verify the timing requirements are being met.

Thank you,

Evan

Hi Evan,

We did a review of the Signals and configurations. Attached you can see the Waveform captures from Tx and Rx lines with better Time-resolution.

Picture “R305_R300_DP83” captures RXD[3] and RX_CLK from DP83TD510E. (Channel1->RX_CLK, Channel2->RXD[3])

Picture “R402_R400_KSZ” captures RXD[3] and RX_CLK from KSZ9031RNXI. (Channel1->RX_CLK, Channel2->RXD[3])

From my understanding of RGMII Specification 2.0, the timing requirements are being met, I have attached RGMII-V2.0 Specification from KSZ datasheet as a reference.

What confuses me is the RGMII timing specification found in DP83TD510E datasheet, page 14 (I have also attached a screenshot from that page). For example, TskewT  in integrated delay mode is specified with 40 ns delay! But from my understanding it’s not within RGMII-V2.0 specification, is it a typo in documentation? Or am I misinterpreting it?

Anyway, if the timing requirements are being met, and the Align/Shift modes are configured correctly, then what could be the Problem?

Best Regards,

Pourya

Hi Pourya,

Please specify which modes the 510 and KSZ are programmed in for RGMII. If possible, share the corresponding registers (KSZ's align/shift mode config appears to be in extended register space).

I see from the initial register dump, the 510 is in RX and TX align mode (reg 0x17). Has this changed?

Thank you,

Evan

Hello Evan,

We came to the conclusion, that by 510 the RGMII is not functioning properly. It would be great if more test from your side could be done on 510 RGMII communication, and if any problem is found then be reported in Errata sheet.

We are contemplating a re-design using RMII this time; we are considering the DP83848-EP, do you think, that this PHY is compatible with 510?
Do you have any other suggestions for other PHYs with RMII v1.2 and 10M support, which could also work with 510?

Best Regards,

Pourya

Hi Pourya,

With all of the information provided, we expect RGMII with 510 to work. There may be some issue on the system-level with the KSZ configuration.

DP83848 can communicate with 510 with RMII, although DP83822 is easier to evaluate as our DP83TD510EVM is an RMII media converter with 510 and 822.

Thank you,

Evan

Hi Evan,

thanks for your suggestion. The problem is, that DP83822 is not available to buy in Europe! So we have limited options, are there any other alternatives?

Thank you,

Pourya 

Hi Evan,

At the moment I don't have any specific feature for RMII PHY in mind. 
But if you/your Team found something about RGMII in 510, we and probably other Developers would benefit from your feedback.

Thanks for your help and support.

Best Regards,

Pourya 

Hi Pourya,

We are looking to create an equivalent lab setup for 510 RGMII media conversion - I will follow-up with updates if we can replicate the problem you are facing.

Thank you,
Evan