• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 2099 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.

DP83822H: RGMII RX_CLK & TX_CLK Internal Delay

Matt Zobel
Prodigy 80 points
Part Number: DP83822H



In the DP83822 datasheet it states there are delays the chip can add for TX_CLK and RX_CLK for proper RGMII operation.

In Table 37 it states the internal delay is 3.5ns relative to the data.  Why is the delay 3.5ns when the industry standard is 1.5ns of delay?

Is it because the device is only rated for 10/100 that delay can be greater? 

 

Is there a way to chose alternate delay values?  Most other PHY's have a way to choose different increments from 0.2ns to 1.0ns up to 3.5ns.

 

If I don’t use the internal delay, are you suggesting that 10” of trace be added to each clock trace (board delay ~160ps/in) to achieve a delay of only 1.5ns?

 

Thanks,


MZ

  • 0
    TI__Mastermind 19780 points

    Hi Matt,

    1.5 ns is standard when using the device in 1000M mode.

    As the DP83822 device is 100M only, the clock period is extremely long, and setting the delay close to the required 1 ns minimum su/hold time is unnecessarily risky.

    3.5 ns gives you a lot of margin with no risk to significantly degrading the other su/hold time.

    Is the 3.5 ns delay a problem in your design?

    Best Regards,

  • 0 in reply to Rob Rodrigues
    Prodigy 80 points

    My MAC is based off of a 10/100/1000 design with requirements to meet the gigabit speeds.  It is very difficult to get straight information from the other vendor with respect to only running at 10/100 speeds.  So, yes, for now 3.5ns is an issue.

    MZ

  • 0 in reply to Matt Zobel
    TI__Mastermind 19780 points
    Matt,

    The DP83822 delay is fixed to 3.5 ns. For the reasons above, I do not think this is an issue for a MAC that will be running at 100M. Hopefully your MAC vendor can confirm.

    Best Regards,