What happens if save/restore signals have incorrect polarity, and what UPF assertion mechanism catches this?

Short Answer

If the sense you declare in -save_signal or -restore_signal (UPF) does not match how the power controller drives the pin, the retention flop saves at the wrong edge or restores at the wrong time, and the domain wakes up with stale or corrupt state. No option inside set_retention (UPF) checks polarity during implementation. You catch it with a mutex checker attached by bind_checker (UPF) in power-aware simulation, backed by VC LP static checks.

Technical Explanation

• Sense declaration: -save_signal {net sense} (UPF) takes a net plus high, low, posedge or negedge in IEEE 1801; the ICC2 command reference lists only high or low.
• Save event: the retained value is the register value at the save event, which is the chosen edge or the trailing edge of a level-sensitive save.
• Inverted SAVE: the save event lands on the wrong edge, so the shadow latch holds a value from the wrong moment, or X if the rail is already falling.
• Inverted RESTORE: a level-sensitive restore has priority over any other register operation, so one held active in run mode freezes the flop at its retained value.
• Overlap: by default (SAV_RES_COR) simulation corrupts the register while level-sensitive save and restore are both asserted, so a polarity slip shows up as X.
• UPF assertion: IEEE 1801-2015 models save/restore mutex checks as a SystemVerilog checker bound to the strategy signals with bind_checker (UPF).
• Legacy form (still accepted by ICC2/PT): set_retention_control (UPF) with -assert_r_mutex, -assert_s_mutex, -assert_rs_mutex; ICC2 parses and ignores these three options.

# [UPF]  design.upf
set_retention RET_COP -domain PD_COP -retention_supply SS_AON -save_signal {U_PC/SRE posedge} -restore_signal {U_PC/SRE negedge} -retention_condition {U_PC/SRE}
bind_checker ret_mutex_chk -module ret_mutex_checker -ports {{save PD_COP.RET_COP.save_signal} {restore PD_COP.RET_COP.restore_signal}}
# [ICC2]  icc2_shell
report_mv_cells -retention
# [VC LP]  vc_static_shell
check_lp -stage upf
report_violations -app LP

What To Check

• The sense of each save and restore signal matches the controller RTL, edge for edge.
• The declared sense matches the save/restore pin polarity of the mapped retention cell.
• A mutex checker is bound to every retention strategy in power-aware simulation.
• No net drives several retention strategies with opposite polarities.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Simulation of PD_COP power-down shows save on the SRE rising edge, restore on the falling edge, and the checker never fires.
• Suspicious (illustrative): The checker is silent, but only one of the four PD_COP test sequences reaches the restore edge.
• Hard stop: The checker fires, or the register reads X after wake-up in power-aware simulation.

What The Interviewer Is Testing

• Do you know what the sense field in -save_signal really controls?
• Can you name an assertion path that works in 1801-2015, not just the legacy option?
• Do you know which checks ICC2 actually enforces and which it ignores?

Follow-up Question & Model Response

"How would a polarity bug look different for a level-sensitive restore versus an edge-triggered one?"

Candidate Model Response: With a level-sensitive restore, the inverted signal sits active through run mode. Because restore has priority, the flop ignores its D input and keeps reloading the retained value, so the domain looks frozen. With an edge-triggered restore, the restore fires on the wrong edge, often at power-down, and the flop loads whatever the shadow latch held then. The first shows up as stuck logic in every test; the second only as wrong values after a full power cycle.