cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
999068709169
Explorer
Explorer
1,651 Views
Registered: ‎09-08-2009

Spartan 7 input clock jitter requirement

Jump to solution

 

Where can I find the input clock jitter requirement.

  • I am using clock directly, no PLL (Input Clock from MicroController > MRCC > BUFG > global clock tree )
0 Kudos
1 Solution

Accepted Solutions
1,601 Views
Registered: ‎01-22-2015

@999068709169 

You will need to tell Vivado the jitter on your input clock by placing a set_input_jitter constraint (pg 1582, UG835, v2019.1) in the Vivado project XDC constraints file.  Then, your input clock jitter will be low enough if your project passes Vivado timing analysis.

Mark

View solution in original post

8 Replies
csattar
Moderator
Moderator
1,608 Views
Registered: ‎05-02-2017

 

hi @999068709169 ,

 

SRCC stands for Single Region Clock Capable, and MRCC stands for Multi Region Clock Capable.  FoOr those familiar with previous Xilinx FPGA families these are similar to the GCLK pins.  For those who are not familiar these pins are used for bring clocks in and out of the FPGA.  These pins are dedicated resources that reduce clock skew and jitter.  If you are clocking something out of the fabric, or reading something in with a reference clock, you want to put the clock on an SRCC or MRCC pin.  Take a look a the clocking guide to find out more about which each of these do i beleive we do not have clock jitter specification for MRCC pin.

 

 

for more info please see the below links

 

https://www.xilinx.com/support/answers/46493.html

 

 

Regards
Chandra sekhar
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if solution provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------
0 Kudos
1,602 Views
Registered: ‎01-22-2015

@999068709169 

You will need to tell Vivado the jitter on your input clock by placing a set_input_jitter constraint (pg 1582, UG835, v2019.1) in the Vivado project XDC constraints file.  Then, your input clock jitter will be low enough if your project passes Vivado timing analysis.

Mark

View solution in original post

999068709169
Explorer
Explorer
1,575 Views
Registered: ‎09-08-2009

Dear markg@prosensing.com 

I need to supply Vivado Period Jitter right? (not Tie jitter as a constraint)

1-  The TIE jitter measures how far each active edge of the clock varies from corresponding edge of an ideal clock
2-  The period jitter measures the maximum deviation of clock period of a clock cycle in the waveform over 10,000 clock cycles

 

PS: There are many jitter definitions (https://www.onsemi.com/pub/Collateral/AND8459-D.PDF)

0 Kudos
lowearthorbit
Scholar
Scholar
1,549 Views
Registered: ‎09-17-2018

Jitter is maximum peak to peak over a long interval,

Also known as MTIE.  It is added to all other sources of jitter quadratically, divided by two, and subtracted from all period constraints to allow the tool to always meet timing with positive slack.  It is all jitter:  deterministic and random.

The system jitter is something you need to measure, and then specify in the tools (the default is 100ps).  Until you do that, there is guarantee timing will be met.

l.e.o.

 

1,538 Views
Registered: ‎01-22-2015

@999068709169 

The Xilinx documentation is surprisingly unclear on the type of jitter used in set_input_jitter.  The clearest indication comes from the Summary tab of Clocking Wizard which shows units to be Peak-to-Peak (Pk-Pk).

Peak-to-Peak jitter is a combination of the measured RMS period-jitter for the clock and a desired value for Bit-Error-Rate (BER).  Generally we use the conversion that Pk-Pk jitter is 14 times the RMS period-jitter which implies a BER of 1 in 10^12.  For more information, see the following article.

https://pdfserv.maximintegrated.com/en/an/AN462.pdf

Tags (3)
lowearthorbit
Scholar
Scholar
1,498 Views
Registered: ‎09-17-2018

mg,

As I created the jitter tool flow to address what at that time was the number one customer issue (tool having positive slack yet designs failing not meeting timing) I realized that it was the peak negative jitter from all sources that the tools were ignorant of.

No amount of extra margin would solve the problem, as poor power integrity and poor signal integrity along with poor clock sources, internal switching, IO switching would create a nightmare.

No amount of clever math or statistics would make the problem go away.

So Vivado now represenst the best solution to what is still an annoying issue.  Unfortunately, the designer must actually measure jitter to guarantee timing closure.

l.e.o.

 

0 Kudos
999068709169
Explorer
Explorer
1,455 Views
Registered: ‎09-08-2009

markg@prosensing.com  and @lowearthorbit thanks for your replies. 

Assuming If clock is

  • 1ns late in the 1st clock cycle and
  • 1ns early in the 2nd clock cycle,  my period becomes literally 2 ns less. 

So, as a jitter value : should not I just add these values (peak to peak)

jitter = |max late| + |max early| 

instead of 14 * RMS.

 


jitter.gif

0 Kudos
1,432 Views
Registered: ‎01-22-2015

@999068709169 

Your professors would be proud of you for trying to find the deeper meaning of Pk-Pk jitter.  However, the meaning you describe lacks the necessary statistical karma. 😊

The fact is that our “stable” FPGA clocks do not have constant period.  That is, noise causes the clock period to sometimes be too long and to sometimes too short.  As shown in the Maxim Integrated paper that I gave you, this too-long/too-short behavior has statistical properties.  Many assume the statistics to be Gaussian, with the RMS value of clock jitter lying at the 1-sigma points of a Gaussian probability distribution.  That is, 63% of the time, the observed jitter on the clock will be less that the RMS value.  However, this means that 100-63=37% of the time, the observed jitter will be greater than the RMS value.  Unlike your calculation, there is no peak value of jitter under the Gaussian assumption.  That is, the observed jitter on any clock cycle could be almost any value – although the higher values have very low probability.

When we specify a value of clock jitter to Vivado, we are asking Vivado to tell us if circuits will pass timing analysis when jitter is less than the specified value.  Implied is the fact that we are willing to accept circuit glitches (ie. timing failures) when jitter is higher than the specified value of clock jitter.  This implied fact is a little scary because we certainly don’t want glitching to occur in the FPGA – ever!   So, to minimize glitching, the value of clock jitter that we give to Vivado should be much higher than the measured RMS jitter for the clock.  The theory in the Maxim Integrated paper says that if you tell Vivado the clock jitter is 14 times the RMS jitter and Vivado reports that the circuits pass timing analysis - then the FPGA is likely to glitch only 1 out of every 10^12 clock cycles (roughly).  So, if you are using a 100MHz clock, then you can expect a glitch ever 10^12 * 10ns = 27.7 hours.

So, that’s why we tell Vivado that clock jitter is roughly 14 times the measured RMS period jitter for a clock.

Mark