• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 34 subscribers
  • Views 195 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.

DP83867IR: RX_CTRL behavior when IFG is less than minimum required time(96ns)

Shota Mago
Expert 8470 points
Part Number: DP83867IR


Hi team,

My customer would like to make sure behavior of RX_CTRL signal when IFG(Interframe Gap) is shorter than minimum required time, which is 96ns(=12 clk x 8ns/clk).

[Background]

They're performing ethernet communication via switching hub. Each master and slave equipment uses DP83867IR for PHY.

When transmitting data which exeeds max payload size of ethernet frame, the frame is divided. For this example, the frame is divided into 3 frames. 

Sometime, the data frame transmitted from HUB excibits IFG, which is shorter than minimum required time(96ns). In this case, RX_CTRL signal of DP83867IR at Rx side toggles High/Low, indicating receive error. They repeat transmit data periodicaly(roughly several 10 ms) and the issue occurs about a few minutes later.

image.png

[Waveforms]

image.png

IFG of Tx side(above i and k) was about 96ns.

Above i: IFG of Tx side was about 96ns

image.png

Above k: IFG of Tx side was about 95.7ns

image.png

When the issue occurs, IFG(above j and l) was clearly less than 96ns.

Above j: IFG of Rx side was 79.9ns.

image.png

Above l: IFG of Rx side was 68.0ns.

image.png

[Questions]

  1. When IFG is shorter than specified minimum value(96ns), RX_CTRL signal toggles High/Low like above waveforms while receiving data frame. Is this expected behavior?
  2. Is there any register which can change minimum required IFG in the PHY?
  3. For RX side, second and third IFG were 68ns, but when receiving theird frame, RX_CTRL signal sticked to High. 
    Is this expected behavior?

Best regards,
Shota Mago

  • 0
    TI__Mastermind 21426 points

    Hi Mago-san, 

    1. RX_CTRL is a combination of RX_DV and RX_ER. On the rising edge of RX_CLK, RX_DV is indicated and on the falling edge RXDV xor RXER in RGMII mode. Without RX_CLK, it would be hard to tell if RX_CTRL is toggling because the PHY sees error on the data frame or because the data is valid.

    2. For copper connection, register 53h bit[3:0] is known to decrease the required IPG on the PHY's end. The default value if 5 and the lowest the PHY can support is 3. 

    3. As previously mentioned, RX_CTRL is a combination of RX_DV and RX_ER depending on the RX_CLK edge. Because RX_CTRL is high on both edges, it could be that the PHY sees the valid packet. In this case, was the customer seeing errors on the MAC side?

    Best,
    J

  • 0
    Prodigy 40 points

    Hi J-san,

    Thank you for your response.

    **********
    1.

    The waveforms of the RX_CTRL and RX_CLK signals are shown below.

    Also shown below is an enlarged image of the point where the IFG was shorter than 96 ns.



    Please note that bit[3:0] of the DP83867IR's RGMIIDCTL register (Address 0x0086) are set to "1000b," which means that RX_CLK has a delay time of 2.25 ns.
    Taking the RX_CLK delay into account, it appears that RX_CTRL changes to low on the falling edge of RX_CLK.
    Is this behavior when the IFG is shorter than the specified minimum value (96 ns)?

    **********
    2.
    Thank you for the information about the VTM_CFG register (Address 0x0053).

    **********
    3.
    I'm currently checking the status on the MAC side.
    I'll get back to you after checking.

    **********


    Best regards,
    Nakamura

  • 0 in reply to Takayuki Nakamura
    TI__Mastermind 21426 points

    Hi Nakamura-san, 

    Thank you for the reply. 

    Takayuki Nakamura said:
    Taking the RX_CLK delay into account, it appears that RX_CTRL changes to low on the falling edge of RX_CLK.
    Is this behavior when the IFG is shorter than the specified minimum value (96 ns)?

    In this case, this would mean that both RX_ER and RX_DV are high. This can be one of the expected behaviors for shorter IPG. 
    The PHY's minimum IPG threshold can be changed by modifying register 0053[3:0]. The default value is 5 (12 bytes) and can be lowered to 3 (10 bytes). Could you modify this value to see if RX_CTRL behavior changes?

    Best,
    J

  • 0 in reply to J
    Prodigy 40 points

    Hi J-san,

    J said:
    3. As previously mentioned, RX_CTRL is a combination of RX_DV and RX_ER depending on the RX_CLK edge. Because RX_CTRL is high on both edges, it could be that the PHY sees the valid packet. In this case, was the customer seeing errors on the MAC side?

    When I checked the MAC side, I found that the third packet was received as a valid packet by the MAC.
    At this time, the VTM_CFG register was still at its default value.
    The IPG between the second packet (error packet) and the third packet was 68 ns, but the PHY seemed to be able to receive the third packet as valid packets.
    Is this behavior expected from the PHY?


    J said:
    The PHY's minimum IPG threshold can be changed by modifying register 0053[3:0]. The default value is 5 (12 bytes) and can be lowered to 3 (10 bytes). Could you modify this value to see if RX_CTRL behavior changes?

    I have set the value of the VTM_CFG register to 3 and am currently investigating.
    I will contact you again once the results are available.

    Best regards,
    Nakamura

  • 0 in reply to Takayuki Nakamura
    TI__Mastermind 21426 points

    Hi Nakamura-san, 

    Takayuki Nakamura said:
    When I checked the MAC side, I found that the third packet was received as a valid packet by the MAC.
    At this time, the VTM_CFG register was still at its default value.
    The IPG between the second packet (error packet) and the third packet was 68 ns, but the PHY seemed to be able to receive the third packet as valid packets.
    Is this behavior expected from the PHY?


    This can be an expected behavior because the PHY saw the second packet as an invalid packet so the IPG counter may not have resetted so it may have thought that the next incoming PHY to have an IPG greater than 96ns instead of 68ns. 

    Please let me know once the results are available. 

    Best,
    J

  • 0 in reply to J
    Prodigy 40 points

    Hi J-san,

    After changing the VTM_CFG register value to 0x3, the device was operated for 24 hours and no errors occurred even when receiving 80 ns IPG packets.
    I have confirmed the effectiveness of changing the VTM_CFG register.

    I have additional questions.
    - Can you please point me to any documentation that states that the minimum value of the VTM_CFG register is 0x3? Also, please explain why the minimum value is 0x3. I was unable to determine this from the datasheet.
    - Please let me know if you can think of any concerns about setting the VTM_CFG register value to 0x3.

    Best regards,
    Nakamura

  • 0 in reply to Takayuki Nakamura
    TI__Mastermind 21426 points

    Hi Nakamura-san,

    There is no official documentation of the minimum value unfortunately at this moment. Theoretically, the value can go lower but we have seen in previous customer cases and internal validation afterwards that lower value than 3 caused issues with the PHY.

    There is no concern for setting the value to 3. That value is the known lowest threshold that the PHY can handle.

    Best,

    J

  • 0 in reply to J
    Prodigy 40 points

    Hi J-san,

    Thank you for explaining why the minimum value is 0x3.
    I will change the setting to 0x3.
    For reference, could you tell me about any PHY issues that customers or internal validation have encountered when setting it to 0x2 or 0x1?

    Best regards,
    Nakamura

  • 0 in reply to Takayuki Nakamura
    TI__Mastermind 21426 points

    Hi Nakamura-san, 

    As far as I know, we have seen cases in which invalid packets were being read as a valid packet by the PHY when the threshold was too low. 0x3 has been a configuration that was validated and reported by customers that doesn't cause issue functionally over a period of time. 

    Best,
    J