How does ICD actually make CCD faster, and what's the real mechanism behind the speedup?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Pre-CTS CCD is about 10% of place_opt runtime, mostly from medium/high-effort CUS (compute useful skew) calls. ICD (place_opt.flow.enable_fast_cus_in_final_opto) reduces one global CUS call to two LOCAL CUS calls focused only on critical endpoints, in the final_opto stage -- trading exhaustive global recomputation for a narrower, targeted recomputation that still catches the paths that matter most.
Technical Explanation
- Pre-CTS CCD is about 10% of place_opt runtime on its own, mostly from medium/high-effort CUS (compute useful skew) calls -- a real, measurable cost, not a rounding error.
- ICD reduces one global CUS call to two LOCAL CUS calls focused only on critical endpoints, specifically in the final_opto stage.
- The mechanism is a genuine scope reduction, not a quality shortcut: instead of recomputing useful skew globally across the whole design, ICD recomputes it locally around the endpoints that are actually critical.
- Enabled via place_opt.flow.enable_fast_cus_in_final_opto, default false -- this is an opt-in runtime optimization, not automatic.
Formula Or Decision Rule
Default: place_opt.flow.enable_fast_cus_in_final_opto = false. Enabling it trades one global CUS call for two local CUS calls scoped to critical endpoints only.
What To Check
- Warning sign: place_opt runtime with CCD enabled is significantly higher than expected for the design size.
- Inspect: check whether place_opt.flow.enable_fast_cus_in_final_opto is set -- CCD's CUS calls are a documented ~10% runtime cost that ICD specifically targets.
- Correct: enable ICD if the runtime cost is dominating and the design's critical endpoints are well-identified; verify post-run that critical-path timing wasn't negatively affected by the narrower scope.
Command Checks & Actions
set_app_options -name place_opt.flow.enable_fast_cus_in_final_opto -value trueEnables ICD's local CUS calls.
report_ccd_timingVerify critical-endpoint timing after enabling ICD to confirm no regression from the narrower scope.
Healthy, Suspicious & Hard-stop Results
- Expected: place_opt runtime drops measurably with ICD enabled, and critical-endpoint timing (verified via report_ccd_timing) is unaffected.
- Investigate: ICD is enabled but runtime didn't improve as expected -- confirm CUS calls were actually the dominant cost in this specific run before assuming ICD should have helped.
- Stop: ICD is enabled and critical-endpoint timing measurably regressed versus a global-CUS baseline -- that's a real signal the local scope missed something the global call would have caught.
Common Mistake
The Trap: Assuming ICD is a lossy shortcut that sacrifices CCD quality for speed -- it's a scope reduction to critical endpoints specifically, not a blanket approximation across the whole design.
What The Interviewer Is Testing
Whether you understand ICD's actual mechanism (local CUS calls around critical endpoints) rather than treating it as a vague "faster CCD" toggle.
Practical Example
Debug Scenario: A large block's place_opt run spends a disproportionate fraction of its time in CCD's CUS calls. Enabling place_opt.flow.enable_fast_cus_in_final_opto reduces that cost by scoping CUS recomputation to critical endpoints only in final_opto, cutting runtime without abandoning useful-skew optimization entirely.
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