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.

DP83867IR: Ping error caused by Fast Link Drop

Part Number: DP83867IR

Tool/software:

Hi Team,

Is it possible that FLD mode could cause more frequent Ping errors?

Ping errors will not reach 0% in customer system.

They performed various verification, and when they changed the mode of CRS strap setting from "2" to "1", the ping error decreased.
Mode 1: Fast Link Drop is disabled
Mode 2: Fast Link Drop is enabled

A different board using the same PHY, CPU with the same kernel, and RGMII mode had 0% ping errors.
CRS is not used in RGMII mode so we think that ping successes when Fast Link Drop is disabled.

Based on the above, we think FLP is suspicious.

The customer is using DP83867IRPAPT with 1000BASE, GMII.

Best Regards,

  • Hi Takahashi-san,

    FLD can cause issues for 1000Base-T during link-up process.

    Please try linking up while strapped with CRS = Mode 1, then enabling FLD with 0x2D[14] = '1' and noting any ping / throughput errors.

    Thank you,

    Evan

  • Hi Evan-san,

    Thank you for your advice.

    I'll check that.

    Just to be sure, are you saying that it's not Fast Link Detect but Fast Link Drop that can cause issues during the link up process?

    If so, please tell me the mechanism.

  • Hi Takahashi-san,

    Just to be sure, are you saying that it's not Fast Link Detect but Fast Link Drop that can cause issues during the link up process?

    FLD functionality in Gigabit can affect link-up process, but is expected to function normally when enabling after link is established.

    I do not have details on the exact mechanism, there are a few criteria for Fast Link Drop that may have false positives triggered during link up process:

    Thank you,

    Evan

  • Hi Evan-san,

    We found it difficult for the customer to try what you advise.

    However, we need to explain the mechanism of this issue to them.

    Could you tell me the details about it as long as you could?

  • Hi Takahashi-san,

    Can you clarify the challenge for testing CRS mode 1, and 0x2D[14] = '1' after link up?

    Fast Link Drop has several conditions for link drop (descrambler loss sync, RX errors, MLT3 errors, SNR level, signal/energy lost).

    There is an internal threshold defined for each of these conditions - the PHY will drop link if the threshold is met while FLD is enabled.

    In the Gigabit case, at least one of these conditions is being triggered during link-up process, causing FLD to actively drop link before link-up can complete.

    For this, we recommend disabling FLD in Gigabit until link-up has completed.

    Thank you,

    Evan

  • Hi Evan-san,

    I'm sorry for the late reply.

    The customer cannot spare the time to do this research due to resource.

    I would like to clarify why this issue causes Ping error.

    If a FLP occurs during link up,
    - will communication do with unstable link state?
    - can link drops occur periodically after link establishment?

    The important thing in this case is that a Ping error occurs during link up.

  • Hi Takahashi-san,

    No worries.

    If a FLP occurs during link up,
    - will communication do with unstable link state?
    - can link drops occur periodically after link establishment?

    1) The PHY will attempt communication during unstable link state, but there will not be good throughput without errors until stable link.

    2) After link establishment, link drop could occur due to normal FLD conditions (descrambler loss sync, RX errors, MLT3 errors, ...). However, these conditions are not expected to flag if following proper layout / schematic recommendations.

    Thank you,

    Evan