IntermediateQuestion 5 of 112

What's the difference between clock uncertainty and clock jitter?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Clock jitter is the clock edge itself wobbling from cycle to cycle at its source — a physical property of the clock generator (a PLL, for example) that the tool cannot derive on its own. Clock uncertainty is a margin the designer explicitly tells the tool to subtract from the setup or hold budget, using set_clock_uncertainty (SDC), to account for jitter plus other unmodeled effects like residual skew.

Clock jitter as a physical wobble at the PLL source versus the set_clock_uncertainty margin subtracted from the setup and hold budgets — Technical Reference DiagramWhat's the difference between clock uncertainty and clock jitter?

Technical Reference DiagramWhat's the difference between clock uncertainty and clock jitter?

Technical Explanation

Jitter is a physical fact about the clock source. Every real clock generator — a PLL, an oscillator — produces edges that land slightly earlier or later than the ideal period, cycle after cycle. This wobble is called jitter, and it exists whether or not the timing tool knows about it.
The tool cannot measure jitter on its own. Static timing analysis has no way to simulate a PLL's electrical behavior, so jitter has to be supplied as a number, usually from the clock generator's datasheet or a characterization measurement.
Clock uncertainty is where that number goes. set_clock_uncertainty (SDC) tells the tool to subtract a fixed margin from the setup check (and optionally add one to the hold check) to cover jitter, plus other effects the tool cannot fully model, such as any skew not yet captured by the current clock tree estimate.
They are not the same size. A clock's uncertainty value is usually set larger than jitter alone, since it also has to cover margin for OCV-style variation on the clock path and any other unmodeled effect the designer chooses to fold in.
Setup and hold get separate values. -setup and -hold options on set_clock_uncertainty let a designer apply different margins to each check, since jitter's impact and other uncertainty sources do not necessarily affect setup and hold equally.
What happens if uncertainty is left too small. A design can pass STA cleanly on paper and still fail in silicon if the clock uncertainty number understates real jitter — the margin only protects against what it is told to protect against.

Common Mistake

The Trap: Assuming set_clock_uncertainty automatically accounts for whatever jitter the clock source actually has.

The command applies exactly the number it is given — nothing more, nothing less.
If the designer copies a generic uncertainty value from a template instead of the real PLL's jitter specification, the tool will report clean slack on a path that has less real margin than the report suggests.

Follow-up Question & Model Response

If a PLL datasheet gives a jitter specification in picoseconds RMS, is that the number you should hand directly to set_clock_uncertainty?

Candidate Model Response: Not directly. An RMS jitter number describes a statistical spread, but STA needs a single deterministic margin, so it is standard to convert RMS jitter to a peak-to-peak or worst-case bound first, often using a multiplier from the PLL vendor's guidance, before folding it into the uncertainty value. The uncertainty number also typically needs to include margin beyond jitter alone, such as any skew the current clock tree estimate has not yet captured. Handing the raw RMS number to set_clock_uncertainty without that conversion under-margins the design and can let a real jitter-driven failure through STA looking clean.

Practical Example

A 1 GHz clock (1.0 ns period) is generated by an on-chip PLL with a datasheet RMS jitter of 8 ps, which the design team converts to a 48 ps peak-to-peak bound using a 6-sigma multiplier from the PLL vendor. They set set_clock_uncertainty -setup 0.06 [get_clocks CLK], folding in the 48 ps jitter bound plus 12 ps of margin for pre-CTS skew estimation error. A path with 80 ps of raw setup slack under a naive 20 ps uncertainty assumption would have shown +80 ps; with the correctly derived 60 ps uncertainty, the same path reports roughly +40 ps — still passing, but with real margin instead of an inflated number that hid the PLL's actual jitter.

Complete STA Handbook