The tools report power-state conflicts. How do you resolve them?

Short Answer

A power-state conflict means two parts of the power intent disagree: connected supplies carry different states, or a parent PST uses a voltage the child never defined, so the merge drops that state. Identify which case you have with report_pst -reconcile (ICC2) and report_system_pst (VCLP), then fix the UPF at its source instead of loosening checks until the message goes away.

Technical Explanation

• Connected-supply conflict: two supply nets or ports tied together carry different supply states; ICC2 reports UPF-159 at commit_upf (ICC2).
• Early data check: mv.pst.conflict_supply_state (ICC2) is an error under the strict and normal configurations and tolerated under lenient, where the tool takes the later state.
• Merge conflict: tools intersect parent and child PSTs into one system PST; a parent state whose voltage the child does not allow is dropped.
• Reconcile thresholds: with the upf_reconcile_boundary attribute set to reconcile_voltages, set_variation -tolerance (ICC2) turns block voltages into ranges, so near-miss values such as 0.85 V versus 0.9 V still align.
• VC LP view: check_lp -stage upf (VCLP) reports PST_VOLTAGE_DROPPED for a parent state missing in a child; PST_VOLTAGE_UNUSED is the usually harmless reverse.
• What breaks: a dropped state is a mode software can still enter, and no isolation, level-shifter or timing check ever covers it.

# [ICC2]  icc2_shell
set_early_data_check_policy -checks mv.pst.conflict_supply_state -policy error
load_upf mychip.upf
commit_upf
report_early_data_checks
report_pst -reconcile
# [VC LP]  vc_static_shell
read_upf mychip.upf
check_lp -stage upf
report_violations -app LP
report_system_pst -summary

What To Check

• Every connected pair of supply nets or ports carries one consistent set of states.
• Each top-level mode still exists in the merged system PST, or you can explain why it was dropped.
• Block PST voltages match the top, or a documented tolerance covers the difference.
• The conflict_supply_state policy is error for every signoff run, not lenient.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): report_early_data_checks shows no conflict_supply_state failures and report_system_pst lists all 4 MYCHIP modes.
• Suspicious (illustrative): report_system_pst -summary shows 3 actual system states where the mode spec defines 4.
• Hard stop: commit_upf stops with UPF-159 under the error policy, or check_lp -stage upf reports PST_VOLTAGE_DROPPED on a mode the software uses.

What The Interviewer Is Testing

• Can you tell a connected-supply state conflict from a PST merge that drops states?
• Do you fix the intent at its source instead of widening tolerance or relaxing policy?

Follow-up Question & Model Response

"Why not set the data check policy to lenient so commit_upf finishes?"

Candidate Model Response: Lenient turns the check from error into tolerate, so the tool keeps the later of the two conflicting states and moves on. You have fixed nothing; you let the tool choose which intent wins. That choice then flows into isolation, level-shifter and retention decisions with no one reviewing it. Use lenient only for early exploration with incomplete UPF, and switch back to error before any signoff run.