How does clock uncertainty reduce setup and hold margin?

Short Answer

Clock uncertainty is a margin you add for clock effects you do not model, such as jitter or skew not yet known. For setup, PrimeTime subtracts it from the data required time, so data must arrive earlier; for hold, it adds it to the required time, so data must stay stable longer. Every picosecond of uncertainty is a picosecond of slack taken away.

Technical Explanation

• set_clock_uncertainty -setup 0.05 [get_clocks CLK] (SDC) sets 50 ps (in ns units) of setup uncertainty on every path captured by CLK. A single value without -setup or -hold applies to both checks.
• Uncertainty appears as a clock uncertainty line on the capture side of the report, after the clock network delay and CRPR lines. For setup it is negative and moves required time earlier.
• Simple uncertainty applies to all capturing flops of a clock, port or pin. Interclock uncertainty, set with -from and -to clocks, applies only between those clocks, and wins when both exist on a path.
• Before CTS the clock is ideal, so uncertainty usually also covers expected skew. After CTS the real skew is in the propagated latencies, and teams normally reduce the value to jitter plus agreed margin so skew is not counted twice.
• Hold uncertainty is often set separately with -hold. Setup jitter shifts one edge relative to the next, while a hold check compares edges from the same clock cycle, so the two checks need different margins.
• By default the uncertainty also applies to pulse width checks. If uncertainty is set on a port or pin feeding a clock mux, the worst value applies to the whole fanout, so setting it on the clock object is safer.

Formula Or Decision Rule

• Setup: required time = capture edge + capture clock latency − library setup time − setup uncertainty; setup slack = required time − data arrival.
• Hold: required time = capture edge + capture clock latency + library hold time + hold uncertainty; hold slack = data arrival − required time.
• Rule: one value with no -setup or -hold applies to both checks. When a path has both simple and interclock uncertainty, the interclock value is used.

What To Check

• The clock uncertainty line on the worst setup and hold paths, and that it matches the specification for this stage.
• Setup and hold values set separately where the specification requires it.
• Interclock values set in both directions for paths between two clocks.
• Values reduced after CTS, so skew is not counted twice.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Post-CTS setup uncertainty equals jitter plus the agreed margin, for example 30 ps, and the report line shows exactly that.
• Suspicious (illustrative): A post-route run still carries a 150 ps pre-CTS uncertainty on top of propagated clocks, which counts skew twice and hides real slack.
• Hard stop: Hold uncertainty of zero in a signoff run whose specification requires a hold margin, or an uncertainty missing from one of two interacting clocks.

What The Interviewer Is Testing

• Can you place uncertainty correctly in the setup and hold slack equations?
• Knowing which value wins between simple and interclock uncertainty.
• Recognising that uncertainty should change between pre-CTS and post-CTS.

Follow-up Question & Model Response

"Why does uncertainty hurt hold as well, if jitter is about cycle-to-cycle variation?"

Candidate Model Response: A hold check compares the launch and capture of the same clock edge, so cycle-to-cycle jitter mostly cancels. But the uncertainty value also carries margin for skew the model may not capture and for analysis error, and the specification often asks for a hold margin. PT adds the hold uncertainty to the required time, so data must stay stable for longer. That is why hold values are usually smaller than setup values but seldom zero.