DP83869HM: Transmit side not working, but receive side is

Hi Ross,

Thank you for getting in touch with us.

Can you please let me know the following?

1. In which mode is RGMII configured on DP83867? Align mode or Shift/Internal delay mode?
2. Please check the same for the MAC too.
3. Were you able to observe a difference in skew between TX_DATA and TX_CLK after programming the DLL_TX_DELAY_CTRL_SL?

--
Regards,
Gokul.

Hi Gokul,

1) This is the DP83869HM, not the DP83867. I have RGMII_TX_CLK_DELAY equal to 1, which says "0x1 = RGMII transmit clock is aligned with respect to transmit data." I think the wording of this is a little ambiguous: Is it asking how the TX_DATA/TX_CLK will be delivered from the MAC/received at the PHY, or desired internal operation should be?

2) I have observed TX_DATA and TX_CLK  at the PHY pins themselves using an o-scope, and they are edge aligned within 340 ps.

3) I'm not sure what you mean. The MAC drives the TX_DATA and TX_CLK signal, so I believe changing DLL_TX_DELAY_CTRL_SL would only be affected internally to the DP83869HM (the 90 degree phase shift clock), so I'm not sure how to observe it. What I mean is: Changing a register setting in the PHY won't change how the MAC is driving these signals. Or have I misunderstood?

Hi Ross,

Sorry, it is a mistake from my end. I got confused with TX_* signals and RX_* signals.

To debug whether this is a problem on MDI side or on the MAC interface side, you can run with reverse loopback enabled on DP83869HM.
In reverse loopback, the data packets received by the PHY are retransmitted to link partner bypassing the MAC.

You can enable loopback by programming reg<0x0016> = 0x0020.

--
Regards,
Gokul.

I'm have found a register setting that makes comms start working, but I don't understand why: I have cleared bit 1 of register 0x32, which is setting "RGMII Transmit Clock Delay" low, which is explained: "0x0 = RGMII transmit clock is shifted with respect to transmit data." However, the PCB traces on the board are the same length. Can you please give guidance on which way to set this register when the PCB traces are the same length?

Hi Ross,

I see that the TX_CLK and TX_DATA (all transmitted by MAC) are aligned. To receive the data properly by the PHY from the TX_* lines, an internal delay has to be generated so that sampling of the data happens reliably, the TX_CLK should be shifted by a delay.

Programming 0x32[1] = 0 enabled shifting of the TX_CLK internally with respect to the TX_DATA.
After this settings the internal delay can be optimized using the bits 'DLL_TX_DELAY_CTRL_SL'.

Please let me know if you need more details.

--
Regards,
Gokul.

Thanks Gokul, that does explain why it is working now. My recommendation is to update the datasheet to make it more clear that setting the register bit to 0 will apply an internal delay. The description "RGMII transmit clock is shifted with respect to transmit data" is ambiguous as to whether it is describing the behavior of the MAC or the behavior of the PHY.  Maybe "0x0 = RGMII transmit clock will be internally shifted with respect to transmit data" is better. Plus, the opposite polarity's description makes no sense: "0x1 = RGMII transmit clock is aligned with respect to transmit data." So if a value of 0 means to apply an internal delay, a value of 1 would have to mean "dont apply a delay", as in, the clock is already delayed with respect to the data from the MAC or PCB traces. In that case, the clock from the MAC is NOT edge aligned with the data, and since in that mode, there is no internal delay added, then the internal clock is also NOT edge aligned with the data. So if the transmit clock is never aligned with respect to transmit data, then the description "transmit clock is aligned with respect to transmit data" makes no sense. Maybe a better description here would be "0x1 = RGMII transmit clock will not be internally shifted with respect to transmit data" would make it more clear.

Hi Ross,

Agree with your feedback. Let me work with our team to take this feedback into consideration.

Please let me know if there are any other queries.

--
Regards,
Gokul.