ExpertQuestion 43 of 69Source: Constraining Designs for Synthesis and Timing Analysis: Clock Latency and Propagation

What happens if you forget to run set_propagated_clock, and why can an ideal clock network hide a real skew problem?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Without set_propagated_clock (SDC), the tool times every clock path as an ideal network with only the latency and uncertainty values a designer supplied, so it never sees the real, branch-by-branch skew that clock tree synthesis introduces. A path that looks comfortably positive under the ideal-clock assumption can flip to a violation the moment real, propagated clock latency is applied, because the ideal model was silently optimistic about how well-aligned the launch and capture clock edges really are.

Technical Reference DiagramWhat happens if you forget to run set_propagated_clock, and why can an ideal clock network hide a real skew problem?
Two flip-flops FF_A and FF_B fed by an ideal clock network (zero skew, 30ps slack) versus the same pair after set_propagated_clock reveals a real 45ps skew, flipping the path to a -15ps violation

Technical Explanation

  • By default, before set_propagated_clock (SDC) is applied, PrimeTime times a clock as "ideal" — every registered arrival of that clock is calculated using only the values from set_clock_latency/set_clock_uncertainty, with no branch-by-branch insertion delay through real buffers and inverters.
  • An ideal network effectively assumes zero skew between two flops on the same clock unless the designer manually modeled otherwise, because the tool has no clock-tree structure to derive skew from.
  • set_propagated_clock (SDC) switches the clock to "propagated" mode: the tool walks the actual clock tree netlist, computing real insertion delay and transition at every clock pin, so two flops fed by different buffer chains get different, physically accurate arrival times.
  • The switch matters most after clock tree synthesis (CTS), when the real clock network exists in the netlist; running signoff STA while still in ideal mode analyzes a network that no longer matches the chip.
  • Ideal-clock timing tends to be optimistic for setup, because it assumes the launch and capture edges line up better than a real, unbalanced clock tree usually manages — real skew narrows the setup margin.
  • The reverse is also true for hold: some real skew helps hold margin on certain paths, so an ideal network can look worse than reality on those same paths — the direction of the error depends on which flop's branch is longer.
  • What breaks: a design signed off in ideal mode passes cleanly, then the same paths fail once propagated clocks are turned on for the real signoff run, because the skew the ideal model never modeled was hiding a marginal path.

Common Mistake

The Trap: Running early or mid-flow timing checks in ideal-clock mode and treating a clean report as proof the design will still be clean once the real clock tree exists.

  • Ideal mode is appropriate before CTS, when there is no real clock tree to model yet, but carrying that assumption into post-CTS or signoff analysis analyzes a network that no longer resembles silicon.
  • The gap only shows up when someone finally runs set_propagated_clock — often late, when a specific marginal path that looked fine suddenly reports a setup violation with no netlist change to explain it.

Follow-up Question & Model Response

"If a path passes with 30 ps slack under ideal clocks, how much could that change once propagated clocks are on, and how would I check before it surprises me?"

Candidate Model Response: The change equals the real skew between the launch and capture clock branches, which depends entirely on how balanced the clock tree is between those two flops — there is no fixed number, so it has to be measured, not assumed. Run report_clock_timing -type latency (PT) on both flops' clock pins after set_propagated_clock (SDC) is applied, and compare the Source and Network latency columns; the difference between the two flops' Total latency is the real skew being added to (or subtracted from) that 30 ps. Doing this check on every marginal path before final signoff, rather than after a surprise violation appears, turns an unpredictable jump into a known number.

Practical Example

A 900 MHz path between FF_A and FF_B reports 30 ps of setup slack under an ideal clock network with set_clock_uncertainty at 60 ps. After CTS, set_propagated_clock is applied, and report_clock_timing shows FF_A's clock branch has 210 ps of total latency while FF_B's branch, three extra buffer stages deeper, has 255 ps — 45 ps of real skew working against setup on that path. The 30 ps of ideal-mode slack becomes a -15 ps violation, discovered only because the propagated-clock run was finally added to the regression, not because any RTL or placement changed.

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 →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

Continue practising

Related STA questions

BeginnerWhat is the difference between an ideal clock and a propagated clock?BeginnerWhat is clock skew?AdvancedA team proposes leaving clocks ideal (skipping propagated timing) post-CTS to save runtime near a deadline. How do you respond?ExpertHow do you use report_clock_timing to confirm a generated clock's source and network latency were computed correctly after fixing its definition?