Why doesn't signoff run every operating mode against every PVT corner?

Short Answer

Running every mode against every corner is the safest possible coverage, but it is also the most expensive: each additional scenario costs real machine time and license usage to analyze, and many mode-corner combinations are physically impossible or already known to be dominated by a different combination. Teams prune the full cross product down to the combinations that can actually happen and that actually stress a check, rather than paying for scenarios that provide no new information.

Technical Explanation

The full mode-by-corner grid is the conceptual starting point, but very few real signoff plans use every cell in it.

• Some combinations are physically impossible. A low-power standby mode may only ever operate at a specific reduced voltage rail, so pairing it with a high-voltage, fast-fast corner describes a condition the chip can never actually be in.
• Some combinations are dominated by another. If a mode's setup timing is always worse at the slow-slow corner than at typical or fast-fast for every path in the design, running the typical and fast-fast versions of that mode for a setup check adds cost without changing which paths get flagged.
• Scenario count drives real machine cost. Each scenario is a separate timing analysis with its own memory and runtime, so create_scenario (PT) calls multiply directly into compute cost and turnaround time — a design with dozens of unnecessary combinations can turn a same-day signoff run into an overnight one.
• Pruning is a documented decision, not a shortcut. A scenario that gets dropped from the plan needs a stated reason — physically impossible, provably dominated by another scenario — recorded somewhere a reviewer can check, not silently omitted.
• Why it matters: MCMM signoff aims for complete coverage of what the chip can really do, not maximum scenario count — an unpruned cross product wastes compute while a carelessly pruned one leaves real conditions unchecked.

Follow-up Question & Model Response

How would you prove a scenario is genuinely dominated by another one, rather than just assuming it?

Candidate Model Response: I would run the candidate scenario at least once on the real design and compare its worst-case slack for the relevant check against the suspected dominant scenario, path by path. If every path's slack in the candidate is equal to or better, that is real evidence, not intuition. I would also re-verify after any significant design change — a different cell mix, a new voltage domain, a library update — since domination proven once is not guaranteed to hold forever.