What must be true before a design is ready to hand off from placement to CTS?

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.

Healthy, Suspicious & Hard-stop Results

• Expected: check_timing and 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.

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.