How does UPF represent illegal power states, and what mechanisms exist to declare them?

Short Answer

Modern UPF marks a named state illegal with -illegal in add_power_state (UPF), and -complete declares that any state not defined is illegal too. Legacy PST flows declare illegal combinations by omission: any combination missing from the add_pst_state (UPF) rows is not allowed. Implementation reads the legal set to decide where isolation and level shifters go, so a wrong illegal state quietly removes protection.

Technical Explanation

• Explicit: a state defined with -illegal in add_power_state (UPF) names a combination that must never occur; simulation reports an error if it does.
• Complete: -complete on add_power_state (UPF) declares the state list finished, so an object in any undefined state is an error.
• ICC2 default: the ICC2 MV UG treats undefined power states as illegal, even without -complete.
• Legacy PST: the rows of add_pst_state (UPF) are the legal combinations; everything absent is illegal by omission.
• Why it matters: ICC2 uses the legal set to place shifters and isolation, and a combination that never occurs needs neither.
• Refinement differs: 1801-2015 lets -update turn a legal state illegal, but the ICC2 MV UG says you cannot change a legal state to illegal. Declare it illegal up front.
• What breaks: mark a real mode illegal and the cells that mode needs are never inserted, and the static checks agree with the wrong intent.

# [UPF]  mychip.upf
add_power_state PD_DSP.primary -supply -state {HI -supply_expr {power == {FULL_ON 1.1}}} -state {LO -supply_expr {power == {FULL_ON 0.9}}}
add_power_state PD_MYCHIP -domain -state {COP_ON_DSP_LO -logic_expr {PD_COP.primary == ON && PD_DSP.primary == LO} -illegal}
# [ICC2]  icc2_shell
report_pst -derived
check_mv_design
# [VC LP]  vc_static_shell
check_lp -stage upf
report_system_pst

What To Check

• Every illegal state names a combination that truly never occurs in any firmware sequence, transitions included.
• report_pst (ICC2) lists only the combinations you intend as legal.
• Legacy PST rows cover every real mode.
• Isolation and shifter coverage from check_mv_design (ICC2) matches the legal set.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): report_pst (ICC2) shows three legal rows for PD_COP and PD_DSP, and none has PD_COP ON with PD_DSP LO.
• Suspicious (illustrative): A mode the firmware team lists, such as PD_COP ON during a DSP voltage change, is missing from the legal rows.
• Hard stop: A real operating mode is marked illegal, so the crossing it needs was never isolated or shifted.

What The Interviewer Is Testing

• Whether you know the three ways to make a state illegal: an explicit illegal state, a complete state list, and omission from a PST.
• Whether you see that illegal states steer cell insertion, not only simulation.

Follow-up Question & Model Response

"Can you turn a legal state illegal later with -update?"

Candidate Model Response: IEEE 1801-2015 allows it, and its own example updates state GOGO with -illegal. The ICC2 MV UG refinement rules say you cannot change a legal state to an illegal state. A UPF that relies on that update may work in simulation and fail in ICC2. Declare the state illegal in its first definition to keep both tools aligned.