AdvancedQuestion 30 of 63Source: Synopsys PrimeTime User Guide: Specifying Clock Characteristics

How do you make clock jitter automatically propagate from a master clock to every clock it generates?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

The set_clock_jitter (SDC) command, applied to a master clock, sets the same jitter properties on every clock generated from it, so you do not have to repeat the jitter values on each generated clock individually. report_clock_jitter (PT) then shows the cycle jitter, duty-cycle jitter, and which master clock's jitter each generated clock inherited, so you can confirm the propagation actually took effect.

Technical Reference DiagramHow do you make clock jitter automatically propagate from a master clock to every clock it generates?
A master clock mclk with set_clock_jitter -cycle 2 applied to it, an arrow showing automatic inheritance down to a generated clock gclk with no jitter command of its own, and a report_clock_jitter table showing matching cycle jitter of 2 and duty-cycle jitter of 3 for both clocks, with mclk listed as the master clock with jitter for both rows

Technical Explanation

  • set_clock_jitter (SDC) is scoped to a master clock, and its effect fans out from there. Running it on one clock object sets jitter on that clock and, automatically, on every generated clock whose source traces back to it.
  • Leaving out the master-clock argument applies the jitter to every clock in the design. If you do not specify which master clock the jitter belongs to, PrimeTime sets it on all clocks, which is rarely what you actually want on a design with multiple independent PLLs.
  • remove_clock_jitter (SDC) mirrors the same scoping. Removing jitter from a master clock automatically removes it from every generated clock that had inherited it, so you do not have to track down and clear each one by hand.
  • report_clock_jitter (PT) is the way to confirm the propagation worked. Its report lists cycle jitter, duty-cycle jitter, and a "master clock with jitter" column for every clock, showing which master clock's setting each row is actually using.
  • This is a distinct mechanism from modeling jitter through set_clock_uncertainty (SDC). set_clock_jitter describes the clock's own waveform quality and inherits down a generated-clock family automatically; set_clock_uncertainty sets a margin value directly on whatever object you name, with no automatic inheritance to clocks derived from it.
  • report_timing (PT) shows the effect once jitter is applied. A path's clock network delay in the timing report reflects the jitter value that ended up on the specific clock edge being timed, which is the fastest way to confirm the right master's jitter reached a given generated clock.

Common Mistake

  • Setting set_clock_jitter separately on every generated clock in a divider chain, assuming each stage needs its own explicit jitter value the way set_clock_uncertainty often does.
  • This duplicates a value that would have propagated automatically from the master clock, and if a later ECO changes the master's jitter, the manually-set values on the generated clocks are easy to forget to update.
  • Cost: a generated clock's jitter silently drifts out of sync with its master's real jitter after a spec change, because it was never wired to inherit automatically in the first place.

Follow-up Question & Model Response

If report_clock_jitter shows a generated clock's "master clock with jitter" column pointing to a different clock than the one you expected, what does that tell you about how the generated clock was defined?

Candidate Model Response: It tells me the generated clock's source network traces back to a different master than I assumed, since set_clock_jitter's propagation follows the actual generated-clock hierarchy, not my mental model of it. I would check the generated clock's -master_clock and -source options against the report, because a cascaded chain that skipped a stage, or that pointed a later stage back at the wrong master, would produce exactly this mismatch. This is also a useful sanity check after restructuring a multi-stage divider, since it confirms the tool's view of the clock family matches the SDC author's intent.

Practical Example

A design's reference clock mclk has a real jitter spec of 2 picoseconds of cycle jitter, applied with set_clock_jitter -cycle 2 mclk (SDC). A generated clock gclk, divided down from mclk, was never given its own set_clock_jitter command. Running report_clock_jitter (PT) confirms the inheritance worked: both mclk and gclk show a cycle jitter of 2 and a duty-cycle jitter of 3, with the master clock with jitter column reading mclk for both rows, meaning gclk correctly picked up its master's jitter spec without a single extra line of SDC.

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

IntermediateHow would you model PLL clock jitter, and why use dynamic latency rather than uncertainty?IntermediateWhat's the difference between clock uncertainty and clock jitter?BeginnerWhat is clock uncertainty?AdvancedWhy does interclock uncertainty override simple clock uncertainty when both apply to the same path?