How does `place_opt` resolve optimization conflicts across competing MMMC views?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Optimizing a chip for a single corner/mode combination inevitably hurts it in the other operating views it also has to survive — this is the core tension MMMC placement optimization exists to manage. Concrete example of the conflict: Scenario A (functional mode, slow-slow corner, setup-critical) wants high-drive LVT/ULVT cells and wide buffers to overcome slow transistor switching and high RC delay.
Technical Explanation
- Optimizing a chip for a single corner/mode combination inevitably hurts it in the other operating views it also has to survive — this is the core tension MMMC placement optimization exists to manage.
- Concrete example of the conflict: Scenario A (functional mode, slow-slow corner, setup-critical) wants high-drive LVT/ULVT cells and wide buffers to overcome slow transistor switching and high RC delay.
- But those same high-drive ULVT cells picked for Scenario A leak excessively in Scenario B (standby mode, fast-fast corner, leakage-critical), threatening the standby battery-current budget — a direct conflict between two legitimate requirements on the same cells.
- A third view compounds it further: Scenario C (scan-shift mode, fast-fast corner, cold temperature) is hold- and slew-critical, and the same high-drive cells' sharp transition edges worsen crosstalk noise and dynamic IR drop in that view.
place_optresolves this with a unified cost function evaluated across all active scenarios simultaneously — it weighs path-slack deltas across every view at once and prioritizes sizing decisions on paths showing dominant worst-negative-slack across multiple scenarios, specifically so a setup fix in one corner doesn't quietly blow the leakage or noise budget in another.
Common Mistake
The Trap: Optimizing scenarios sequentially (fixing Scenario 1, then Scenario 2). Sequential optimization creates infinite ping-pong loops where each pass undoes the previous corner's fixes.
Follow-up Question & Model Response
"What is dominant scenario analysis during MMMC placement?"
Candidate Model Response: Dominant scenario analysis identifies which corner/mode combination exerts the greatest timing constraint on each path group, pruning redundant non-limiting checks to save runtime.
Practical Example
Configuring Multi-Scenario Optimization:
# Synopsys ICC2: Enable concurrent multi-scenario optimization across all active views
set_scenario_status [all_scenarios] -active true -setup true -leakage_power true
place_opt -concurrent
report_qor -scenario_matrixPhysical 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