How does `place_opt` resolve optimization conflicts across competing MMMC views?
From PDVerse PnR Interview Handbook, part of the 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_matrixPnR 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