IntermediateQuestion 21 of 112

How would you model PLL clock jitter, and why use dynamic latency rather than uncertainty?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Model PLL jitter as the dynamic part of clock source latency, using the -dynamic option of set_clock_latency (SDC), rather than folding it only into set_clock_uncertainty (SDC). Unlike uncertainty, dynamic latency affects the tool's crosstalk arrival-window calculation and is handled correctly by CRPR (clock reconvergence pessimism removal).

Technical Reference DiagramHow would you model PLL clock jitter, and why use dynamic latency rather than uncertainty?

Technical Explanation

  • Why uncertainty alone isn't the right home for jitter. set_clock_uncertainty (SDC) tightens the setup and hold budget by a fixed margin, but it does not feed into the tool's crosstalk arrival-window calculation, and it is not considered by CRPR at all — it is a pure timing-budget subtraction with no other effect.
  • What dynamic source latency does differently. set_clock_latency -dynamic (SDC) is handled by CRPR the same way the tool handles PrimeTime SI delta delays — meaning the jitter genuinely participates in the arrival-window math used for crosstalk analysis, not just the raw setup/hold subtraction.
  • Why CRPR handling matters here specifically. CRPR removes pessimism at the point where a launch and capture clock path share common logic — if jitter is modeled as dynamic latency, CRPR correctly accounts for both the static and dynamic portions of that shared clock path when removing pessimism; if it is modeled only as uncertainty, CRPR simply never sees it.
  • When the difference actually matters. For a design where jitter interacts meaningfully with signal-integrity timing — a fast SI-sensitive process node, or a design with significant crosstalk exposure — modeling jitter as dynamic latency is the more physically accurate choice, since it plugs into calculations plain uncertainty is defined to skip entirely.
  • How it's written in practice. The static and dynamic parts are specified together: set_clock_latency -source -early 2.5 -dynamic -0.5 [get_clocks CLK] pairs a 3.0 ns static early latency with a −0.5 ns dynamic jitter component, giving a combined 2.5 ns; the late side pairs similarly. report_timing (PT) shows the static and dynamic components separately, and report_crpr (PT) reports the CRP values computed under both conditions and which one the tool actually used.

Common Mistake

The Trap: Modeling all PLL jitter as clock uncertainty because it's the simpler, more commonly taught command.

  • Uncertainty-only modeling silently drops jitter from both the crosstalk arrival-window calculation and CRPR's pessimism removal.
  • On a design where SI timing or CRPR-heavy clock structures matter, this understates real risk in a way that a clean setup/hold report will never reveal, since uncertainty was never wrong about setup/hold — it was just incomplete for everything else.

Follow-up Question & Model Response

If a design has negligible crosstalk exposure and no CRPR-sensitive clock reconvergence, does the choice between uncertainty and dynamic latency still matter?

Candidate Model Response: In that narrow case the practical difference shrinks, since the two extra mechanisms dynamic latency plugs into — crosstalk arrival windows and CRPR — would not meaningfully affect the result either way. But few real designs can confidently claim both conditions at once, especially at advanced nodes where crosstalk exposure is common and clock trees frequently reconverge at multiplexers or clock-gating cells. Defaulting to dynamic latency as the standard practice, rather than deciding case by case, avoids having to re-verify that assumption every time the clock structure or process node changes.

Practical Example

A 28nm design's core clock comes from an on-chip PLL with a static source latency of 3.0 ns and a jitter specification that converts to ±0.5 ns. The SDC models this as set_clock_latency -source -early 2.5 -dynamic -0.5 [get_clocks CLK] and set_clock_latency -source -late 3.5 -dynamic 0.5 [get_clocks CLK], keeping the same 3.0 ns static value on both sides separate from the ±0.5 ns dynamic jitter component. Because this clock reconverges at a clock-gating mux shared by two downstream domains, report_crpr on the reconvergent path shows CRPR correctly removing pessimism across both the static and dynamic portions of the shared clock segment — a calculation that would have silently excluded the dynamic 0.5 ns jitter component entirely had it been modeled only through set_clock_uncertainty instead.

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 →

Offline PDF Bundle

Want all 1109 questions offline?

Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.

See what's inside the bundle
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?IntermediateWhat's the difference between clock source latency and clock network latency, and why model them separately before CTS?AdvancedA team proposes leaving clocks ideal (skipping propagated timing) post-CTS to save runtime near a deadline. How do you respond?ExpertWalk through a full setup check including clock reconvergence pessimism (CRPR) — why does OCV derating create artificial pessimism on shared clock paths, and how is it removed?