IntermediateQuestion 89 of 112Source: Synopsys PrimeTime User Guide: Multiple Scenario Analysis

How do you switch between scenarios during an interactive PrimeTime session?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

The current_scenario (PT) command changes which scenario subsequent commands apply to, whether that is one specific scenario, a chosen subset, or every scenario at once with the -all option. This matters because most PrimeTime reporting and analysis commands act on whatever scenario currently has command focus, not on the whole design by default.

Technical Reference DiagramHow do you switch between scenarios during an interactive PrimeTime session?
A PrimeTime session with five scenario icons, showing current_scenario focus narrowing from all five down to one specific scenario for debugging, then widening back to all five before the final signoff report.

Technical Explanation

Once a session has more than one scenario, the tool needs a clear, explicit answer to "which one am I looking at right now," and that is exactly what this command controls.

  • By default, all scenarios are in focus. Right after several scenarios are created, the manager session usually has every scenario in the current scope, so a report at that point reflects the worst case across all of them.
  • current_scenario {name} (PT) narrows focus to one scenario. For example, current_scenario {scen1} (PT) restricts the following commands — a report_timing (PT) call, say — to that scenario's own library, SDC, and parasitics.
  • A list narrows focus to a chosen subset. current_scenario {s1 s2} (PT) restricts focus to exactly those two scenarios, useful when debugging a violation that only appears in a couple of related scenarios out of a much larger set.
  • current_scenario -all (PT) restores full scope. After debugging inside a narrowed focus, this brings every scenario back into view for a comprehensive report.
  • This is a command-focus setting, not a data change. Switching current_scenario does not re-run analysis or modify any scenario's data — it only changes which scenario's already-computed results the next command reads or reports on.
  • Why it matters: a designer debugging one specific violation wants to look at exactly the scenario where it occurs, not a merged, worst-case-across-everything view that can obscure which scenario is actually responsible for the failure.

Common Mistake

The Trap: running report_timing (PT) on a specific path while command focus is still set to -all, and reading the result as if it came from one particular scenario.

  • A designer investigating a violation flagged in a signoff summary reruns report_timing immediately, without first narrowing current_scenario to the exact scenario named in that summary.
  • The report returned reflects the worst case across every scenario in focus, which can be a different scenario than the one the summary actually flagged, leading to a debugging session chasing the wrong corner or mode entirely.

Follow-up Question & Model Response

If you forget to reset current_scenario back to -all after narrowing it down to debug one scenario, what is the risk on your next signoff report?

Candidate Model Response: The risk is a signoff report that silently only reflects the narrowed scenario, not the full scenario set, even though nothing in the command syntax announces that scope has changed. If the debug session leaves focus on a single best-case scenario and someone later runs a summary report assuming it covers everything, real violations sitting only in a worse scenario that is currently out of focus would not appear at all. I would make resetting current_scenario -all (PT) an explicit, scripted last step of any debugging sequence, rather than relying on remembering to type it interactively.

Practical Example

A signoff summary flags a -14ps setup violation on core/u_alu/sum_reg[7]/D in scenario func_ssg125. The designer runs current_scenario {func_ssg125} (PT), then report_timing -to core/u_alu/sum_reg[7]/D (PT), confirming the exact -14ps number and the specific corner's library causing it. After identifying a buffer resize as the fix, the designer runs current_scenario -all (PT) before the next full-design report_global_timing (PT) pass, to confirm the fix does not regress any of the other four active scenarios.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
VLSI Physical Design Planning Handbook — fourteen chaptersDesign PlanningFourteen chapters, floorplanning through timing budgets. →

Continue practising

Related STA questions

IntermediateWhat is a scenario in multi-corner, multi-mode analysis?IntermediateHow do you report timing results across all scenarios at once in PrimeTime?ExpertWhat is MCMM/DMSA (multi-mode multi-corner / distributed multiscenario analysis), and what commands does PrimeTime provide to manage it?IntermediateWhat information does a scenario need besides a corner, library, and clock definition?