IntermediateQuestion 44 of 222

Why are clocks normally ideal before floorplanning?

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

Short Answer

Before a clock tree is actually built and routed, there's simply nothing to measure โ€” no buffers, no real wire delay, no real skew between branches, because CTS hasn't happened yet. Treating the clock as "ideal" (zero or user-specified latency, no built-in skew) isn't a shortcut or a cop-out โ€” it's an honest reflection of what's actually known at that stage of the flow.

Technical Reference DiagramWhy are clocks normally ideal before floorplanning?

Technical Explanation

  • Any early value you do assign โ€” via set_clock_latency or set_clock_uncertainty โ€” is a modeling assumption standing in for the clock tree that will eventually exist, and it should be clearly labeled and periodically reviewed as such, not treated as measured data.
  • This matters because downstream engineers reading a pre-CTS timing report need to know they're looking at assumptions, not silicon-accurate numbers โ€” conflating the two leads to false confidence in early closure.
  • Once CTS actually runs (clock_opt/synthesize_clock_trees), the clock becomes "propagated" and the tool switches from the assumed ideal values to the real insertion delay and skew computed from the built tree.
  • Practically: keep the assumed pre-CTS latency/uncertainty values conservative and grounded in prior tapeouts or early estimates of tree size, since an unrealistic ideal-clock assumption can mask real setup/hold problems that only show up after CTS โ€” by which point they're much more expensive to fix.

What To Check

  • Warning sign: A copied post-CTS propagated-clock setting creates fictional network behaviour.
  • Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
  • Correct: Remove unsupported propagation and use the approved pre-CTS source latency, uncertainty, and transition model.

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: There is no implemented clock tree, so built-tree skew and route latency do not exist; only justified early assumptions belong in the model.
  • 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.