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
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