Why is multimode clock synthesis genuinely harder than single-mode CTS, not just "more of the same work"?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Clock distribution must be balanced for both functional and scan mode simultaneously -- and this is made harder by multilevel clock gating, clock dividing, mode-switching circuits, and a scan clock all being present in the same tree. Balancing for one mode doesn't guarantee balance for another; the tree that's optimal for functional-mode skew may not be optimal for scan-shift-mode skew, and CTS has to satisfy both from one physical structure.
Technical Explanation
- Clock distribution must be balanced for both functional and scan mode simultaneously -- one physical tree, two (or more) sets of timing requirements to satisfy.
- This is made genuinely harder by multilevel clock gating, clock dividing, mode-switching circuits, and a scan clock all coexisting in the same design.
- Balancing for one mode doesn't guarantee balance for another -- the tree that's optimal for functional-mode skew may not be optimal for scan-shift-mode skew.
- The scan clock specifically often runs at a very different frequency from functional mode, meaning the same physical latencies produce very different effective skew/uncertainty budgets depending on which mode is active.
Formula Or Decision Rule
cts.icg.merge_cross_level = false (default): CTS only merges ICGs within the same tree level unless explicitly opted into cross-level merging.
What To Check
- Warning sign: functional-mode timing closes cleanly, but scan-shift-mode timing shows unexpected violations on the same clock tree.
- Inspect: check whether the tree's skew was validated only against functional-mode constraints, not scan-mode ones.
- Correct: re-run timing analysis under scan-mode constraints specifically, since a functional-mode-clean tree is not automatically scan-mode-clean.
Command Checks & Actions
report_clock_qorCheck skew/latency separately for each mode's active scenario, not just functional mode.
report_clock_timing -type skew -scenario <scan_scenario>Explicitly checks skew under scan-mode constraints.
check_mv_designConfirms mode-switching circuits (if multivoltage) are legal across both modes.
Healthy, Suspicious & Hard-stop Results
- Expected: both functional-mode and scan-mode skew/latency close within budget on the same physical tree.
- Investigate: one mode closes cleanly while the other shows marginal violations -- the tree may need mode-aware tuning rather than a purely functional-mode-optimized structure.
- Stop: scan-mode timing was never actually checked, only functional-mode -- that's not multimode-clean, it's single-mode-verified with an unverified assumption about the other mode.
Common Mistake
The Trap: Verifying clock tree timing only under functional-mode constraints and assuming scan-mode timing is automatically fine on the same physical structure.
What The Interviewer Is Testing
Whether you understand multimode CTS as a genuinely harder constraint-satisfaction problem, not just "the same CTS work, done twice."
Practical Example
Debug Scenario: A clock tree closes functional-mode timing cleanly but shows hold violations specifically in scan-shift mode -- the tree was optimized against functional-mode skew requirements without separately validating the very different clock relationship active during scan shift.
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