MMMC in STA: Multi-Mode Multi-Corner Timing Sign-off

A modern block is never timed once. It is timed in functional mode and in scan shift, at a slow corner and a fast one, hot and cold, with worst-case and best-case wires, and often at more than one DVFS voltage. Multi-mode multi-corner (MMMC) analysis is how STA and implementation tools handle all of those situations together instead of one run at a time.

This guide explains MMMC from a physical design and sign-off point of view: what a mode and a corner really are, how they combine into analysis views (scenarios), which corners matter for setup and which for hold, how to keep the scenario count under control, how optimization works across many views at once, and how to debug the usual problems. All numbers and corner lists in the worked examples are illustrative, not taken from any specific foundry, library or project. Command snippets are simplified sketches to show the structure, not complete scripts. Related reading on iVLSI: Static Timing Analysis (STA) in VLSI, Setup and Hold Violations, OCV, AOCV and POCV in STA, Standard Design Constraints (SDC) and Timing Library (.lib).

Why one timing run is not enough#

STA checks every path against its constraints for one set of conditions. But the conditions change in two independent ways:

• How the chip is being used. The same flops are clocked by a fast functional PLL clock in normal operation, by a slow tester clock during scan shift, and by an at-speed clock during scan capture. Different clocks, different case values on mux selects, different false paths. Each of these is a mode.
• The physical conditions the silicon sits in. Transistors can be slow or fast (process), the supply can droop or sit high (voltage), the die can be cold or hot (temperature), and the wires can come out wider or narrower, thicker or thinner (interconnect). Each combination is a corner.

A path with setup margin at a fast corner can fail at the slow corner; a hold path clean at the slow corner can fail at the fast one; a scan-shift path nobody cares about for setup can be the worst hold violator. Time one combination and you are guessing about the rest.

MMMC lets placement, CTS, routing optimization and sign-off STA see all the relevant combinations together, so a fix for one view is checked against the others as soon as it is made.

Modes: the constraint side#

A mode is a set of timing constraints, usually one SDC per mode. Typical modes:

Modes differ in clock definitions, set_case_analysis values, I/O delays and exceptions. For refreshers, see Generated Clocks in STA and Multicycle Path and False Path in STA.

A good mode SDC describes exactly one hardware configuration. Mixing scan and functional clocks without case analysis that makes them exclusive creates paths that can never happen in silicon.

Corners: the physical side#

A corner in MMMC combines two ingredients.

Library (PVT) corner#

Each standard cell, memory and IP library is characterised at specific process, voltage and temperature points, and the tool reads the Liberty file for each point. A name like "ss, 0.72 V, 125 C" means slow-slow transistors, a low supply and a hot die. Common types:

• Slow (ss) at low voltage, typically checked at both a hot and a cold temperature, for setup.
• Fast (ff) at high voltage, hot and cold, for hold.
• Typical (tt) at nominal voltage, often used for power analysis and sometimes for a sanity timing view.

Why check slow corners both hot and cold? At older nodes and higher supply voltages, cells get slower as temperature rises, so "slow and hot" was the setup worst case. At many advanced nodes and low supply voltages, the threshold-voltage effect dominates and cells can be slower when cold. This is temperature inversion, explained in detail in Temperature Inversion in VLSI. The practical consequence for MMMC is simple: you cannot assume which temperature is worst, so the corner list includes both ends of the range unless the library data proves one of them never dominates.

Interconnect (RC) corner#

Metal width, thickness and dielectric thickness vary across manufacturing, and they change wire resistance and capacitance in different directions. Extraction tools therefore provide several RC corners from the foundry's interconnect technology files. The usual names are:

• Cworst / Cbest: total capacitance at its maximum or minimum.
• RCworst / RCbest: the resistance-capacitance product at its maximum or minimum. RCworst typically comes from thinner, narrower wires, which raise resistance even though some capacitance components drop.
• Typical: nominal geometry.

