What is MCMM/DMSA (multi-mode multi-corner / distributed multiscenario analysis), and what commands does PrimeTime provide to manage it?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
MCMM (multi-mode multi-corner) is the requirement to verify and optimize timing across every combination of a design's functional modes and its process/voltage/temperature corners, since a chip must work correctly in every mode it will actually run and at every corner silicon can land on. DMSA (distributed multiscenario analysis) is the execution architecture that makes checking all those combinations tractable: a manager process coordinates a scenario for each mode-corner combination, running each on its own worker process, then merges the results back into one signoff view.
Technical Explanation
- A mode is a functional operating condition of the design — normal function, test, low-power retention, a specific clock configuration — and a corner is a specific process/voltage/temperature (PVT) combination the tool analyzes delay at, such as slow-slow at low voltage and high temperature, or fast-fast at high voltage and low temperature.
- The full MCMM requirement is the cross-product: every mode has to be checked at every corner that could actually affect it, because a violation that only shows up in one specific mode-corner pairing is still a real risk if that pairing can occur in the field.
- A scenario (PT) bundles one specific mode-corner combination's full analysis setup:
create_scenario -name name -common_data {scripts} -specific_data {scripts}(PT) creates it, with common-data scripts shared across scenarios (for example, the same netlist read-in) and specific-data scripts unique to that one scenario (for example, that corner's operating conditions and SDC). - A session (PT) is the set of scenarios you actually want analyzed together in a given run, selected with
current_session(PT); it can be every defined scenario or a chosen subset, letting a designer run a smaller session during iteration and the full session for final signoff. - Command focus (PT), set with
current_scenario(PT), narrows which scenarios in the current session a given PrimeTime command actually applies to — by default all scenarios in the session are in focus, but a command can be pointed at just one or a few scenarios when only those need attention. - DMSA's architecture runs one manager process and a worker process per scenario;
start_hosts(PT) requests and brings online the compute resources the manager will dispatch worker scenarios to, andset_host_options -max_cores N(PT) bounds how many cores each worker or the manager itself is allowed to use. - What breaks: treating a single mode-corner combination's clean timing report as representative of the whole design's signoff status is a mistake MCMM/DMSA specifically exists to prevent — a design can be clean at one corner and violate badly at another corner in the exact same mode, and only running the full scenario set catches that.
Common Mistake
The Trap: narrowing command focus with current_scenario for a quick check and forgetting to broaden it back before a full signoff report.
- A
report_global_timing(PT) orreport_qor(PT) run while command focus is still narrowed to a handful of scenarios silently omits every other scenario's violations from that report, which can look like a clean signoff pass when the majority of scenarios were never actually included. - Assuming common-data scripts can be freely edited per scenario without consequence ignores that their entire purpose is to stay identical and shared — divergent "common" data across scenarios that are supposed to share it defeats the deduplication DMSA relies on for efficiency and can silently produce inconsistent baseline assumptions between scenarios.
Follow-up Question & Model Response
"You've been iterating with command focus narrowed to two scenarios during ECO. What do you need to check before declaring the ECO complete and ready for full signoff?"
Candidate Model Response: I would explicitly reset current_scenario back to the full current session before running any summary report, since command focus does not automatically revert on its own between commands. I would then run report_global_timing or report_qor across the restored full scenario set and confirm the reported endpoint and violation counts match the expected total scenario count, not just the two I had been iterating on — a mismatch there would tell me the ECO's real effect on the other scenarios was never actually checked.
Practical Example
Worked case: a design has 3 modes (function, test, retention) and 4 PVT corners (SSG 0.72V 125C, SSG 0.72V -40C, FFG 0.88V -40C, FFG 0.88V 125C), giving 12 scenarios total. create_scenario defines each of the 12 with shared common-data (the same gate-level netlist read-in script) and scenario-specific data (that scenario's SDC and operating conditions). current_session includes all 12 for final signoff; during an ECO focused only on a retention-mode hold fix, current_scenario narrows command focus to the 2 retention-mode SSG scenarios where the violation appeared, then is explicitly reset to all 12 before the final report_global_timing confirms the fix did not regress any of the other 10 scenarios.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
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