Why is multimode clock synthesis genuinely harder than single-mode CTS, not just "more of the same work"?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Last updated:
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.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
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.
Continue practising