IntermediateQuestion 55 of 112Source: Synopsys PrimeTime User Guide: Clock Latency and Clock Uncertainty

How does clock uncertainty modeled with set_clock_uncertainty differ from clock latency modeled with set_clock_latency, and why are both needed?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Clock latency tells the tool where a clock edge arrives — a position in time, set with set_clock_latency or computed from a real propagated network. Clock uncertainty is a margin subtracted around that position to cover jitter and other variation the tool cannot exactly compute, set with set_clock_uncertainty — both are needed because one answers where the edge is and the other answers how much to distrust that answer.

Technical Reference DiagramHow does clock uncertainty modeled with set_clock_uncertainty differ from clock latency modeled with set_clock_latency, and why are both needed?
A clock edge marked on a timeline at its nominal latency position, with a shaded uncertainty band drawn around that position representing jitter, labeled separately from the latency arrow itself.

Technical Explanation

Uncertainty and latency both attach numbers to a clock's timing, but they model two different physical things.

  • Clock latency is where the edge is. set_clock_latency (SDC), or a real propagated clock network after CTS, tells the tool what time the clock edge actually arrives at a given point — it is a position in time.
  • Clock uncertainty is how much that position can wobble. set_clock_uncertainty (SDC) is a margin subtracted from the check, representing jitter, unmodeled skew, or other variation the tool cannot compute exactly from the netlist alone — it is not a position, it is a safety band around one.
  • Both are needed because they answer different questions. Latency answers "when does the edge nominally arrive"; uncertainty answers "how much should I distrust that nominal answer." Removing either one leaves the timing model incomplete in a different way.
  • Latency without uncertainty assumes a perfectly predictable clock, which is unrealistic once real jitter, unmodeled skew, or non-ideal effects exist — every real clock has some.
  • Uncertainty without a reasonable latency value is protecting the wrong number. A margin subtracted from an inaccurate nominal arrival time is still working from a wrong starting point, even if the margin itself is well chosen.
  • Why it matters: early in the flow, before a real clock network exists, uncertainty often does double duty, standing in for both latency's inaccuracy and real jitter, which is why teams frequently tighten the uncertainty value once propagated clock data replaces the early latency estimate.

Common Mistake

The Trap: treating a generous clock latency estimate as if it already covers real jitter, and skipping set_clock_uncertainty because the design "already has margin."

  • A conservative latency number moves where the edge nominally is, but it says nothing about how much that edge might vary from run to run or cycle to cycle — that is a separate physical effect uncertainty is meant to cover.
  • Skipping uncertainty because latency already looks pessimistic can leave a design with no real jitter protection at all, since the two numbers are not interchangeable.

Follow-up Question & Model Response

Before CTS, you set a conservative 2ns clock latency estimate for both clocks in a domain crossing. Do you still need clock uncertainty?

Candidate Model Response: Yes, latency and uncertainty are answering different questions even in that case. The 2ns latency estimate is a placeholder for where the clock tree will eventually put the edge, but it says nothing about jitter or the natural variation in when that edge actually arrives cycle to cycle. I would still apply a reasonable set_clock_uncertainty value, sized from expected PLL jitter and pre-CTS skew uncertainty, on top of the 2ns latency estimate. Once the real clock tree is built and set_propagated_clock (SDC) takes over from the estimate, I would revisit the uncertainty value, since propagated latency removes some of the modeling uncertainty the placeholder had to cover.

Practical Example

Before CTS, a domain sets set_clock_latency 2.0 [get_clocks CLK1] (SDC) as a placeholder estimate and separately applies set_clock_uncertainty 0.15 [get_clocks CLK1] (SDC) to cover expected PLL jitter and pre-CTS skew uncertainty. After CTS, set_propagated_clock [get_clocks CLK1] (SDC) replaces the 2.0ns estimate with a real, computed clock network delay of 1.85ns, and the team re-evaluates the uncertainty value down to 0.08 since it no longer needs to cover pre-CTS skew guesswork, only real PLL jitter.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

Continue practising

Related STA questions

IntermediateWhat's the difference between clock uncertainty and clock jitter?IntermediateHow do you model early and late clock source latency with set_clock_latency?IntermediateHow do you apply different setup and hold clock uncertainty margins with set_clock_uncertainty?BeginnerWhat does set_clock_transition do, and how is it different from set_clock_uncertainty?