AdvancedQuestion 1 of 63

Explain the precedence interaction when an explicit -sms_scenarios option and an active push_sms_scenario context both apply to a command.

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

A DVFS scenario (one voltage/frequency operating point in a design that switches between several) can reach a command two ways: typed on the command as -sms_scenarios (PT), or inherited from a push_sms_scenario (PT) context around it. The explicit option always wins, and the pushed context is ignored for that command, not merged with it.

Two DVFS scenarios built with get_sms_scenarios, low_mid and high_only: a pushed context box for low_mid surrounds a command carrying an explicit -sms_scenarios high_only option, with an arrow showing the command uses only high_only while a get_current_sms_scenario query beside it still reads low_mid from the context stack — Technical Reference DiagramExplain the precedence interaction when an explicit -sms_scenarios option and an active push_sms_scenario context both apply to a command.

Technical Reference DiagramExplain the precedence interaction when an explicit -sms_scenarios option and an active push_sms_scenario context both apply to a command.

Technical Explanation

Two paths to the same setting. A command can learn which DVFS scenario to use explicitly, through its own -sms_scenarios (PT) option, or implicitly, by running inside a block opened with push_sms_scenario (PT). Both are legal on the same script.
Explicit always wins. When a command carries -sms_scenarios and also sits inside a pushed context, PrimeTime uses only the explicit option. The pushed context is not merged with it and not intersected with it - it is dropped for that one command.
Why the tool picks this way. The rule matches how every other scoping decision in PrimeTime works: the narrower, closer instruction beats the broader, farther one. A pushed context describes a whole region of a script; an option typed on one command describes just that command, so it is assumed to be the more deliberate choice.
The trap this creates in debug. get_current_sms_scenario (PT) still reports the pushed context, because that query describes the context stack, not any single command's scoping decision. You can query it, see the pushed scenario, and still have the very next command running under a completely different one.
What breaks if you assume they merge. Someone reading a report expects the command to reflect both, and instead the tool applied only the explicit list; a scenario the author thought was excluded still shows up in the results.
How to check what actually scoped a command. Read the command's own option, not the context. If a command has no -sms_scenarios, then and only then does the pushed context apply to it.

Common Mistake

Assuming a push_sms_scenario wrapped around a whole block of script also narrows a command inside it that already carries its own -sms_scenarios.
The pushed context is invisible in the command's own output, so the mistake surfaces only when a report includes a scenario the author meant to exclude.
Cost: a signoff report that silently includes an extra DVFS scenario, which can hide a real violation specific to that scenario or waste review time chasing one that should never have appeared.

Follow-up Question & Model Response

If a script pushes scenario A, then calls a command with -sms_scenarios B, then calls get_current_sms_scenario right after - what does each step report, and why don't they agree?

Candidate Model Response: The command with the explicit option runs entirely under scenario B, and its report reflects only B - the pushed A is set aside for that call. The very next get_current_sms_scenario call, though, still reports A, because it is reading the open context stack, not asking what scoped the previous command. The two are not contradicting each other; they answer different questions - one is "what did this command use," the other is "what context is currently open." Once you separate those two questions, the mismatch stops looking like a bug.

Practical Example

A DVFS design has a supply group VDDC with three named voltage references: low, mid, high. A script builds set low_mid [get_sms_scenarios -supply_group VDDC -reference_names {low mid}] (PT) and opens push_sms_scenario -sms_scenario low_mid (PT) to scope a whole review section to the two lower-voltage states, then inside it builds set high_only [get_sms_scenarios -supply_group VDDC -reference_names {high}] and runs report_timing -sms_scenarios high_only (PT) to spot-check the high-voltage state without leaving the block. That one report_timing call reports only the high state, ignoring the pushed pair entirely. A get_current_sms_scenario call two lines later still returns the $low_mid scenario, confirming the push is still active for whatever command runs next without its own explicit option.