What must be true before a design is ready to hand off from placement to CTS?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Before CTS: no outstanding timing violations and no DRV violations from placement, derived clocks correctly expanded and understood, critical clock transitions/capacitance/fanout/congestion areas identified, high-fanout nets already driven with correct drive strength, and any logic areas needing shielding or max-capacitance limits already flagged. CTS is not a fresh start -- it inherits every unresolved placement problem and makes debugging them mixed up with genuine clock-tree problems.
Technical Explanation
- Before CTS, verify there are no outstanding timing violations and no DRV violations left over from placement -- CTS builds on top of them, it doesn't clean them up.
- Check that derived clocks are handled correctly -- an unexpanded generated clock means CTS builds a tree for a clock that isn't real.
- Identify critical clock transitions, capacitance, and fanout areas plus congestion hot spots ahead of time -- CTS buffer insertion adds cells into exactly those areas.
- Confirm high-fanout nets are already driven with correct drive strength -- that's placement's job, not CTS's.
- Identify logic areas needing shielding, fast transitions, or max-capacitance limits so buffer/delay stages can be sized appropriately.
- Once CTS runs, a post-CTS violation could be pre-existing, CTS-introduced, or both tangled together -- you lose the ability to tell which just by reading the report.
What To Check
- Warning sign: CTS completes with skew/latency numbers that look plausible, but setup/hold violations remain that don't obviously trace to the clock tree itself.
- Inspect: go back and check whether those violations existed pre-CTS -- if they did, CTS never had a chance to fix them because they weren't clock-tree problems.
- Correct: resolve pre-CTS violations before running CTS at all, so any violation found afterward can be attributed to the tree with confidence.
Command Checks & Actions
check_timingFinds missing or inconsistent timing setup before CTS runs.
report_constraint -all_violatorsSurfaces DRC violations left over from placement.
report_clock [all_clocks]Inspects every defined clock (including generated ones), confirming each generated clock’s -source/-master_clock actually resolved before CTS builds a tree for it.
Healthy, Suspicious & Hard-stop Results
- Expected:
check_timingand report_constraint come back clean, and every generated clock traces to a real source. - Investigate: a small number of DRC violations remain in a known congested area -- decide whether to fix now or explicitly accept the risk before CTS.
- Stop: an unexpanded generated clock, or unresolved timing violations on paths CTS cannot touch -- fix these before running CTS, not after.
Common Mistake
The Trap: Running CTS to "see what happens" when placement still has open violations, then spending debug time trying to separate pre-existing placement problems from genuine clock-tree problems in the post-CTS report.
What The Interviewer Is Testing
Whether you treat the placement-to-CTS handoff as a real gate with its own checklist, or just run CTS as the next step in a linear flow regardless of what state placement is actually in.
Practical Example
Tapeout Scenario: A block shows three hold violations after CTS. Before assuming CTS caused them, you check the pre-CTS report and find two of the three were already present at ideal-clock timing -- meaning CTS didn't cause them, it just carried them forward, and the real fix is upstream in placement, not in the clock tree.
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