cancel
Showing results for
Show  only  | Search instead for
Did you mean:
Voyager
942 Views
Registered: ‎05-25-2016

## How to estimate jitter on output pin?

Jump to solution

Hello,

I have what is probably a pretty straight forward question.  I have to use an older part and ISE for some other reasons, but I think I'm just likely missing some fundamentals.  I am bringing a clock into a global clock pin, it goes through a buffer, into a DCM then into a PLL then out of a buffer out of the FPGA to another chip.  I need to wrap my head around how to estimate jitter on the output pin.  Long story short I'm trying to figure out if the clock running through the FPGA will induce too much jitter and violate the jitter spec  of the chip the FPGA is providing a clock to.  I've made an example project in ISE to try to get ISE to produce some numbers for me to use as rough estimates.

Here is a picture of my test project

I've attached my constraints file where I define the clock period and INPUT_JITTER value.  There isn't much to them they are shown below:

``````# Clock Uncertainty = [((System Jitter^2) + (Input Jitter^2)) ^ (1/2) + DCM Jitter] / 2 + DCM Phase Error

#MODEL "Top" SYSTEM_JITTER = 100 ps;
NET "clk" TNM_NET = "clk";
NET "clk" PERIOD = 10 INPUT_JITTER 300 ps;
#TIMESPEC TS_clk = PERIOD "clk" 10 ns HIGH 50% INPUT_JITTER 100 ps;``````

So far I can see in my timing report that there are some "clock uncertainty" values as shown in my timing report and below for the counter I stuck in the 2 bit counter block (just for testing).

So my ultimate questions are:

1. what does the above clock uncertainty (jitter) represent?  Is this the jitter at the flipflop clock pin that drives the "strobe" output signal?

2. How do I ultimately come up with an estimate of the clock jitter at "Ex Clk Out" pin?  I need an estimate here that will tell me what amount of jitter will be added or attenuated due to the DCM, PLL and internal fabric effects.

3. I can't seem to find any jitter info aside from the uncertainty related to the flip flops in the little example counter block.  Where do you find resulting output pin jitter?

1 Solution

Accepted Solutions
Guide
886 Views
Registered: ‎01-22-2015

Xilinx documentation has little to say about jitter.  However, I have deduced some things from experimentation with Vivado that may apply to your questions about jitter in ISE.

1. When using a PLL to create clocks, it is usually the PLL itself that determines the clock jitter.  That is, jitter for the PLL input clock has little effect on jitter for the PLL output clock.
2. In Vivado, we setup the PLL using a Clocking Wizard.  The final tab of the Clocking Wizard tells us the jitter on the PLL output clocks.  Also, the Clocking Wizard tells us that this is Peak-to-Peak (Pk-Pk) jitter (which is about 14x the RMS jitter).
3. In the Timing Report that you show, the Discrete Jitter (DJ) term found under Clock Uncertainty is the Peak-to-Peak jitter for the PLL output clock reported by the Clocking Wizard.

So, based on what you have shown, it appears that the PLL output clock has 0.177ns Pk-Pk jitter.  This is a strongly dominant factor in the calculation of the Clock Uncertainty shown in the Timing Report.  That is, other things found in the FPGA seem to have little effect on the jitter for the PLL-created clock.  So, I suspect that the PLL-created clock that you send out of the FPGA will have very nearly 0.177ns Pk-Pk jitter.

Cheers,
Mark

Tags (2)
6 Replies
Guide
887 Views
Registered: ‎01-22-2015

Xilinx documentation has little to say about jitter.  However, I have deduced some things from experimentation with Vivado that may apply to your questions about jitter in ISE.

1. When using a PLL to create clocks, it is usually the PLL itself that determines the clock jitter.  That is, jitter for the PLL input clock has little effect on jitter for the PLL output clock.
2. In Vivado, we setup the PLL using a Clocking Wizard.  The final tab of the Clocking Wizard tells us the jitter on the PLL output clocks.  Also, the Clocking Wizard tells us that this is Peak-to-Peak (Pk-Pk) jitter (which is about 14x the RMS jitter).
3. In the Timing Report that you show, the Discrete Jitter (DJ) term found under Clock Uncertainty is the Peak-to-Peak jitter for the PLL output clock reported by the Clocking Wizard.

So, based on what you have shown, it appears that the PLL output clock has 0.177ns Pk-Pk jitter.  This is a strongly dominant factor in the calculation of the Clock Uncertainty shown in the Timing Report.  That is, other things found in the FPGA seem to have little effect on the jitter for the PLL-created clock.  So, I suspect that the PLL-created clock that you send out of the FPGA will have very nearly 0.177ns Pk-Pk jitter.

Cheers,
Mark

Tags (2)
Voyager
840 Views
Registered: ‎05-25-2016

Hi Mark,

