IntermediateQuestion 236 of 142Source PDF page undefined

How does post-CTS STA differ from pre-CTS STA now that a real clock tree exists?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Before CTS, STA times against ideal clocks -- user-specified set_clock_latency and set_clock_uncertainty values standing in for a tree that doesn't exist yet. After CTS, the tool switches to propagated clocks: real, computed insertion delay and real skew from the actual built tree, not an estimate. This is why a design that looked clean pre-CTS can show new setup or hold violations post-CTS -- it's not that the design got worse, it's that STA is finally measuring the real thing instead of a placeholder.

Technical Reference DiagramHow does post-CTS STA differ from pre-CTS STA now that a real clock tree exists?
How does post-CTS STA differ from pre-CTS STA now that a real clock tree exists?, illustrating the physical design concept.

Technical Explanation

  • Before CTS, timing analysis runs against ideal clocks -- zero real insertion delay, with set_clock_latency/set_clock_uncertainty standing in as user-specified estimates.
  • After CTS, clocks are marked propagated (as a side effect of running CTS, or explicitly via synthesize_clock_trees -propagate_only) -- from then on STA uses the real computed insertion delay and skew from the actual tree.
  • A design that looked clean pre-CTS can show new violations post-CTS not because it got worse, but because STA stopped measuring an estimate and started measuring the real tree -- the pre-CTS pass was always against a placeholder.
  • New violation classes become possible post-CTS that couldn't exist pre-CTS: real skew-driven hold violations at specific leaf registers, and real insertion-delay-driven setup pressure the ideal-clock estimate couldn't predict.
  • Best practice is to run STA immediately after CTS and fix setup against the slow-case library corner, hold against the fast-case library corner, using global routing information where available.

What To Check

  • Warning sign: a design passes pre-CTS timing cleanly, then shows a cluster of new hold violations right after CTS.
  • Inspect: check whether the violating paths correlate with high-skew leaf registers in the newly built tree, not with anything that changed in the data path.
  • Correct: fix hold violations against the fast-case library corner specifically, using real global routing information, rather than re-checking against the same corner used for setup.

Command Checks & Actions

ICC2synthesize_clock_trees -propagate_only

Marks clocks propagated without rebuilding the tree.

ICC2report_clock_timing -type latency

Reports real computed insertion delay from the built tree.

ICC2report_timing -delay_type min

Checks hold, where post-CTS-only violations most often first appear.

Healthy, Suspicious & Hard-stop Results

  • Expected: post-CTS setup/hold violations, if any, correlate clearly with real tree skew/latency at specific leaf registers, not with unrelated data-path changes.
  • Investigate: a large number of new violations appear across the whole design rather than concentrated at specific high-skew points -- may indicate the pre-CTS estimate [SDC: set_clock_latency/set_clock_uncertainty] was badly wrong, not just optimistic.
  • Stop: hold violations are being fixed against the wrong corner (slow-case instead of fast-case) -- that fix will not hold up in silicon.

Common Mistake

The Trap: Treating a clean pre-CTS timing report as a real pass, and being surprised or suspicious when CTS "introduces" violations -- when in fact STA is just measuring the real tree for the first time instead of an ideal-clock estimate.

What The Interviewer Is Testing

Whether you understand propagated-vs-ideal clocks as a real, mechanical switch in what STA is measuring -- not just "CTS happened, so now there might be more violations."

Practical Example

Tapeout Scenario: A block passes pre-CTS setup and hold cleanly with set_clock_uncertainty conservatively set to 100ps. Post-CTS, the real tree's actual skew at one leaf register turns out to be 140ps -- a hold violation appears that the pre-CTS estimate, being lower than reality at that specific point, simply could not have caught.

Physical Design & Planning Handbook

Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.

Explore Design Planning Guide →

Continue practising

Related PnR (Place & Route) questions

BeginnerHow are clock tree DRC constraints different from clock tree timing constraints, and why does CTS need both?IntermediateIf you need to rebuild a clock tree from scratch, what does remove_clock_trees actually preserve versus remove?IntermediateHow do a clock mesh, an H-tree, and a spine differ as clock distribution structures?ExpertWhat is CCD (Concurrent Clock and Data optimization), and what does it actually change in the clock tree?