How would you model PLL clock jitter, and why use dynamic latency rather than uncertainty?
From PDVerse PrimeTime STA Interview Guide · pdVerse Mentor Guide
Ten-second Interview Answer
Model PLL jitter as a dynamic component of clock source latency with set_clock_latency -dynamic, because unlike set_clock_uncertainty it affects the crosstalk arrival-window calculation and is handled by CRPR.
Complete Technical Explanation
The right home for PLL jitter is the dynamic part of the clock source latency, using the -dynamic option of set_clock_latency, rather than uncertainty alone. The reason is a subtlety worth knowing precisely. Clock uncertainty, set with set_clock_uncertainty, tightens the setup and hold checks, but it does not affect the calculation of crosstalk arrival windows and it is not considered by CRPR, clock reconvergence pessimism removal. Dynamic source latency behaves differently: set_clock_latency -dynamic is handled by CRPR in the same way as PrimeTime SI delta delays, so the jitter properly affects the crosstalk arrival-window calculation, and CRPR correctly handles both the static and the dynamic portions, removing the appropriate pessimism at the common clock point. For designs where jitter interacts with SI and crosstalk timing, that makes dynamic latency the more accurate model. In practice you write it alongside the static value: set_clock_latency -source -early 2.5 -dynamic -0.5 [get_clocks CLK] and set_clock_latency -source -late 5.5 -dynamic 0.5 [get_clocks CLK], where the total early is static 3.0 plus dynamic -0.5 giving 2.5, and the total late is static 5.0 plus dynamic 0.5 giving 5.5. report_timing shows the static and dynamic components separately, and report_crpr reports the CRP values calculated for the static and dynamic conditions and which one was actually used.
In Pd / Signoff
You make this choice when building the clock model for an SI-aware signoff run on a PLL-driven design. The jitter number comes from the PLL specification and goes in as -dynamic on the source latency rather than being folded wholesale into uncertainty; afterwards report_crpr is read to confirm the static and dynamic CRP values, and report_timing to see the two components broken out on real paths.
Common Trap
Rolling all the jitter into set_clock_uncertainty and assuming it is covered. It tightens the checks but stays invisible to CRPR and to the crosstalk arrival windows, so the SI analysis never sees it and the common-point pessimism removal is computed without it - a silent accuracy loss, not a warning.
Expect Next
How does CRPR treat the dynamic latency component differently from the static portion at the common clock point?
Topic And Primetime Commands
Clocks / Generated Clocks. set_clock_latency, get_clocks, report_crpr, 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