UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
5,530 Views
Registered: ‎01-22-2015

input-clock jitter effect on timing analysis

Jump to solution

The input-clock to my Kintex-7 comes from a crystal oscillator with jitter specified at <10ps. The Vivado Clocking Wizard (MMCM) estimates jitter for the output-clocks to be in the range of 80 -160ps. If I specify the input-clock jitter to be 20ps (instead of 10ps), then output-clock jitter reported by the Clocking Wizard changes by only a few ps.

 

So, it seems that jitter produced by the MMCM itself (and not jitter of the input-clock) will usually be the dominant part of the jitter-value used for timing analysis?

 

I'm trying to ensure that jitter of the input-clock does not significantly affect timing analysis.  Any advice or cautions in this regard?

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
9,583 Views
Registered: ‎01-23-2009

Re: input-clock jitter effect on timing analysis

Jump to solution

So, two things....

 

First, most oscillators specify jitter as RMS jitter; a probabilistic measure. Vivado, however, needs cycle-cycle jitter. So when you use the set_input_jitter command you need to convert your RMS jitter to cycle-cycle jitter. This is determined by your minimum tolerable Mean-Time-Between-Failures (MTBF), but can often be a factor of 10 or more (cycle-cycle jitter = 10 * RMS jitter). So your RMS jitter of 10ps is really 100ps of cycle-cycle jitter.

 

Second, the MMCM has an analog low pass filter on the feedback path. Therefore it is pretty damned good at filtering out input jitter. It is for this reason that there is a very weak correlation between input and output jitter of the MMCM (which is a good thing!).

 

Avrum

View solution in original post

0 Kudos
6 Replies
Highlighted
Scholar austin
Scholar
5,517 Views
Registered: ‎02-27-2008

Re: input-clock jitter effect on timing analysis

Jump to solution

mg,

 

Firstly, peak to peak jitter directly affects Fmax by removing 1/2 the value from the minimum period.  That then takes away from any slack.  So awhile back we added jitter to timing closure by getting the clock source jitter from the customer, accurately estimating what jitter is added or attenuated by the clocking resources, and the having a place holder for system jitter.

 

System jitter is the jitter added by all the substrate noise and voltage variation going on in a complex system.  It might be from 50 to 500 ps peak to peak.  It is typically below 100 ps in 16+.  Below 200 ps in 28nm.

 

Jitter adds quadratically.  So square root of the sums of the squares of all the values.

 

Depending on how good your power distribution network, how quiet your IOs, your clock source, any one element may be dominant.  But its affect on the total goes as the square root of the sum of the squares.  The dominant factor remains dominant.  The contributors seem unimportant (because they contribute less).

 

If the total is 100 ps, the tools will increase automatically the requirement to meet timing by 50 ps.

Austin Lesea
Principal Engineer
Xilinx San Jose
Historian
Historian
9,584 Views
Registered: ‎01-23-2009

Re: input-clock jitter effect on timing analysis

Jump to solution

So, two things....

 

First, most oscillators specify jitter as RMS jitter; a probabilistic measure. Vivado, however, needs cycle-cycle jitter. So when you use the set_input_jitter command you need to convert your RMS jitter to cycle-cycle jitter. This is determined by your minimum tolerable Mean-Time-Between-Failures (MTBF), but can often be a factor of 10 or more (cycle-cycle jitter = 10 * RMS jitter). So your RMS jitter of 10ps is really 100ps of cycle-cycle jitter.

 

Second, the MMCM has an analog low pass filter on the feedback path. Therefore it is pretty damned good at filtering out input jitter. It is for this reason that there is a very weak correlation between input and output jitter of the MMCM (which is a good thing!).

 

Avrum

View solution in original post

0 Kudos
Scholar austin
Scholar
5,473 Views
Registered: ‎02-27-2008

Re: input-clock jitter effect on timing analysis

Jump to solution

A caution,

 

The PLL does reduce jitter above 300 KHz.  Lower frequency components of jitter will not be attenuated.  Most (good) crystal oscillators will not have any significant jitter at the low or high end of the frequency spectrum.  But, swithcing power supply noise and ripple will likely be below 500 KHz, and cause AM to PM (jitter).  Good power integrity engineering, good signal integrity engineering is all required.

 

Jitter is the result of being sloppy with just about anything in the design.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
5,450 Views
Registered: ‎01-22-2015

Re: input-clock jitter effect on timing analysis

Jump to solution

Austin and Avrum,

 

So, in short summary:

  • use careful low-noise engineering for powering the FPGA+clock system and for routing the clock signal to the FPGA
  • in the Vivado Clocking Wizard, specify cycle-cycle jitter and not RMS jitter.

Got it (I hope).  Thanks!

 

As an aside, the manufacturer of my clock oscillator sent me plots of the oscillator’s phase noise spectrum, L(f), instead of a jitter value. Conversion from L(f) to RMS jitter is described nicely here where the calculations agreed with the on-line calculator results found here.

 

Austin: You mention that the PLL (MMCM?) does a poor job of filtering-off the low-frequency components of jitter coming from the input-clock. I note that the conversion from L(f) to RMS-jitter involves integration of L(f) over a frequency band (sometimes 100-10000 Hz). Can you say more about the importance of the low-frequency components? That is, over what frequency range should L(f) be integrated to get proper estimates of RMS-jitter?

 

Avrum: Can you suggest reading for the use of RMS-jitter and MTBF to get cycle-cycle jitter?

 

Thanks!

0 Kudos
Historian
Historian
5,441 Views
Registered: ‎01-23-2009

Re: input-clock jitter effect on timing analysis

Jump to solution

The RMS to cycle-cycle jitter table seems to be available from a fair number of places - this link seems to have one...

 

Avrum

0 Kudos
Scholar austin
Scholar
5,417 Views
Registered: ‎02-27-2008

Re: input-clock jitter effect on timing analysis

Jump to solution

RMS Jitter,

 

Is really the 'tip of the iceberg.'  As the negative peak causes data path errors (violate timing), that is what you should be looking at.

 

The frequency component is also of little importance, as a data error error is a data error.

 

The failure to meet timing is the extent of the negative peak.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos