What is a scenario in multi-corner, multi-mode analysis?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
A scenario is one complete, self-contained timing setup: a single combination of an operating mode (its own SDC constraints, like functional or test mode) and a single PVT corner (its own library, operating condition, and parasitics). PrimeTime analyzes each scenario as if it were a fully separate design, then merges the results, because a design's real behavior depends on which mode and which corner it is actually running under at any given moment.
Technical Explanation
A scenario bundles everything needed to time a design under one specific set of conditions into a single unit the tool can create, select, and analyze on its own.
- A scenario is created explicitly. The
create_scenario -name(PT) command builds a new scenario and specifies the library set, SDC constraints, and parasitics that define it — nothing is inferred automatically from a design's other scenarios. - Mode and corner are independent axes that combine inside one scenario. The mode (functional, scan-shift, low-power standby) decides which SDC constraints apply — different clocks enabled, different case analysis settings. The corner (say, worst-case slow-slow at 0.81V and 125°C, or best-case fast-fast at 0.99V and -40°C) decides which library and operating condition apply. A scenario is one specific mode paired with one specific corner.
current_scenario(PT) switches the tool's command focus. Once several scenarios exist,current_scenario {name}(PT) tells the tool which scenario subsequent reporting and analysis commands apply to, andcurrent_scenario -all(PT) broadens focus back to every scenario at once.- Each scenario is timed independently, worst-case per check. A path's setup slack is evaluated separately under every scenario it belongs to, and the tool reports the worst result across the full scenario set as the signoff number for that path.
- Why the design needs more than one scenario at all: real silicon runs across a range of voltage and temperature and switches between modes, so one scenario proves correctness for only one narrow slice of what the chip has to do.
- What breaks: picking one scenario and calling it the signoff run — a path safe in the functional, typical-corner scenario can still fail in a scan-shift, worst-corner scenario nobody checked.
Common Mistake
The Trap: treating "corner" and "scenario" as the same word, and assuming that covering every PVT corner automatically covers every mode too.
- A designer sets up scenarios for slow-slow, typical, and fast-fast corners, all under the design's default functional-mode SDC, and considers MCMM signoff complete.
- Test mode (scan shift, at-speed test clocking) and low-power standby mode have their own, different SDC — different active clocks, different case analysis settings — so a corner-only scenario set silently skips entire operating conditions the chip will actually experience.
Follow-up Question & Model Response
If a design has 3 modes and 4 PVT corners, does it need 12 scenarios, or could it need more or fewer?
Candidate Model Response: Twelve is the full cross product, a reasonable starting assumption, but rarely the real number. It can be fewer, since not every mode needs every corner — a standby mode might only sign off at its own dedicated low-voltage corner. It can be more, since some modes need extra scenario axes beyond mode and corner, like different clock frequencies or separate hold- and setup-focused RC extraction corners. I would use the mode-by-corner grid as a checklist, then prune or extend it based on what the chip actually needs verified.
Practical Example
A mobile SoC block defines two modes — functional and scan-test — and three PVT corners — slow-slow 0.81V 125°C, typical 0.90V 25°C, and fast-fast 0.99V -40°C. The signoff set uses create_scenario -name func_ssg125 ... (PT) and five sibling calls to build all six mode-corner combinations, skipping the fast-fast scan-test combination because the test SDC is only ever run at the slow corner for hold-critical scan-chain timing. current_scenario -all (PT) is used for the final signoff report so every path's worst-case slack reflects whichever of the five active scenarios stresses it hardest.
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.
Continue practising