How do you decide which scenarios to merge versus keep separate in a signoff run?

Short Answer

Two MCMM scenarios can be merged into one report only when they share the same constraints on every path the report will show, which usually means the same mode and enough corner similarity that neither scenario's worst path is masked by the other's. Scenarios get kept separate whenever a designer needs to trace a violation back to a specific mode or corner, since a merged view can only show the worst number across whatever it combined, not which scenario produced it.

Technical Explanation

A scenario in multi-mode multi-corner (MCMM) analysis is one specific combination of mode -- a functional configuration, like scan-shift or functional-mission -- and corner, each with its own SDC and library set.

• Merging scenarios for a report means combining slack numbers from several scenarios into one table, showing only the worst slack per endpoint across whatever was merged.
• Merging is safe for scenarios that genuinely share the same failure mechanism, such as reporting the worst setup slack across a family of PVT/SPEF corner variants under the same functional mode, because the designer only needs the single worst number, not which corner produced it.
• Merging is unsafe across different modes, because a violation appearing under scan-shift but not under functional-mission needs its own fix path -- masking it inside a merged worst-across-all-scenarios number can make a scan-specific bug look like it belongs to whichever scenario happened to report the worst slack.
• Keeping scenarios separate costs runtime and report volume -- every additional scenario is another full timing solve -- so a signoff plan balances how many distinct scenarios are truly needed against how many can be safely represented by their shared worst case.
• A union view answers whether there is any violation anywhere across a merged set, while a per-scenario view answers exactly where it is, and signoff typically needs both, at different stages of debug.

Follow-up Question & Model Response

If a merged report already shows the true worst-case slack across all scenarios, why would a designer ever need the per-scenario breakdown at all?

Candidate Model Response: The merged worst-case number answers whether a violation exists anywhere in the scenario set, but it says nothing about which scenario, and therefore which fix, applies -- an ECO that helps the scenario shown in the merge might do nothing for a different scenario hiding a comparable violation underneath it. Debugging and ECO planning both need to know the actual mode and corner responsible, since a fix targeted at the wrong scenario's constraints can pass the merged check while leaving the real violation in place. The per-scenario breakdown is also the only way to catch a violation that is not the global worst but still fails its own scenario's signoff bar. In practice, teams use the merged view to triage whether there is any problem at all, and the per-scenario view to actually close it.