Why must clock networks remain ideal during placement and pre-CTS optimization?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
During placement, registers are still moving around the floorplan constantly — you simply can't have a real, physically-routed clock tree yet, because the endpoints it would feed haven't settled into their final locations. Because of that, the timing engine models clocks as "ideal": every register's clock pin is assumed to transition at the same instant (often modeled as t=0 or a flat virtual-source latency), with clock uncertainty standing in as a placeholder margin (commonly around 100 ps) for the skew CTS will eventually introduce.
Technical Explanation
- During placement, registers are still moving around the floorplan constantly — you simply can't have a real, physically-routed clock tree yet, because the endpoints it would feed haven't settled into their final locations.
- Because of that, the timing engine models clocks as "ideal": every register's clock pin is assumed to transition at the same instant (often modeled as t=0 or a flat virtual-source latency), with clock uncertainty standing in as a placeholder margin (commonly around 100 ps) for the skew CTS will eventually introduce.
- If you prematurely turn on propagated clocks [PrimeTime:
set_propagated_clock] during placement, the timing engine sees zero clock-network insertion delay everywhere — and since no real clock tree exists yet to balance that delay, ordinary data paths between registers suddenly show massive, entirely fictitious hold violations. - The placer doesn't know those violations are fake — it will spend real routing resources inserting hold-fix delay buffers to chase phantom problems, permanently wasting area and congestion budget on a problem that was never real.
- The fix is procedural, not clever: keep clocks ideal with realistic uncertainty margins through placement, and only propagate real clock delay once CTS has actually built the tree.
Common Mistake
The Trap: Running set_propagated_clock [all_clocks] before place_opt. The tool inserts thousands of hold delay buffers on unbuffered clock sinks, destroying floorplan area and routing channels.
Follow-up Question & Model Response
"How does the timing engine account for clock skew during pre-CTS optimization?"
Candidate Model Response: Pre-CTS SDC specifies clock uncertainty (e.g., set_clock_uncertainty 0.15 [get_clocks CLK]), reserving an explicit timing margin for expected post-CTS clock skew and jitter.
Practical Example
Pre-CTS Clock Sanity Verification:
# Verify that all clocks remain ideal during placement
report_clocks -attributes
# Ensure uncertainty includes skew margin pre-CTS
set_clock_uncertainty -setup 0.12 [get_clocks CORE_CLK]
set_clock_uncertainty -hold 0.05 [get_clocks CORE_CLK]Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Continue practising