This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867E: Gigabit amplitude below spec

Part Number: DP83867E

We have a design using two DP83867E Phys (connected together with the internal switch of a T1020 CPU via SGMII). Generally the design works very well. However, there are a few specific problematic cases that we have observed, possibly with the same or related root causes.  With one link partner our device consistently takes several times longer to negotiate a link and the link doesn't always seem to work properly. With another link partner, the pair polarity and MDIX mode resulting from auto-negotiation varies significantly and the link often doesn't work even after it claims auto-negotiation completed successfully.  We had our device analyzed using a PVA-3000 PhyView®Analyzer from Sifos and the resulting report showed that the TX amplitude in Gigabit mode was over 2db below nominal on all pairs, at about 1.2V P-P.  I'm not sure if this is related to the symptoms we are seeing, but it seems plausible. Both of the ports on our device use a different Jack, both with integrated magnetics, but since both ports behave the same even with these different Jack/magnetics parts, I don't believe that is the issue. For reference, one part is Bel 0821-1C1T-43, and the other is Wurth 7499111221A.

I was hoping to find a way to tune the transmission power or amplitude of the DP83867E but I didn't see anything in any documentation about that. I'm also looking for any other information on diagnosing problematic links. I have compared a register dump from working and non-functional links and so far nothing has consistently stood out (besides the variations in auto-negotiation results cited above) that suggests a cause.  I have also verified the reference resistor value, the voltage across this resistor during operation, and the power supply voltages, and all are nominal.

  • Hi,

    With the Llink partner taking longer time, can you check by disabling the Auto MDIX ?

    The long link up is factor of cable length as well sometimes. What is the cable length you are using in your test ? Have you tried with various cable lengths.

    Regards,

    Geet

  • I will do some testing with Auto-MDIX disabled.

    We had already done some cable length investigation and it was actually related: it seems that when we use short (1-3ft) cables, the issue is much more pronounced. It seems to almost completely go away when we use a 5ft or longer cable. 

    However, cable length didn't seem to be a factor with the other link partner. But I will try disabling Auto-MDIX in that case, too, since the resolution of that property varied.

  • Hi,

    Any updates from your test ?

    Regards,

    Geet

  • Hi,

    Can you try following configuration 

    Register Address 0x012C = 0x0E81

    Regards,
    Geet

  • Sorry for the delay on the testing results. I had a few other things come up that I had to take care of first.

    I put back a shorter cable on the device setup that seemed to take longer to negotiate. In the past we had been seeing some sporadic failures with a 3ft cable, but in my testing just now (even without any Phy Register changes) I was not able to readily reproduce a failure. However, I then switched back to a 1ft cable and it passed maybe 1% of the test runs.

    So then with the baseline failure re-established I tried a few things:

    1. Disable Auto-MDIX.

    2. Write register 0x012C as above.

    3. Combination of both.

    4. Switch to fixed MDIX instead of MDI.

    None of these yielded an appreciable improvement in the link-negotiation behavior with this partner device. I just started the last case, but so far it has yet to pass a run so it seems about the same.

    I can try adjusting any other number of settings, but ultimately we would ideally want something that auto-negotiated with all partners if possible.

    I haven not yet had a chance to set up the test for the other problematic device yet; I should be able to do that next week.

  • Thanks for the update.  You mean switching off Auto-MDIX is not helping to converge the link ?

    Is it link to size of the cables ?

    Regards,

    Geet

  • Geet,

    Correct, turning off Auto-MDIX did not help I this particular case. I have not yet had a chance to reconnect the other board to our device to see if changing that option has any bearing on that setup.

    The problem with the first board is indeed linked to the length of the cable.

    Using a 1ft cable works with:

    • our device connecting to network switches
    • our device connecting to other devices (though I don't know that we've extensively tested a large number of other devices with a 1ft cable, but we do regularly use shorter cables)
    • this problematic partner device connected directly to a network switch (we've tried a couple at least)

    However, using a 1ft cable between our device and this problematic partner device takes a long time to negotiate, and at least some of the time yields a non-functional link even though it says AN is complete.

    I have also been trying other manual configurations of the DP83867E in our device and have yet to find a configuration that works with this short cable to this partner device.

    Still gathering some more data as I have time, but if there are other specific tests you would like me to try, I can do that fairly easily now.

    -Brian

  • I also just confirmed that a 3ft cable works both at 1G and 100M with the first partner, yet with a 1ft cable I don't seem to be able to make a link at all, even forcing 100M.

  • However in earlier post you mentioned you are able to make link with 1 feet cable though it takes time to Link UP ?

    Regards,

    Geet

  • I thought we had seen instances where a link would come up with the 1ft cable with this partner, but I don't have complete documentation of what we had tried before and what had worked.  I also believe I was getting confused between the "AN Complete"/"Link Status" status bits and the "Local/Remote Receiver Status" bits. I have been paying more attention to more of the status bits in my more recent testing and I have not seen a case where the link comes up completely with the 1ft cable and this partner despite "AN Complete" and "Link Status" being set.  I am going to switch back to the 1ft now that I have verified the behavior is notably better with the 3ft cable (including both the status bits and functionality of the link) and do some more rigorous testing to see if I can ever get a working link with 1ft.

    -Brian

  • Thanks. I will wait for further update. 

    BTW, is 1 ft cable a practical use-case for you ?

    Regards,

    Geet

  • The 1ft cable is actually practical because our device and the partner device are often right next to each other and have other connections between each other.

    I have done some more digging and I apologize that my information before was incomplete and partially incorrect.

    Let me summarize:

    1. The first problematic link partner is actually forcing 100M on its side, I now realize, and thus the status bits (and AN behavior) I was expecting weren't valid. This board is actually regularly making a working link with the 1ft cable. However, I was able to reproduce a case where AN completed, both sides thought the link was up (at 100M), yet it didn't work at all, even after many minutes of letting it sit, until either side restarted AN at which point it worked fine. 

    2. I have also started looking at the second problematic link partner again in more detail and I was also mistaken at how often it failed; it actually works most of the time, as well, but I have been able to reproduce some failures. I am still digging into this one, though, to make sure I have all the details straight, so I will report more on that one later. I can try (but have not yet tried) the suggested register writes with this partner.

    3. The original title and aspect of the question related to the Gigiabit amplitude is still of interest; the analysis we had done of our device is a little concerning and we aren't sure why the amplitude would be consistently low. However, the first case above is presumably not related to this given it's at 100M, and I don't know for sure if it's related to the second issue, either, but it is at least a possibility. Any ideas or tests related to this would be useful, though.

    A few more details on the first case:

    The problematic test sequence involves resetting the partner device, and the way its software works allows the device to make a link initially and then it resets its Phy again and reconfigures it without Gigabit enabled (because supposedly its Gigabit is not reliable). Since I was suspecting these restarts and changing AN parameters were confusing things, I tried a few combinations of:

    • Disabling Gigabit on our device
    • Not disabling Gigabit on the partner device
    • Adding a delay after disabling Gigabit on the partner device

    And none of those seemed to prevent it from eventually failing -- when using the shorter Ethernet cable.  It would regularly either take a long time to AN or it would appear to complete AN when the link wasn't working, but eventually recover. When it got into a state that didn't recover on its own (in a case where Gigabit was left enabled) the Idle Error Counter was continuously saturating. When left in the original configuration that reverted to 100M, it would often recover on its own but just now I had a case where our test failed, but then the link started working intermittently; ping is getting 43% packet loss right now.

    Now that I have a better handle on what is actually expected from this partner and a much more conclusive way of determining if it is in a working state, I will repeat the tests with the register changes.

  • Thanks for the update. 

    Let us know if you need any further assistance on this topic.


    Regards,
    Geet

  • Hi,

     

    I am closing this thread. In case you need further assistance, please open new thread and provide reference to this thread.

     

    Regards,

    Geet