IntermediateQuestion 47 of 222

Why check clock transition before CTS?

From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide

Short Answer

Clock transition (slew) is just the rise/fall time at a clock pin — how fast the signal ramps from low to high or high to low — and it directly drives cell delay calculation for every gate the clock touches. Before CTS exists, there's no real clock tree with real buffers driving real wire capacitance, so any transition value you see pre-CTS is an assumed input, typically set via set_clock_transition, not something measured from actual routed geometry.

Technical Reference DiagramWhy check clock transition before CTS?

Technical Explanation

  • Why bother checking it at all, then? Because that assumed transition feeds every downstream delay calculation in pre-CTS timing analysis — if the assumption is unrealistically fast (say, 50ps when a real clock buffer chain would realistically deliver 150–200ps), your pre-CTS timing will look artificially clean and then blow up in surprise violations once CTS builds the real tree.
  • It's also a sanity check against the library: an assumed transition that violates the library's own max_transition characterization range is a red flag that someone picked an unrealistic number rather than one grounded in typical clock buffer sizing for this technology.
  • Practically, teams often calibrate this assumption based on prior tapeouts in the same node/library — "our clock trees in this technology typically settle around X ps of transition at the leaf" — rather than guessing.
  • Once CTS runs and clocks propagate, this assumed value is replaced by the real, calculated transition at every clock pin — so this check is specifically a pre-CTS sanity gate, not something you keep worrying about afterward.

What To Check

  • Warning sign: The design uses an unrealistic default or a post-CTS value copied from another block.
  • Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
  • Correct: Apply the characterised methodology assumption and keep it distinct from later propagated results.

Command Checks & Actions

  • report_clocks: shows clock definitions and relationships
  • report_clock_settings: shows latency, transition, uncertainty, and clock-analysis settings

Run the commands in order. Each line answers a separate part of the check.

Healthy, Suspicious & Hard-stop Results

  • Expected: An explicit pre-CTS transition can be a modelling assumption for cell delay; it is not a measured routed-clock slew.
  • Stop before floorplanning when required logic or timing coverage is missing or unexplained.

Common Mistake

The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.

What The Interviewer Is Testing

Be ready to explain why this matters before floorplanning.

Follow-up Question & Model Response

Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”

Physical Design & Planning Handbook

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

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