How do you keep implementing when the UPF isn't finished yet?

Short Answer

Use the early data check manager: set_early_data_check_policy (ICC2) sets how each multivoltage check reacts (error, tolerate or repair), and report_early_data_checks (ICC2) lists what was relaxed and how often it fired. The older route is the incomplete UPF flow, enabled with mv.incomplete_upf.enable (ICC2). Either way the tool is guessing at missing intent, so every relaxed check must be closed before signoff.

Technical Explanation

• Global policy: -policy strict | lenient | normal without -checks. Lenient drops every check to its lowest severity; strict raises every check to its highest.
• Normal: checks report early data issues but the flow and optimization behave as default, so you can relax one area without touching the rest.
• Per-check policy: add -checks; levels run error, tolerate, repair. At error, invalid mapped cells drop the strategy (UPF-108); repair infers a missing voltage area.
• One-way ratchet: once set, a policy cannot move to a stricter setting without reset_upf (ICC2). The one exception is the missing voltage area check.
• Legacy flow: mv.incomplete_upf.enable (ICC2) makes the tool ignore listed UPF errors, for example using the first of two conflicting power states.
• Do not mix: any data check manager command disables the legacy flow, and a global policy makes ICC2 ignore the incomplete UPF app options.
• What breaks: a tolerated conflict means the tool picked a state for you, so MV cells and timing follow a guess nobody reviewed.

# [ICC2]  icc2_shell
set_early_data_check_policy -policy normal
set_early_data_check_policy -policy lenient -checks mv.pst.conflict_supply_state
load_upf mychip.upf
commit_upf
report_early_data_checks
get_early_data_check_records

What To Check

• Which checks run below error, and who owns the UPF fix for each.
• The fail count of each relaxed check falling to zero over the weeks.
• That the signoff run starts from a clean session with no relaxed policy.
• No script sets both a global policy and the legacy incomplete UPF option.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): The report shows one relaxed check, mv.pst.conflict_supply_state at tolerate with a fail count of 1, and a ticket against it.
• Suspicious (illustrative): A second relaxed check appears that nobody set on purpose, such as an invalid library cell list being tolerated.
• Hard stop: The signoff run still shows any tolerated or repaired check: the netlist was built on guessed power intent.

What The Interviewer Is Testing

• Do you know how to unblock a flow without hiding the problem?
• Can you name the three global settings and the three per-check policy levels?

Follow-up Question & Model Response

"Your UPF has conflicting supply states on two connected supplies. What does the tool do under each policy?"

Candidate Model Response: With the check at error, commit_upf (ICC2) stops with UPF-159 naming both states and both supplies. At tolerate, it continues and takes the later state, and the verbose report records that choice. That is fine for floorplan trials, never for signoff. The real fix is in the UPF: make the two power state definitions agree or remove one.