Which RC corner hurts most depends on the path. A path dominated by gate delay and short local wires is usually hurt most by Cworst, because extra capacitance loads every driver. A path with long routes, where wire RC delay dominates, can be hurt most by RCworst. That is why many sign-off matrices pair slow library corners with both Cworst and RCworst, and fast library corners with Cbest and RCbest. Coupling capacitance also matters for crosstalk delay; see Crosstalk in VLSI.

Delay corner = library corner + RC corner (+ derates)#

In most tools a timing corner bundles a library set, an RC corner, an operating temperature for extraction, and the corner's derating or variation data (OCV derates, AOCV tables or POCV side files). The OCV, AOCV and POCV settings are corner-specific, so an MMMC setup that loads one derate file for all corners is usually wrong.

Analysis views (scenarios): mode × corner#

An analysis view (Cadence naming) or scenario (Synopsys naming) is one mode paired with one corner. The tool times each view separately and reports or optimises the worst slack per path across the active views.

The structure looks like this in a Cadence-style MMMC file (simplified, illustrative names):

# Libraries and RC per corner (file names are placeholders) create_library_set -name LIB_SS_0P72_M40 -timing {ss_0p72v_m40c.lib} create_library_set -name LIB_SS_0P72_125 -timing {ss_0p72v_125c.lib} create_library_set -name LIB_FF_0P88_M40 -timing {ff_0p88v_m40c.lib} create_rc_corner -name RC_CWORST -qrc_tech cworst.tch -temperature 125 create_rc_corner -name RC_RCWORST -qrc_tech rcworst.tch -temperature 125 create_rc_corner -name RC_CBEST -qrc_tech cbest.tch -temperature -40 # Delay corners create_delay_corner -name DC_SS125_CW -library_set LIB_SS_0P72_125 -rc_corner RC_CWORST create_delay_corner -name DC_SS125_RCW -library_set LIB_SS_0P72_125 -rc_corner RC_RCWORST create_delay_corner -name DC_FFM40_CB -library_set LIB_FF_0P88_M40 -rc_corner RC_CBEST # Modes create_constraint_mode -name FUNC -sdc_files {func.sdc} create_constraint_mode -name SHIFT -sdc_files {scan_shift.sdc} # Views and which ones are used for setup / hold create_analysis_view -name FUNC_SS125_CW -constraint_mode FUNC -delay_corner DC_SS125_CW create_analysis_view -name FUNC_SS125_RCW -constraint_mode FUNC -delay_corner DC_SS125_RCW create_analysis_view -name FUNC_FFM40_CB -constraint_mode FUNC -delay_corner DC_FFM40_CB create_analysis_view -name SHIFT_FFM40_CB -constraint_mode SHIFT -delay_corner DC_FFM40_CB set_analysis_view -setup {FUNC_SS125_CW FUNC_SS125_RCW} \ -hold {FUNC_FFM40_CB SHIFT_FFM40_CB}

Synopsys-style flows express the same idea with create_mode, create_corner and create_scenario, enabling each scenario for setup, hold or power separately. Options vary by tool and version, so check your tool documentation.

The key idea is that a view does not have to be used for everything. A slow corner view is usually enabled for setup and max transition/capacitance checks. A fast corner view is usually enabled for hold. A typical corner view may be enabled only for leakage or dynamic power optimization.

Which views check what#

Hold slack depends on the difference between data and clock arrival, and at a slow corner an unbalanced clock tree can stretch skew more than it stretches a short data path. Most methodologies therefore require hold to be clean in every sign-off view, not only the fast ones. The Setup and Hold Violations post covers the fixes.

Worked example A: the same path, different worst views (illustrative)#

Consider three paths in one block, timed in four views. Slack is in picoseconds; negative means violating.

What this shows:

• P1 is gate dominated, so the Cworst view is its worst case. Fixing it only in the RCworst view would leave −18 ps behind.
• P2 is wire dominated, so RCworst is worst. A Cworst-only flow would think it passes with +12 ps.
• P3 exists only in the shift mode as a real timing path (Q of one scan flop to scan input of the next). It barely passes hold in functional mode but fails in shift mode, because the shift clock tree and case analysis differ.

