How does PrimeTime model and analyze clock networks, including latency and uncertainty?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
PrimeTime propagates a defined clock waveform through the network to get each register's latency -source plus network - derives skew from latency differences, and adds clock uncertainty for jitter and margin on top, using ideal latency pre-CTS and propagated clocks post-CTS.
Complete Technical Explanation
PrimeTime models a clock as a defined waveform, a period with edges, at a source, then propagates it through the clock network to every register. The clock's arrival at a register is its latency, and latency has two parts: source latency, from the ideal clock origin to the clock definition point - an off-chip or PLL-to-port delay, for instance - and network latency, from the definition point through the on-chip clock tree of buffers and inverters to the register clock pin. Pre-CTS the network latency is ideal or estimated and you specify it with set_clock_latency; post-CTS it is propagated, computed from the actual clock-tree cells and parasitics, via set_propagated_clock . Differences in latency between registers are what produce skew. On top of that deterministic latency, PrimeTime adds clock uncertainty with set_clock_uncertainty - a margin covering jitter, the cycle-to-cycle edge variation from the clock source, an estimated-skew placeholder pre-CTS, and any added safety margin. Uncertainty is subtracted from the setup budget and added for hold, so it tightens both checks. Alongside this the tool handles CRPR, which removes common-clock OCV pessimism, and clock reconvergence generally. The pre-CTS to post-CTS move is therefore not a switch of one setting but the transition from estimated clock timing to signoff-accurate clock timing, with uncertainty shrinking as real skew becomes visible.
In Pd / Signoff
Concretely this governs which clock settings belong to which stage: set_clock_latency and a generous uncertainty pre-CTS, then set_propagated_clock with a reduced, justified uncertainty once the tree exists. Getting the handover wrong in either direction is a common source of slack that moves for no design reason - and of hold problems appearing only after CTS.
Common Trap
Leaving the pre-CTS skew allowance inside set_clock_uncertainty after switching to propagated clocks. The real skew is then counted twice - once through propagated latency differences, once through the placeholder margin - producing pessimism that no amount of datapath work can close.
Expect Next
What is the difference between an ideal and a propagated clock, and when does each belong in the flow?
Topic And Primetime Commands
STA Fundamentals / Slack & Arrival. set_clock_latency, set_propagated_clock, set_clock_uncertainty
Keep building interview depth
Continue practising STA
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising