• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 34 subscribers
  • Views 260 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DP83822H: DP83822 send unwanted "next page" bit on the ethernet Auto-Negotiation Advertisement

DP83869HM: Autonegotiation optimizations / issues

Dominic Rath
Mastermind 7540 points
Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869, DP83867IR

Tool/software:

Dear TI team,

we're working with the DP83869HM PHY and are trying to reduce Ethernet autonegotiation time to achieve a faster link-up. Our use case requires only 100 Mbit/s full-duplex negotation. In the process, we've encountered a couple of issues and questions we hope you can help clarify:

1. ANAR Register (0x04) and Next Page Bit Behavior

We observed that the ANAR register (0x04), which controls the advertised abilities of the PHY, does not behave as expected. Specifically:

  • We set ANAR[15] (Next Page Ability) to 0
  • We renegotiate via BMCR[9]
  • Expectation: NP bit sent by the PHY reflects this change
  • Observation: NP bit sent by the PHY is still 1, regardless of the bit’s state in the ANAR register:

We have also tried to set ANAR[15] to 0 while the PHY is held in PWD_DWN state (BMCR[11]), but the observation is the same.

Q: Is this expected behavior for the DP83869HM?

Q: Could there be internal logic that overrides this bit, or are we possibly missing another related configuration?

2. Fast Autonegotiation (FAST_ANEG_EN in GEN_CFG4 - 0x1E)

We've come across the FAST_ANEG_EN bit in register GEN_CFG4 (0x1E), which appears to enable a fast autonegotiation feature. However, this feature is not thoroughly documented, so we would appreciate clarification on the following points:

The datasheet of the DP83867ir PHY (which we assume is "related" to the DP83869) includes the following note:

"While shortening these timer intervals may not cause problems in normal operation, there are certain situations where this may lead to problems."

We’d like to understand:

Q: What situations does this refer to?

Q: What kind of problems might occur when using Fast Autonegotiation or shortened timer intervals?

Q: Will longer timer intervals have better stability with PHYs that are not configured for FAST_ANEG?

Thanks in advance for your assistance and clarification.

Best regards,

Dominic

  • 0
    TI__Mastermind 25048 points

    Hi Dominic,

    1)

    Dominic Rath said:
    • We set ANAR[15] (Next Page Ability) to 0
    • We renegotiate via BMCR[9]
    • Expectation: NP bit sent by the PHY reflects this change
    • Observation: NP bit sent by the PHY is still 1, regardless of the bit’s state in the ANAR register:

    This is not expected, but I will confirm on our internal setup. Could you please share the register read-out of BMCR, ANAR, and waveform / link partner ANLPAR register showing NP=1?

    2)

    There are two cases where short timers with FAST_ANEG_EN may present issues:

    • Link Partner does not have FAST_ANEG enabled. Both link partners should match modes to avoid cases where handshake timers are mismatched, causing auto-negotiation errors
    • Poor link quality on MDI. With FAST_ANEG disabled, auto-negotiation link training process helps improve margins for link up. Enabling FAST_ANEG reduces link training time, potentially causing link issues when MDI link quality is poor (due to layout/schematic issues, cable faults, noise in environment, ...)

    Longer timers are recommended if the Link Partner does not have FAST_ANEG enabled. Generally, I recommend having FAST_ANEG disabled for stability if the Link Partner does not support.

    Could you clarify the issue you are observing? Is link/communication failing, and for what combination of modes between PHY and link partner?

    Mode PHY Link Partner Link / Communication Status
    FAST_ANEG Y Y ?
    N N ?
    Y N ?
    N Y ?

    Thank you,

    Evan 

  • 0 in reply to Evan Mayhew
    Mastermind 7540 points

    Hi Evan,

    thank you for your quick response.

    To clarify: we're not encountering any link issues at this time, but we have observed some interesting behavior during linkup timing optimization. Our main goal is to reduce the time for autonegotiation. One thing that could be optimized is not sending any next pages, because (based on our understanding) we wouldn't need any next pages for our use case (100 Mbps full-duplex only).

    Here is the info you have requested:

    1) Register Dump:

    • BMCR: 0x1140
    • ANAR: 0x01E1
    • ANLPAR (of Link Partner): 0xC1E1

    2) We haven’t observed any issues while using FAST_ANEG mode so far. However, we’d like to ensure our hardware remains compatible with other link partners, e.g. we can't gurarantee that there's a TI PHY on the other end of the link.

    Below is your table populated with our test results:

    Mode PHY Link Partner Link / Communication Status
    FAST_ANEG Y Y UP (duration not yet measured)
    N N UP (after ~2,664,598 usec)
    Y N UP (after ~397,839 usec)
    N Y UP (duration not yet measured)

    Is there any documentation available that explains exactly HOW FAST_ANEG affects autonegotiation? Does it deviate anywhere from the requirements in 802.3, or is it just "optimizing" timers to the smallest allowed setting?

    Let me know if you need further details.

    Best regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Mastermind 25048 points

    Hi Dominic,

    Thank you for sharing the requested data. To clarify, you are seeing the NP bit = 1 in the waveform itself, in addition to ANLPAR (of link partner) reporting receiving next page adv?

    Your understanding of FAST_ANEG "optimizing" timers is aligned with mine. The extent of interop tests for FAST_ANEG with various non-TI link partners is limited, so we cannot guarantee FAST_ANEG is compatible with all LP, depending on use-case and signal margins.

    Does your application allow configuring FAST_ANEG dynamically through software?
    E.g. -> attempt link up with FAST_ANEG default -> if link fails, disable FAST_ANEG.

    What is your application requirement for auto-negotiation time? I'd like to understand for trade-offs between interop confidence vs. aneg time.

    Thank you,
    Evan

  • 0 in reply to Evan Mayhew
    Mastermind 7540 points

    Hello Evan,

    Evan Mayhew said:
    Thank you for sharing the requested data. To clarify, you are seeing the NP bit = 1 in the waveform itself, in addition to ANLPAR (of link partner) reporting receiving next page adv?

    we're seeing the NP bit = 1 in the waveform and we're seeing subsequent next page transfers. The bit is also set in the ANLPAR of the link partner.

    Evan Mayhew said:
    Does your application allow configuring FAST_ANEG dynamically through software?
    E.g. -> attempt link up with FAST_ANEG default -> if link fails, disable FAST_ANEG.

    We'll think about that, thanks.

    Evan Mayhew said:
    What is your application requirement for auto-negotiation time? I'd like to understand for trade-offs between interop confidence vs. aneg time.

    This is for an EtherCAT SubDevice, so all link partners will only ever use 100 Mbit/s Full-Duplex, but we can't assume a particular PHY / PHY vendor on the link partner.

    The faster the better, but reliability is more important than time. What we were seeing was ~3 seconds for autonegotiation, but with a lot of variance of +-1 or 2 seconds. We looked at the DP83869 documentation, noticed the FAST_ANEG setting, and saw considerable improvements. Unfortunately it is basically undocumented.

    Do you think there's any chance of getting a reliable answer on what exactly FAST_ANEG changes? The idea is that if we understood what FAST_ANEG does, we could evaluate in what circumstances this might lead to problems, and if that is relevant for our use case.

    Regards,

    Dominic

  • 0 in reply to Dominic Rath
    TI__Mastermind 25048 points

    Hi Dominic,

    Thanks for clarifying.

    I am checking with internal teams to get more confidence on FAST_ANEG change list, and if we can expect reliable interop use-case with this feature enabled. I appreciate your patience here.

    Thank you,
    Evan