BeginnerQuestion 16 of 95

What is clock uncertainty?

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 uncertainty is a margin the tool builds into every setup and hold check to cover clock jitter, skew the model can't fully predict, and other small clock imperfections. It's subtracted from the setup deadline (making it stricter) and added to the hold deadline (also making it stricter) through set_clock_uncertainty (SDC).

Clock uncertainty margin subtracted from the setup deadline and added to the hold deadline, shrinking from pre-CTS estimate to post-CTS propagated value — Technical Reference DiagramWhat is clock uncertainty?

Technical Reference DiagramWhat is clock uncertainty?

Technical Explanation

Uncertainty exists because a real clock is never perfectly ideal, and the size of the margin needed changes as the design matures.

Before the clock tree is built, uncertainty covers more ground. With no real clock tree yet, the designer estimates skew, adds the clock's own PLL jitter, and includes some extra margin — a typical early-stage value sits somewhere around 150 to 350 ps.
After the clock tree is built, physical skew is already in the report, so uncertainty shrinks. Once real buffer delays are propagated, uncertainty only needs to cover PLL jitter, power-supply noise, and duty-cycle distortion — usually landing around 30 to 100 ps.
Setup: uncertainty is subtracted from the required time. That pulls the setup deadline earlier, which is the pessimistic (stricter) direction for a check that's worried about being late.
Hold: uncertainty is added to the required time. That pushes the hold deadline later, which is the pessimistic direction for a check that's worried about happening too soon.
Setup and hold usually get separate values: set_clock_uncertainty -setup 0.08 [get_clocks CLK] and set_clock_uncertainty -hold 0.04 [get_clocks CLK] (SDC) let the two margins be tuned independently.

Common Mistake

The trap: leaving an early-stage uncertainty value (say, 250 ps) unchanged once the clock tree is actually built and its delays are propagated.
It's an easy value to forget about, since it was set once early in the flow and rarely revisited.
The physical clock tree's real skew is now already inside the reported clock latency, so keeping the old large uncertainty on top double-counts that skew — creating violations on paths that aren't actually failing.

Follow-up Question & Model Response

Why would a design team deliberately set different uncertainty values for two clocks running at the same frequency?

Candidate Model Response: Because uncertainty is meant to reflect that specific clock's real behavior, not a generic guess. A clock coming straight from an on-chip PLL with tight jitter specifications can reasonably carry a smaller uncertainty value than a clock routed a long distance across the die, or one derived through extra dividers that each add their own jitter contribution. Setting one blanket value for every clock either under-margins the noisier clock or over-margins the cleaner one — matching the number to the clock's actual source is the more accurate choice.

Practical Example

After more accurate post-layout characterization of power-supply noise and PLL jitter, one team reduced post-CTS clock uncertainty from 120 ps down to 60 ps. That single change cleared about 4,500 setup violations that had only existed because the earlier uncertainty value was more conservative than the design's real clock behavior justified.

Complete STA Handbook