In short: MMMC (Multi-Mode Multi-Corner) lets a single timing-closure run verify every combination of operating mode (functional, test, sleep) and PVT corner (fast/slow process, voltage, temperature) at once by bundling delay/constraint/parasitic data into analysis views, so you close timing for the real silicon envelope instead of one lucky condition.
Ask any physical-design engineer why their chip taped out late and "we kept re-closing timing for a corner we forgot" is a common answer. MMMC is the methodology that exists to stop that. It is a first-class concept in Cadence Innovus/Tempus, Synopsys IC Compiler II / PrimeTime, and the signoff flows around Siemens Calibre. If you are interviewing for a PD or STA role, you will be asked to define a mode, a corner, and an analysis view in one breath. Let us build that from the ground up.
Why a single corner is never enough
A standard cell's delay is not a fixed number. It depends on three axes engineers group as PVT: Process (how fast transistors came out of the fab lottery, captured as SS/TT/FF library characterization), Voltage (0.72 V vs 0.88 V on a nominal-0.8 V rail), and Temperature (−40 °C to 125 °C for automotive). Each unique PVT point is a corner, and each corner can flip which path is critical.
Classic rule of thumb: setup violations are worst at the slow corner (SS, low V, high T) because gates are sluggish; hold violations are worst at the fast corner (FF, high V, low T) because data races through faster than the clock expects. At advanced nodes "temperature inversion" breaks this — slow gates can be worst-case cold — so you must analyze both, not assume.
Modes: the same silicon, different intent
A mode is a set of timing constraints (the SDC) that describes how the chip is being driven at a moment. The gates do not change; the clocks, I/O timing, false paths and case analysis do. Typical modes for an SoC:
- Functional — mission clock at, say, 1.2 GHz, real datapath active.
- Scan-shift — slow test clock (~50 MHz), every flop chained, `set_case_analysis` on scan-enable.
- Scan-capture / at-speed (ATPG) — functional-speed capture pulses for transition-fault coverage.
- Low-power / retention — a reduced-frequency or clock-gated mode where only part of the fabric toggles.
From modes × corners to analysis views
Here is the key idea. A delay corner couples a library set (the PVT) with the parasitic (RC) corner extracted from the layout — the SPEF file that carries wire resistance and capacitance for cmin/cmax/rcworst/rcbest conditions. An analysis view is then the pairing of one constraint mode with one delay corner. Timing is signed off per view.
With 3 modes and 5 corners you could enumerate 15 views, but you do not analyze all of them. You pick the dominant ones: scan-shift only needs the slow corner for setup and fast for hold; functional needs the full PVT spread. A disciplined team typically closes 6–9 active views rather than the full cross-product — fewer runs, same confidence.
What an MMMC setup file actually contains
In Cadence the view definition lives in an MMMC/view_definition.tcl file. Synopsys uses scenarios with `create_scenario`. The building blocks map cleanly:
| Object | Cadence command | What it names |
|---|---|---|
| Library set | create_library_set | .lib timing files for one PVT |
| RC / extraction corner | create_rc_corner | cap/res scaling, temperature, QRC techfile |
| Delay corner | create_delay_corner | library set + rc corner together |
| Constraint mode | create_constraint_mode | one or more SDC files |
| Analysis view | create_analysis_view | constraint mode + delay corner |
| Active set | set_analysis_view | which views are -setup / -hold |
On-Chip Variation (OCV), and its advanced forms AOCV/POCV/LVF, are applied per view. A derate of ±5% on a 10 ns path is 500 ps — easily the difference between pass and fail, so the derate model is as much part of the corner as the PVT label.
Concurrent analysis: the "multi" that matters
The real power of MMMC is concurrent multi-corner optimization. Instead of fixing a slow-corner violation, re-running, and discovering you just created a fast-corner hold violation, the engine (Innovus `optDesign`, ICC2 placement/CTS/route) sees all active views at once and makes a single fix that satisfies the worst view on every endpoint. The clock tree in particular must be balanced so skew holds across corners simultaneously.
A concrete walk-through
Suppose a 28 nm design with a 1.2 GHz core (0.833 ns period). You define library sets ss_0p81_125c, tt_0p90_25c, ff_0p99_m40c; RC corners cmax and cmin; and two modes. The functional-setup view (ss + cmax) reports −120 ps WNS after routing. You add buffers and resize — but because the ff + cmin hold view is active in the same session, the tool refuses to over-speed a path that would then fail hold at the fast corner by 40 ps. One concurrent pass converges both. Signoff in Tempus/PrimeTime then re-reads the identical view set so there is no optimism gap between implementation and signoff.
Common interview traps
- "More views = safer" — no; redundant views waste runtime and memory. Prune to the dominant ones.
- Forgetting a mode — scan paths unclosed at test speed is a classic DFT escape.
- Mismatched signoff — implementation MMMC must mirror the signoff MMMC, or you tape out on false confidence.
- Ignoring temperature inversion at sub-28 nm.
Teams that pair clean static timing analysis fundamentals with a lean MMMC strategy close faster. If you want hands-on labs with real Innovus and PrimeTime view decks, our training partner ChipXpert VLSI training runs guided tapeout exercises on these exact flows.
Want to go from "I can define a view" to "I can debug a 9-view MMMC signoff deck"? Join the CourseTron Physical Design & STA track — browse the VLSI courses and build a real MMMC closure flow end to end.
FAQ
What is the difference between a mode and a corner in MMMC?
A mode is a set of constraints (SDC) describing how the chip is operated — clock frequencies, I/O delays, case analysis. A corner is a physical operating condition — a PVT point plus its RC extraction. A mode changes intent; a corner changes the silicon's electrical behavior.
What is an analysis view?
An analysis view is the pairing of exactly one constraint mode with one delay corner (library set + RC corner). Timing is reported and signed off per view, and views are grouped into setup and hold active sets.
Why use concurrent multi-corner instead of fixing corners one at a time?
Sequential fixing causes ping-pong: a setup fix at the slow corner creates a hold fix at the fast corner. Concurrent MMMC optimization sees all active views together and makes one fix that satisfies the worst case on every endpoint, which converges faster and avoids optimism gaps.
How many views should a design close?
Not the full mode×corner cross-product. Teams prune to the dominant views — typically 6 to 9 — choosing the worst setup and hold condition for each mode rather than enumerating every combination.