BeginnerQuestion 78 of 95Source: IC Compiler II Timing Analysis: Creating a Scenario

What is a scenario, and why does signoff run so many of them?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

A scenario is one specific combination of a timing mode and a timing corner, analyzed together as a single, self-contained timing run with its own constraints and its own PVT or RC assumptions. Signoff needs many scenarios because a chip has to work correctly in every mode it can be placed into, under every corner condition the silicon might experience, and a violation hiding in just one untested combination is still a real silicon risk. Running many scenarios is how a design team gets confidence that no single mode-corner combination was left unchecked.

A 3x4 grid of modes by corners with 12 scenario cells, two cells greyed out and marked "dropped, never worst-case" versus 10 active cells — Technical Reference DiagramWhat is a scenario, and why does signoff run so many of them?

Technical Explanation

Each scenario is treated as its own independent analysis, which is what gives real coverage.

In an IC Compiler II hierarchical timing flow, create_scenario -mode func -corner ss_0p81v_125c -name func_ss (ICC2) combines a previously defined mode and corner under one name, so 3 modes and 4 corners can generate up to 12 scenarios.
Each scenario carries its own SDC constraints from its mode and its own PVT or RC assumptions from its corner, so the tool runs an essentially separate analysis per scenario.
Not every combination is equally useful to check daily; teams often mark a smaller "active" subset for everyday runs and reserve the full set for milestone signoff.
Because scenarios are independent, a fix satisfying one, like a buffer added for setup at a slow corner, needs re-checking against every other scenario, since it could hurt hold at a fast corner.
Reporting worst-case results across many scenarios, rather than one, is what lets a team see the true worst negative slack the chip would actually experience.

Common Mistake

The Trap: fixing a violation seen in one scenario's report without checking whether that fix creates a new violation elsewhere.

A buffer inserted to fix setup at the slow-process corner adds delay everywhere it is used, which can push a hold check at the fast-process corner from a small pass into a violation.
Signoff-quality ECO always re-verifies the full scenario set after a fix, not just the targeted one.

Follow-up Question & Model Response

If two scenarios use the exact same mode and the exact same corner, does the design still need to keep both as separate scenarios?

Candidate Model Response: No, and most flows check for and remove exact duplicate scenarios, since analyzing the same combination twice adds runtime without adding coverage. A command for removing duplicate scenarios, modes, and corners exists because a growing scenario set can accumulate duplicates, for example when two engineers each create what they think is a new scenario from the same mode and corner under different names. Keeping the list clean is ordinary signoff hygiene, not a one-time task.

Practical Example

A design with 3 modes and 4 corners initially defines 12 scenarios, but analysis shows the low-power mode at the two middle, typical corners never produces a worse result than the extreme corners for that mode. The team drops those 2 scenarios from routine signoff, running the remaining 10 at every milestone while spot-checking the dropped 2 occasionally.

Complete STA Handbook