No single view finds all three. That is the whole argument for MMMC.

How many views is enough?#

The view count multiplies quickly. Four modes × six library corners × four RC corners is 96 combinations, each needing its own timing graph, and some of them with SI enabled. Runtime and memory grow roughly with the number of active views, so teams prune.

Common ways to reduce the set without losing coverage:

1. Pair corners sensibly. Slow library corners go with worst-case RC corners for setup; fast library corners go with best-case RC corners for hold. Cross-pairs (slow cells with best-case wires) are usually only kept where the methodology calls for them, for example some hold checks.
2. Use dominance. If view A is worse than view B on every path for a given check, B adds nothing. Many tools can report dominated scenarios. Re-check after big changes, since an ECO can make a pruned view relevant again.
3. Split by stage. Placement and early optimization can run on a small set of the most critical views. CTS and post-route optimization add hold views. Sign-off STA runs the full matrix.
4. Merge modes where it is safe. Mode merging combines several compatible SDCs into one superset mode, reducing views. It needs care: merged constraints must not create paths that cannot exist, and must not drop exceptions that only apply to one mode.
5. Keep power views separate. Leakage and dynamic power views do not need to be setup or hold views.

Worked example B: trimming a scenario list (illustrative)#

Start: modes FUNC, SCAN_CAP, SHIFT; library corners ss hot, ss cold, ff hot, ff cold, tt; RC corners Cworst, RCworst, Cbest, RCbest, typical.

• Full cross product: 3 × 5 × 5 = 75 views.
• Pair ss with Cworst and RCworst, ff with Cbest and RCbest, tt with typical: 2 + 2 + 2 + 2 + 1 = 9 corners, so 3 × 9 = 27 views.
• SHIFT runs at a slow test clock, so its setup views are dropped by agreement with the DFT team; it keeps the four ff hold views and one ss hold view: 5 SHIFT views instead of 9.
• SCAN_CAP setup is checked at ss hot and ss cold with Cworst only, after a dominance report shows RCworst never adds a worse path in that mode on this block: 2 setup views + 4 ff hold views.
• tt typical is used for power only, FUNC only.

Result: FUNC 9 + SCAN_CAP 6 + SHIFT 5 = 20 views, with every remaining view justified. The numbers are for illustration; the point is that each pruning step is written down with its reason, so it can be re-checked later.

MMMC through the implementation flow#

The same view definitions should drive the whole flow so implementation and sign-off agree. Timing-driven placement uses the most critical setup views. CTS must see hold-critical modes such as shift if their clock path differs, or the tree is balanced for the wrong structure (see Clock Tree Synthesis). Post-CTS and post-route optimization fix setup and hold together across views. Sign-off STA runs the full matrix with SI and sign-off extraction, and remaining fixes go in as an ECO, after which all views are re-timed.

Worked example C: a hold fix that breaks setup (illustrative)#

A path fails hold by 15 ps in FUNC ff cold Cbest and has +20 ps of setup slack in FUNC ss hot Cworst. A delay cell that adds about 25 ps at the ff corner is slower at the ss corner, say about 45 ps. Hold becomes +10 ps, but setup becomes 20 − 45 = −25 ps.

Because the same cell adds more delay at the slow corner than the setup margin allows, no plain delay insertion on the shared data path can fix both. The fix has to change the structure: recover setup earlier in the path (upsize or restructure logic), put the hold delay on a branch that feeds only the hold-critical capture flop, or adjust clock arrival with useful skew if the neighbouring stages have margin. MMMC-aware optimizers check every view before committing a fix; manual ECOs must do the same explicitly.

Common MMMC mistakes#

