ExpertQuestion 44 of 69Source: Synopsys PrimeTime User Guide: Timing PLL-Based Designs

How does the -pll_shift option of set_clock_latency model PLL drift and jitter differently from an ordinary fixed source-latency override?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A normal set_clock_latency (SDC) value replaces the clock's computed source latency outright, but the -pll_shift option adds its value on top of whatever base latency the tool already derived for a PLL-generated clock. That distinction lets a designer layer a PLL's drift and jitter numbers onto the real, feedback-computed latency instead of overwriting it, which is the only way to keep a PLL feedback loop's timing internally consistent.

Technical Reference DiagramHow does the -pll_shift option of set_clock_latency model PLL drift and jitter differently from an ordinary fixed source-latency override?
PLL feedback loop with CLK_pll output showing base feedback-derived latency plus a layered -pll_shift drift term (100ps) and a separate -dynamic jitter term (20ps) on early and late sides

Technical Explanation

  • Ordinary set_clock_latency -source (SDC) overrides the clock's source latency with the exact number given — whatever the tool would have computed from the clock network is thrown away and replaced.
  • set_clock_latency -source -pll_shift (SDC) behaves differently: the specified delay is added to the base early or late latency the tool already computed for the PLL's generated output clock, not substituted for it.
  • This matters because a PLL's generated clock (create_generated_clock -pll_feedback ... -pll_output ... (SDC)) already has real latency derived from the feedback path in the netlist; overwriting it with a flat value would break the loop's own timing relationship.
  • PLL drift is modeled as a static -pll_shift value on the early or late side, representing how far the PLL's actual output tracks its ideal phase over process and voltage.
  • PLL jitter is modeled with the same -pll_shift option combined with -dynamic, which adds a second, separately-tracked jitter component on top of the drift value rather than merging the two into one number.
  • The -pll_shift designation must be applied to the generated clock defined at the PLL output connected to the feedback pin — applying it elsewhere does not represent the PLL's actual phase-correction behavior.
  • Because -pll_shift is additive rather than a replacement, it can be applied incrementally: an early silicon estimate can be refined later with updated drift and jitter numbers from characterization, without ever having to re-derive or re-enter the PLL's base feedback latency by hand.
  • What breaks: using a plain -source override instead of -pll_shift on a PLL output clock discards the tool's own feedback-derived latency, producing a clock model that no longer reflects how the PLL actually locks to its reference.

Common Mistake

The Trap: Reaching for an ordinary set_clock_latency -source override to add PLL drift, which silently deletes the feedback-computed base latency instead of adding to it.

  • The design still reports clean numbers, because the tool accepts the override without complaint — there is no warning that the real feedback latency was thrown away.
  • Downstream, the PLL's output clocks report a latency that no longer matches the actual loop, which can hide, or invent, a skew problem on every path that clock feeds.

Follow-up Question & Model Response

"If I already have real jitter measurements from the PLL datasheet, how do I turn those into the -dynamic value instead of guessing?"

Candidate Model Response: The PLL vendor's jitter specification is usually given as a peak-to-peak number in the clock's own time unit, and that number becomes the magnitude passed with -dynamic on the set_clock_latency -pll_shift (SDC) command, applied with opposite signs on the early and late sides to bound the jitter symmetrically around the drift value. The drift number, separately, comes from the PLL's static phase-offset specification and is applied without -dynamic. Keeping the two separate, rather than folding jitter into a single inflated drift number, lets the tool report which component is driving a given violation when a path fails.

Practical Example

A design defines CLK_pll as a divide-by-1 PLL feedback clock at a 200 MHz reference. The datasheet gives 100 ps of static drift and 20 ps of peak jitter. The SDC applies set_clock_latency -source -pll_shift -early -0.100 -dynamic -0.020 [get_clocks CLK_pll] and the matching -late +0.100 -dynamic +0.020 command pair, then set_propagated_clock {CLK CLK_pll}. report_clock_timing afterward shows the feedback-derived base latency unchanged, with the 100 ps drift and 20 ps jitter appearing as separate additive terms next to it — exactly the layering a plain -source override could never have produced, since that command would have deleted the base number outright.

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 →
Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting. →

Continue practising

Related STA questions

ExpertHow do you model and verify timing across multiple clock domains with different frequencies (e.g., a 2:1 frequency crossing)?ExpertWhat goes wrong when a compound generated clock (divide-then-gate) is defined incorrectly, and how do you validate it?IntermediateHow do you model early and late clock source latency with set_clock_latency?ExpertWhy must a cascaded chain of divide-by generated clocks name the previous generated clock as its master, instead of all pointing back at the original clock?