Thanks very much for taking the time to comment!  Your comment was very helpful.  This might be a dumb question, but wouldn't clock uncertainty be the total jitter number I would be interested in?  If so, why do we use a quadratic sum AND divide by 2?  What I'm referring to below:

``Clock Uncertainty:          0.095ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE ``

Is clock uncertainty still in a peak to peak form after this calculation?

Also, I found a quite exceptional post by you here:

which has a fantastic example very similar to what I'm trying to do.  I noticed you used one of the data registers to check the clock uncertainty.  I initially assumed you needed to somehow get a timing result at the actual output pin, but in you previous post it sounds like you can check the jitter at the final ODDR data bit register and use that number.  Is that because the output jitter on the pin will basically be the jitter shown at the ODDR register and so really you just check the jitter value at the last output register and assume that will be what is on the pin as well?

Thanks again - this is very enlightening!

Guide
799 Views
Registered: ‎01-22-2015

This might be a dumb question, but wouldn't clock uncertainty be the total jitter number I would be interested in?  If so, why do we use a quadratic sum AND divide by 2?

-not dumb at all.  I have been pestering Xilinx (outside the Forum) for theoretical details of the Clock Uncertainty equation.  Here is my understanding:

1. The TSJ and DJ terms are the standard deviation of independent sources of zero-mean noise with Gaussian statistics.  When you add noise from two independent zero-mean Gaussian sources then you add the variances - and variance = (standard deviation)^2.  So, it makes sense that the total standard deviation of noise resulting from the sum of these two terms should be (TSJ^2 + DJ^2)^0.5.
2. The "divide by 2" part does not make sense to me.  I was told by Xilinx that, "For setup you get 1/2 of the RMS jitter and for hold you get 1/2 of the RMS jitter. On your total timing budget, the jitter is complete (1/2+1/2=1)."
3. The PE part of Clock Uncertainty is also a little mysterious.  You will find in the timing reports that PE=0 for intra-clock timing paths and the PE=0.120ns for some inter-clock timing paths.
4. I believe that the PE=0.120ns comes from the MMCM specification, MMCM_TSTATPHAOFFSET = 0.120ns.  I am told that MMCM_TSTATPHAOFFSET is the potential phase difference of between outputs of a MMCM that doesn't change after power-up.  That is, it is a random phase bias on the MMCM outputs that occurs at power-up of the MMCM.  It is strange to me that a bias enters into the calculation of a random process (jitter).

So, I still have lots of uncertainty about the "Clock Uncertainty" equation used in Vivado.  However, I think we should consider the Clock Uncertainty equation to be something specifically designed for Vivado timing analysis.

If you are sending a clock from an MMCM out of the FPGA then we should calculate the Pk-Pk jitter on this clock as (TSJ^2 + DJ^2)^0.5 which is approximately equal to DJ (since TSJ^2 << DJ^2) - and we should not use the entire Clock Uncertainty equation to calculate clock jitter.

...but in you previous post it sounds like you can check the jitter at the final ODDR data bit register and use that number.

I'm glad you found the other post to be helpful.  However, please remember that, like you, I am still searching for answers to all of this.  However, the point in that post is the same as my point above.  The Pk-Pk jitter on the clock at the ODDR is estimated as (TSJ^2 + DJ^2)^0.5 where you get TSJ and DJ from the Vivado timing report that includes the ODDR.

You might also find the following post about calculating jitter from phase noise to be helpful.

Voyager
766 Views
Registered: ‎05-25-2016

Hey Mark,

Thanks again!  I'm still reading through links I found from your link above.

I wanted to get your thoughts regarding the division by 2.  I think Xilinx might be dividing by 2 as we discussed because the peak to peak jitter value covers 50% jitter before the idea clock edge and 50% jitter after the ideal clock edge.  When the timing engine is calculating setup time it just needs the jitter before the expected or target clock edge.  So you can throw away half of the jitter value there because half of it occurs after the target/ideal clock edge?

Also, I found a very very good article from Tektronix

https://www.tek.com/primer/understanding-and-characterizing-timing-jitter-primer

Voyager
760 Views
Registered: ‎05-25-2016

One additional question regarding terms you may  be able to help me with...

I'm seeing the starting point for jitter analysis is phase noise plots.  These plots seem to show power vs frequency.  From this you integrate under this curve (within some bandwidth) to get jitter which is an amount of "time" error.

Does this process of integrating the area under the frequency curve basically just allow you to translate the phase information (in frequency) to time in seconds?  It looks like there is a process here that I"m picking up on that starts with phase noise spectrum plots and ends with jitter error margins in units of seconds.  If you have a good handle on this could you elaborate?

Guide
726 Views
Registered: ‎01-22-2015

Does this process of integrating the area under the frequency curve basically just allow you to translate the phase information (in frequency) to time in seconds?

Yes, basically.  Here is another good article that explains how you use the frequency spectrum of your clock waveform to estimate jitter.