In the article Clock Uncertainty I mentioned that the command set_clock_uncertainty is used to account for among other things, clock jitter. Clock jitter is a characteristic of the clock source and the clock signal environment. It can be defined as “deviation of a clock edge from its ideal location.” Clock jitter is typically caused by clock generator circuitry, noise, power supply variations, interference from nearby circuitry etc. Jitter is a contributing factor to the design margin specified for timing closure.
Based on how it is measured in a system, jitter is of following types:
- Period jitter
Period jitter is the deviation in cycle time of a clock signal with respect to the ideal period over a number of randomly selected cycles(say 10K cycles). It can be specified an average value of of clock period deviation over the selected cycles(RMS value) or can be the difference between maximum deviation & minimum deviation within the selected group(peak-to-peak period jitter).
- Cycle to cycle jitter
C2C is the deviation in cycle of of two adjacent clock cycles over a random number of clock cycles. (say 10K). This is typically reported as a peak value within the random group.This is used to determine the high frequency jitter.
- Phase jitter
In frequency domain, the effect being measured is phase noise. It is the frequency domain representation of rapid, short-term, random fluctuations in the phase of a waveform. This can be translated to jitter values for use in digital design.
Please note all the above jitters are effectively the same phenomenon, but different way of measuring and representing the effect for use in design flow. The jitter number thus obtained is used to specify the design margin using the command “set_clock_uncertainty”.
Since the jitter affects the clock delay of the circuit and the time the clock is available at sync points, setup and hold of the path elements are affected by it. Depending on whether the jitter causes to clock to be slower or faster, there can be setup hold or setup violations in an otherwise timing clean system. This will in turn lead to performance or functional issues for the chip. So it is necessary that the designer knows the jitter values of the clock signal and account for it while analyzing timing.
Pingback: set_clock_uncertainty | VLSI Pro
Hi Pro, So an EYE diagram will be helpful to determine the max jitter in a system ? can you throw some light on this if you know more about the eye diagram.
The info you posted is very good and simple. I sincerely appreciate your efforts for sharing your knowledge.
Say, i have clock with frequency of 100K to 4MHz variation, how can i mention this variable clock frequency in sdc commands. If possible can you give me an example.
naga raju m
I think you have to specify the most stringent constraint 4MHz
but 4MHz will support only for setup calculation. what about for hold calculation.
say some signal propagating from other clock domain to this clk domain.
I have one question. Suppose any system is operating at clock having clock period of Tclk. Now due to power supply noise, there is +-1 % of Tclk clock jitter. At what frequency I should use for that system such a way that it will operate without any failure?
Can you explain how hold time will be affected by jitter?
hold time is a one cycle phenomena, so essentially we are not looking at 2 different edges of the clock.
For half cycle paths, it ll be affected, or for multicycle paths, in case we are not moving the hold edge to cycle 1.
But other than these 2 scenarios how will it affect hold time for regular full cycle paths?
I have one query for you. Consider the Clock period is X and jitter is Y . If the Clock period is doubled, then how the jitter will be scaled ?
Does Jitter effect hold timing also ? I dont think so as, hold check will be from edge 1 -> edge 1 only, am i right?
Yes, shouldn’t be added for hold checks
According to your post jitter should be added to setup and not added to hold uncertainty. By nature of jitter it will affect timing between different clock cycles, and won’t affect same-cycle events. By default setup timing infers different cycles and hold infers same cycle. But with multicycle applied that is not true anymore:
– multicycle hold check might require to account for jitter;
– multicycle 0 setup check (usefull in data to data check) is overconstrained due to added jitter.
What is correct approach to avoid problems described above?