What changed between legacy UPF and IEEE 1801-2015, and why does add_power_state replace the PST?

Short Answer

IEEE 1801-2015 Annex D marks the PST commands create_pst (UPF), add_pst_state (UPF) and add_port_state (UPF), plus set_domain_supply_net (UPF) and the net-based isolation and retention supply options, as legacy, and names a replacement for each. The PST gives way to add_power_state (UPF), which defines states on supply sets and domains instead of in one flat table. Tools still accept both forms, and interviews ask about both.

Technical Explanation

• Power states: on a supply set, add_power_state (UPF) uses -supply_expr with states and voltages; on a domain it uses -logic_expr over supply set states.
• Why replace the PST: a flat table grows with every supply combination, while per-object states compose up the hierarchy and refine later with -update.
• Supplies: Annex D replaces set_domain_supply_net (UPF) with associate_supply_set (UPF); create_power_domain -supply {primary SS_COP} (UPF) does the same binding.
• Strategy supplies: -isolation_power_net/-isolation_ground_net become -isolation_supply, and -retention_power_net/-retention_ground_net become -retention_supply.
• UPF 1.0 forms: set_isolation_control (UPF) and set_retention_control (UPF) are absent from 1801-2015; their signals move onto set_isolation (UPF) and set_retention (UPF).
• Placement rule: supply expressions and simstates belong on supply set states only; on a domain state both are errors.
• Tool support: ICC2 reads both forms; PT ignores the PST commands and takes voltages from set_voltage (PT).

# [UPF]  design.upf
add_power_state SS_COP -state ON {-supply_expr {power == {FULL_ON 1.0} && ground == {FULL_ON 0.0}}}
add_power_state SS_COP -state OFF {-supply_expr {power == {OFF}}}
add_power_state -domain PD_COP -state RUN {-logic_expr {SS_COP == ON}}
add_power_state -domain PD_COP -state SLEEP {-logic_expr {SS_COP == OFF}}
# Legacy PST form (still accepted by ICC2/PT)
add_port_state SW_COP/vout -state {ON 1.0} -state {OFF off}
create_pst PST_MYCHIP -supplies {VDD1p0 VDD1p0_SW}
add_pst_state S_RUN -pst PST_MYCHIP -state {ON ON}
add_pst_state S_SLEEP -pst PST_MYCHIP -state {ON OFF}
# [ICC2]  icc2_shell
report_pst -derived

What To Check

• Every supply set with more than one state defines all of them, OFF included.
• Domain states refer to supply set states, never to supply nets.
• Each supply set uses one add_power_state syntax style throughout; ICC2 rejects mixed styles on one object.
• The legal combinations in report_pst -derived (ICC2) match the architecture spec.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): The PST report lists RUN and SLEEP for PD_COP with VDD1p0 always ON, matching the architecture spec.
• Suspicious (illustrative): A combination appears that nobody intended, or one you expected is missing: look for an undefined state on a supply set.
• Hard stop: The tool rejects a domain state written with a supply expression: nothing downstream has valid power states.

What The Interviewer Is Testing

• Can you map each legacy construct to its 1801-2015 replacement?
• Do you know where supply and logic expressions are each allowed?

Follow-up Question & Model Response

"If the tools still accept create_pst, why migrate?"

Candidate Model Response: The flat table grows with every supply you add, and it cannot express hierarchy or refinement cleanly. With add_power_state, each IP ships its own supply set and domain states, and the SoC composes them with logic expressions. You can refine states later with -update, which suits successive refinement from RTL to implementation. Staying legacy works today, but every IP that arrives in modern form forces a translation.