How does PrimeTime model and analyze clock networks, including latency and uncertainty?

Short Answer

PrimeTime propagates a defined clock waveform through the network to find each register's latency - source latency plus network latency - and derives skew from the differences. On top of that it adds clock uncertainty for jitter and margin, using ideal latency pre-CTS (clock tree synthesis) and real propagated latency post-CTS.

Technical Explanation

• The clock starts as a defined waveform. create_clock (SDC) states a period and edge times at a source point. PrimeTime then propagates that waveform through the clock network to every register's clock pin.
• Latency has two parts. Source latency is the delay from the ideal clock origin to the point where the clock is defined - an off-chip or PLL-to-port delay, for instance. Network latency is the delay from that definition point through the on-chip clock tree of buffers and inverters to the register's clock pin.
• Ideal versus propagated. Before clock tree synthesis (CTS), the network latency is only an estimate, set with set_clock_latency (SDC). After CTS, the real tree exists, and set_propagated_clock (SDC) switches the tool to computing latency from the actual clock-tree cells and their parasitics.
• Skew comes from latency differences. Skew is simply how much later or earlier the clock arrives at one register than another; it falls out directly from the difference in each register's total latency, so it only becomes accurate once real, propagated latency is in the model.
• Uncertainty adds margin on top. set_clock_uncertainty (SDC) layers a margin covering jitter (the source clock's cycle-to-cycle timing variation), an estimated-skew placeholder before CTS, and any extra safety margin the designer wants. Uncertainty tightens the setup budget and tightens the hold budget too, though in opposite directions.
• CRPR sits alongside this. Clock reconvergence pessimism removal (CRPR) credits back the double-counted variation on the clock segment shared by launch and capture paths, which matters once real skew and OCV derating are both active.

Follow-up Question & Model Response

Why does clock uncertainty shrink, rather than disappear, once you switch from ideal to propagated clocks post-CTS?

Candidate Model Response: Pre-CTS, part of the uncertainty budget is a placeholder standing in for skew you can't yet measure, because the tree hasn't been built. Once set_propagated_clock is active, the tool computes real skew directly from the actual clock-tree cells and parasitics, so that placeholder component is no longer needed. But uncertainty never goes to zero, because jitter - the clock source's genuine cycle-to-cycle timing variation - is a real physical effect independent of the tree, and any additional safety margin the design still wants stays in place too. So the number shrinks by exactly the estimated-skew component it no longer needs to guess at.