DP83867E: TDR, MDI termination on C & D 1000BASE-T Ethernet pairs

Hi Cyril,

Thank you for getting in touch with us.

Please find my comments below.

1) When DP83867E is powered down by BMCR register, MDI termination on all pairs is disconnected.
[Gokul]: Yes. The same happens even when pin RESET is asserted.

2) When DP83867E is in auto-negotiation stage, MDI termination is active on pairs A and B (used for the auto-negotiation) and we are able to use TDR against the DP83867E. The pairs C and D are still un-terminated in this stage.
[Gokul]: Yes, your assessment is correct.

3) When DP83867E is in active 1000BASE-T mode (Ethernet link is up), TDR is not possible.
[Gokul]: Yes. When we enable TDR on DUT, link is dropped and the Link Partner enters autoneg mode again.

4) When PORT_MIRROR_EN is set to 1 in CFG4 register, C and D pairs become terminated, A and B pairs become un-terminated (when DP83867E is in auto-negotiation stage without an active link partner).
[Gokul]: Yes.

I have a question about why we want to enable MDI termination and disable transmit on all the channels. Can't we just disable the link partner (or put the link partner in RESET mode) and carry on the TDR testing? The result will then indicate that all channels are open where the length at which the open is indicated is equal to the total cable length.

Please share your thoughts on the solution above.

--
Regards,
Gokul.

Hi Gokul,

thank You for the answer.

The proposed solution (link partner of the type DP83867E being powered-down or RESET) is unfortunately very inconvenient in our applications. Please let me explain why:

1. At first please assume all the tests are performed automatically by software means and nobody is physically present at the site where the devices are.

2. You do not have an idea, what is the length of a cable.

3. If the TDR result is no or very little reflection (SNLA253 How to use the TDR Feature of DP83822, paragraph 2.2.3 Link Partner Down), you can be sure the cable is OK. On the contrary, if there is a reflection, it can be caused for example by:
  a) Interrupted cable somewhere in the middle.
  b) Bad or forgotten contact crimping in a connector.
  c) Loosened or felt out connector.
  d) DP83867E powered-down or RESET.
 
4. When you need to put link partner of the type of DP83867E to RESET to perform TDR, you have to have working Ethernet communication with the partner (typically, you do not have any other connection to devices than Ethernet) and write some complex software to synchronize both sides of the link (which could be impossible if the link is malfunctioning) during the test.

All the points cause the execution and evaluation of the test very complex and based on guesses. Sometimes you realize you cannot distinguish if the cable and connectors are OK or not.

On the contrary, Ethernet PHYs which terminate all MDI pairs permanently when powered on are actually very easy to be used as link partners for TDR. The PHY performing TDR can just:

A. Link-down by setting BMCR register to 0x0140. This automatically leads the link-partner to go quiet at most after 1 second. You do not need any other communication with the partner.

B. Perform the TDR after one second. In practice, it is not important if the link partner is still completely quiet (preferred) or already transmits auto-negotiation pulses. By try & fail we've deduced, because the auto-negotiation pulses are very sparse, they do not interfere with TDR enough to affect the results.

C. If there is no reflection, you can be sure the cable and connectors are good. Actually, this is even possible with DP83867E as link partner for TDR, but only on pairs A & B (if we can't find a way to enable C & D MDI termination).

--

Best Wishes,

Cyril

Hi Cyril,

Thanks for the detailed explanation. I now can understand the system level problems with the solution I thought of.

Let me discuss this with the team and get back to you by next Tuesday (12-Apr).

--
Regards,
Gokul.

Hi Cyril,

I would suggest running TDR on channels A,B first and then enabling mirror mode and both DUT and link partner and running the TDR again.
But I understand the problem is event synchronization of writing registers on DUT and link partner together.

All the solutions I can think of, include programming both DUT and LP. where we face the same issue.
I can't think of any other work around as the device DP83867E doesn't have a mode where terminations are enabled by default on all the channels.

All the channels and their terminations are enabled in 1000Base-T mode, but once TDR is initiated on the DUT, LP goes back to auto-negotiation and terminations are switched off on channels C,D.

Is there a way, you can synchronize events and program registers on DUT and LP together while running the TDR test?

--
Regards,
Gokul.

Hi Gokul,

meanwhile we've found the most simple way to configure DP83867E as the link-partner seems to be to disable auto-negotiation and set speed to 1000 Mbps. In this settings, all MDI pairs (A, B, C and D) are terminated. Unfortunately, because auto-negotiation is mandatory for 1000BASE-T, the LP is not able to link-up with the settings, so we can't set this mode permanently.

If we would be able to synchronize events on both LP and DUT, the solution would be:

  1. set LP's BMCR to 0x0140,
  2. perform TDR from DUT,
  3. restore LP's BMCR (0x1140 typically).

We are able to incorporate any software to both LP and DUT. But LP and DUT are connected only by Ethernet and we need to run the TDR cable test especially when the Ethernet connection of LP to DUT is broken. So, the event synchronization is almost impossible (no non-crazy idea comes to our minds yet). We are able to do the synchronization only in those cases, where we have for example multiple redundant Ethernet links between LP and DUT and at least one of them functional.

--
Cyril

Hi Cyril,

I agree with your analysis. Even, my thoughts are also the same regarding the event synchronization.

I couldn't think of any solution to synchronize the events. I'll let you know if I could think of something.

--
Regards,
Gokul.