• Wrong library in a view, or a memory library missing from one library set so its arcs are not timed.
• Extraction temperature mismatch between the RC corner and the view it is used with.
• Shared derates applied to all corners when the methodology defines them per corner.
• Mode SDC drift: the functional SDC gains a clock or exception that the copied scan SDC never gets.
• Missing case analysis on scan enable or test-mode pins, so impossible paths are timed.
• Views enabled for the wrong check, such as a fast view enabled for setup or a slow view disabled for hold.
• Different view sets in implementation and sign-off.
• A pruned view never re-checked after routing or an ECO.

Debug flowchart: MMMC timing problems#

When a violation appears in one view but not another, or implementation and sign-off disagree:

1. Confirm the view definitions: mode, library set, RC corner, extraction temperature and derates for each view.
2. Compare view lists between implementation and sign-off.
3. Diff the mode SDCs: clocks, case analysis, exceptions; run constraint checks per mode.
4. Check corner-specific data: derates and extraction per corner; re-extract if in doubt.
5. Look for ping-pong: report the path's setup and hold slack in every view and change the fix strategy if fixes trade off.
6. Re-run full sign-off on all views after any fix.

Interview Q&As#

Q1. What is MMMC in STA? Multi-mode multi-corner analysis times a design in several modes (constraint sets such as functional, scan shift and scan capture) and several corners (combinations of library PVT and RC extraction conditions) together. Each mode-corner pair is an analysis view or scenario, and the tool reports or optimises the worst slack across the active views.

Q2. What is the difference between a mode and a corner? A mode is about how the design is used: clocks, case analysis, I/O constraints and exceptions, usually one SDC. A corner is about physical conditions: the process, voltage and temperature of the cell libraries plus the interconnect RC corner and its derates.

Q3. Which corners are typically used for setup and which for hold? Setup is usually worst at slow library corners with low voltage, combined with Cworst or RCworst. Hold is usually worst at fast library corners with high voltage, combined with Cbest or RCbest. Many methodologies also require hold to be met at slow corners, because skew can cause hold failures there.

Q4. Why check both hot and cold at the slow corner? Because of temperature inversion. At many advanced nodes and low supplies, cells are slower when cold, while at higher supplies they are slower when hot. The worst temperature is not known in advance, so both are checked unless data shows one never dominates.

Q5. What is the difference between Cworst and RCworst? Cworst maximises total wire capacitance, which hurts gate-dominated paths with short wires. RCworst maximises the resistance-capacitance product, usually through narrower and thinner wires, which hurts long wire-dominated paths.

Q6. Why is scan shift mode important for hold? Shift paths go directly from one flop's output to the next flop's scan input, often with very little logic between them. With a different clock structure in test mode, these short paths are classic hold violators.

Q7. Why can a hold fix break setup? A delay cell adds more delay at slow corners than at fast corners. If the path's setup margin at the slow corner is smaller than the delay the cell adds there, the hold fix causes a setup violation.

FAQ#

Is a "corner" the same as a PVT corner? Not quite. A PVT corner describes the cell libraries. An MMMC corner usually also includes the RC extraction corner and the variation (derate) settings for that condition.

Do DVFS operating points need separate modes? Usually yes, or at least separate scenarios, because the clock frequency and the supply voltage both change. Each operating point needs setup checked at its own frequency and voltage. See Level Shifters in VLSI and Power Gating in VLSI for the multi-voltage side.

Summary#

• A mode is a constraint set; a corner is a physical condition (library PVT, RC corner, derates); a view or scenario pairs one of each.
• Setup is usually worst at slow, low-voltage corners with Cworst or RCworst; hold at fast, high-voltage corners with Cbest or RCbest, but hold should be clean in every sign-off view.
• Check both temperature extremes (temperature inversion) and both Cworst and RCworst (gate- vs wire-dominated paths).
• Test modes such as scan shift are real timing modes, especially for hold.
• Control the view count by pairing corners, pruning dominated views and staging views through the flow, and document every pruning decision.
• Use the same views in implementation and sign-off, and re-time all views after every fix.

For the timing fundamentals behind all of this, start with Static Timing Analysis (STA) in VLSI, then read Setup and Hold Violations and OCV, AOCV and POCV in STA.