• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 516 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.

DP83867CR: RX Timing Budget Clarification

Mitchell
Expert 4915 points

Part Number: DP83867CR

Hi Team,

My customer is experiencing some issues with the DP83867CR that are mostly related to Receive data. In an effort to determine the root cause we are investigating the timing budget on the RGMII interface, per SNLA243.

The document provides an example and some specs to determine the TX timing budget; however, we are also interested in understanding the RX timing budget. I'd like to get some clarity on the following timing parameters and understand if they hold true for the RX interface:

  • IDvar = 0.2ns for TX --> is this also true for the output of DP83867 on the RX interface?
  • IOskew = 0.35ns for TX --> is this also true for the output of DP83867 on the RX interface?
  • TskewT = 0.5ns for TX --> is this also rue for the output of DP83867 on the RX interface?

Thanks,
Mitchell

  • 0
    TI__Mastermind 26320 points
    Hi Mitchell,

    Yes, skew requirements between data and clock are same on both Transmit and Recieve of RGMII. See below RGMII interface specifications.

    e2e.ti.com/.../RGMIIv1_5F00_3.pdf


    While configuring the internal delay, ensure either MAC or PHY is introducing the delays in each direction.

    Regards,
    Geet
  • 0 in reply to Geet Modi
    TI__Expert 4915 points
    Hi Geet,

    Thanks for the feedback. I just have 2 more points to clarify.

    When DP83867 is the transmitter (Rx data):

    • Is IDvar timing parameter ignored (i.e. is IDvar included in the +/-500ps TskewT)?
    • Is IOskew ignored (i.e. is IOskew included in the receive side setup/hold parameters)?

    Thanks,
    Mitchell
  • 0 in reply to Mitchell
    TI__Mastermind 26320 points
    Hi Mitchell,

    IDvar is variation in delay which may be seen from Transmitter IOs. This along with pcb delay shall be looked at Receiver while calcuating the setup/hold worst case timing.

    IOSkew, it would say yes, this shall be part of the overall skew requirement at receiver side.

    Regards,
    Geet
  • 0 in reply to Geet Modi
    TI__Expert 4915 points
    Hi Geet,

    Thank you. Just one more point to clarify - in the case where for RGMII Receive (DP83867 is transmitting data out on the Rx data lines) -AND- the DP83867 is adding the internal delay, do we need to account for both IDvar AND TskewT?

    i.e. – is the clock to data skew out of DP83867 with internal delay added +/- 700ps (Tskewt (500ps) + IDvar (200ps))?

    Thanks,
    Mitchell
  • 0 in reply to Mitchell
    TI__Mastermind 26320 points
    Hi Mitchell,

    The values ( IDvar, IOskew etc) defined in app note are example values to help explain the RGMII timing margins.

    I think, customer shall focus on the Setup and hold time at Receiver data and clock pins. These measurement values shall be within the RGMII spec defined in DP83867 datasheet.



    regards,
    Geet