It has been a long time since I have posted anything on jitter, and a customer question to a Xilinx Field Applications Engineer (FAE) has prompted me to revisit an old friend, or foe.
Jitter is the difference in the “significant instants” (the ITU definition) from a theoretical perfect clock reference, or a data stream if that is what you are interested in. The significant instants in this case are the rising or falling edges.
There are two types of jitter on the clock networks that the Xilinx tools keep track of and use to check if there is enough timing margin. They are:
In order to perform the calculations, the tools ask the user to supply the peak-to-peak jitter of the various clock oscillators supplying the device, typically 35 picoseconds peak to peak, and the added system jitter from all of the outputs and internal nodes that are switching. The tools then add in the DCM, PLL, and MCMM jitter, and present the results and a summary in the timing report.
When adding peak-to-peak values, one takes the square root of the sum of the squares, which is known as Quadratic Addition, as opposed to simple addition (i.e. 1 + 1 = 2).
The quadratic sum is: 1 + 1 = SQR(1^2 +1^2) or 1.414…, the square root of 2.
The quadratic sum is used when adding peak-to-peak values; whereas, if you had RMS (root mean square) values, you would use regular addition.
When anything switches, it requires some current, and that current leads to a tiny voltage drop, which ultimately means that the power supply is lessened. At each rising edge, all sources of these voltage drops add up and stretch out the clock (the devices get slower with lower voltage). All of this switching activity leads to system jitter. We cannot tell you what it is, so either you may make an educated guess based on past experience, or measure it. System jitter is never less than 100 picoseconds, peak to peak (ps p-p), and can be as much as 1000 ps p-p if absolutely everything, I/Os, BRAMs, DFFs, and DSPs switch on the same clock’s rising edge.
System jitter also increases with poor bypassing or layout of the power and ground planes and connections.
System jitter is measured by placing the clock to a DDR IOB, tying the top DFF D input to a ‘1’ and the bottom DFF D input to a ‘0’, and measuring the resulting signal at the I/O pin for jitter.
It is strongly recommended to use more than one edge of a clock. Pass it through the MMCM to obtain the 0, 90, 180, and 270 degree phases of the clock. Use ¼ of the value you are using to switch on each phase (not all at once). Ensure proper timing by using the correct timing constraints between the four phase regions. Include I/Os in this system jitter reduction design method.
The jitter from the DCM was long ago realized to be “different” from the types of jitter we had seen before. The jitter from the DCM was from the switching of the clock output from one tap to another tap of the delay line. This ‘tap dance’ led to discrete steps of time (~35 ps) on the clock. The use of the frequency synthesizer function introduced a wild and crazy ‘tap dance,’ leading to more jitter than just the phase tracking feature.
With the shift to using phase-locked loops (PLL) more and more, the Discrete Jitter is still used by the tools to account for the jitter added by the clocking resources (multi-mode clock manager, or MMCM).
So, do not be puzzled by the strange nomenclature of ‘Discrete Jitter,’ as it is only the jitter that is added by the clocking resources.
You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet, please register and log in.