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.

DP83848JSQ/NOPB clocking jitters tolerance

Other Parts Discussed in Thread: DP83848J

Hello folks,

  I am planning on using the DP83848JSQ Ethernet Transceiver to add Ethernet to a Xilinx Spartan 6 FPGA.

  The DP83848JSQ requests a 25Mhz clock.

  I am hoping to be able to cheat and use a PLL internall to the FPGA to synthesize this frequency in order to avoid finding an additional oscillator or crystal, subsequent second sources as well and to save space.

  The Xilinx PLL configuration wizard predicts a jitter of about 330pS coming out of the FPGA PLL.

  The appnotes and datasheet for the DP83848JSQ do not seem to be consistent with reguards to the max jitter the DP83848JSQ can tolerate.

The datasheet is cool with jitter up to 800pS.
file:///home/user/josh/SmartGaugeStuff/dp83848j.pdf

The appnote on the otherhand would prefer the jitter to stay under 200pS or even 25pS in the short term.
http://www.ti.com/lit/an/snla079c/snla079c.pdf

So what do ya'll recommend?  Is the Appnote overspected and the PLL is fine?  Or is higher jitter levels known for causing problems and I should really include a seperate oscilator for the DP83848JSQ?

~Joshua

  • Joshua,

    The jitter numbers shown in the design and layout guide, AN-1469 (Literature Number:  SNLA079C), represent best practice and are widely recommended.  The jitter numbers shown in the datasheet refer to another application note, AN-1548 (Literature Number:  SNLA091A), that focuses on reference clock jitter.  The reference clock jitter tolerance application note is available at:

    http://www.ti.com/litv/pdf/snla091a

    The intent of the reference clock jitter tolerance application note is to highlight two aspects of the design:

    1. The device can recover data from signals that have more jitter than is allowed by the IEEE specification.
    2. The device can still meet the IEEE specification for transmit jitter with reference clock jitter that exceeds best practice recommendations.

    Beyond reference clock jitter, there are many variables that will affect the robustness of the system - board layout, magnetics, cabling, link partner, etc.  Of these, the one that would concern me most is the link partner.  If you are operating in an open environment where you have no control over the link partner, it is best to design conservatively.  The DP83848 should be able to exceed the IEEE specification in terms of jitter and cable length, but if the partner cannot do so as well, you can still run into problems.

    Patrick

  • Thank you sir for your response. :-)

    ~Joshua