What is power-state-table (PST) state explosion, and how does it constrain how many independently-switchable domains a real design can have?

Short Answer

Every independent supply multiplies the number of possible system states, so N supplies with k states each give k to the power N combinations. Tools, verification and your own review all scale with that number, which is why real designs declare only the handful of states the product uses and mark the rest illegal. It also pushes architects to tie domains together so they switch as a group instead of independently.

Technical Explanation

• Growth: 100 independent supplies with three states each (1.0 V, 0.5 V, OFF) can reach 3 to the power 100 system states, per the ICC2 MV UG.
• Why it hurts: ICC2 builds one design-level PST and derives isolation and level-shifter needs from it, so runtime and reports grow with every state.
• Modern answer: define supply states with add_power_state (UPF), then name only real system states in a create_power_state_group (UPF) group.
• Close the table: -complete on add_power_state (UPF) makes any undefined combination illegal, and -illegal marks a specific state as unreachable.
• Tool limits: ICC2 stops building the system PST after 36000 s by default; mv.upf.system_pst_building_time_limit (ICC2) changes that.
• Hidden cause: a broken top-to-block supply connection makes supplies look independent; report_supply_net_groups (ICC2) exposes undriven supply net groups.
• Legacy form (still accepted by ICC2/PT): create_pst (UPF) and add_pst_state (UPF), one row per state over a list of supply ports.

# [UPF]  design.upf
add_power_state SS_GPU -supply -state {ON -supply_expr {power == {FULL_ON 0.9}}} -state {OFF -supply_expr {power == {OFF}}}
create_power_state_group PSG_SOC
add_power_state PSG_SOC -group -state {RUN -logic_expr {SS_CPU == ON && SS_GPU == ON}} -state {GPU_IDLE -logic_expr {SS_CPU == ON && SS_GPU == OFF}}
add_power_state PSG_SOC -group -update -complete
# [ICC2]  icc2_shell
report_supply_net_groups
report_pst -derived -pst_state_limit 1000
set_app_options -name mv.upf.system_pst_building_time_limit -value 3600

Formula Or Decision Rule

• Upper bound: states_max = k1 × k2 × … × kN, which is k^N when every supply has k states.
• Five supplies at three states: 3^5 = 243 possible states.
• Decision rule: declare the states your use cases need, close the table with -complete, and merge domains that always switch together.

What To Check

• The number of declared system states matches the product use-case list.
• Supply groups are closed with -complete, so unlisted combinations are illegal.
• Top and block supplies are connected, not floating as independent groups.
• report_pst -derived finishes and its state count makes sense.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): report_pst -derived shows 6 system states for 5 supplies, matching the use-case list.
• Suspicious (illustrative): The derived table shows 40 states when the architecture lists 6.
• Hard stop: report_supply_net_groups shows block supplies with no driver, or the PST build hits its time limit.

What The Interviewer Is Testing

• Can you size the state space and explain why the tool cares?
• Do you know how 1801-2015 closes a state table?
• Would you check supply connectivity before blaming the tool?

Follow-up Question & Model Response

"How does the state count limit how many independent domains you can have?"

Candidate Model Response: Each independent domain multiplies both the verification space and the crossings the tools must reason about. In practice teams cap truly independent domains and group the rest under shared control, so several blocks count as one supply state. Hierarchy helps too: block PSTs stay local and only a few states reach the top. The limit is less a hard number than how many states you can verify and sign off with confidence.