After wake-up, retained registers come back with wrong values. How do you debug it?

Short Answer

Wrong values after wake-up almost always come from the control sequence or the retention supply, not the flop. Check in order that the retention supply stayed on, that RESTORE came after the primary rail was stable and before clocks restarted, that save and restore polarity match the cells, and, for zero-pin retention cells, that check_lp -stage design (VCLP) reports no RET_CLAMP_INVERT.

Technical Explanation

• Retention supply: the shadow latch runs on the retention supply; if that supply is switched with PD_COP, saved state is gone after sleep.
• RESTORE too early: restoring before VDD1p0_SW settles writes the saved value into a master stage that is not yet reliably powered.
• Clock during restore: a clock edge during or just after restore overwrites the restored value with whatever sits on the D input.
• Polarity: set_retention (UPF) with -save_signal {cop_save high} must match the controller; an inverted sense saves at the wrong time or never.
• Zero-pin retention: these cells retain while clock is clamped low and reset clamped high; an odd number of inverters after a NOR-style clamp gives RET_CLAMP_INVERT.
• Reports: report_mv_cells -retention_clamp (ICC2) lists zero-pin clamp cells; check_mv_design (ICC2) checks clamp values and that clamps run on an always-on supply.
• Legacy form (still accepted by ICC2/PT): set_retention_control (UPF) carrying -save_signal and -restore_signal, with -retention_power_net on the strategy.

# [UPF]  mychip.upf
set_retention RET_COP -domain PD_COP -retention_supply SS_AON -save_signal {cop_save high} -restore_signal {cop_restore high}
# [ICC2]  icc2_shell
report_mv_cells -retention
report_mv_cells -retention_clamp -verbose
check_mv_design -retention
# [VC LP]  vc_static_shell
check_lp -stage design
report_violations -app LP

What To Check

• RET_COP uses SS_AON, which is on in every state where PD_COP is off.
• In simulation, cop_restore rises after pse_ack and while clocks are still stopped.
• Save and restore sense in the UPF match the controller and the library pins.
• Zero-pin retention clamp paths have an even inverter count and clamps on an always-on supply.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Power-aware simulation restores all 1,200 retained flops across 50 sleep cycles, and check_lp -stage design is clean.
• Suspicious (illustrative): Restores pass, but cop_restore rises only 5 ns after pse_ack with no agreed margin.
• Hard stop: RET_CLAMP_INVERT on a U_COP clock clamp path, or RET_COP's retention supply resolves to VDD1p0_SW.

What The Interviewer Is Testing

• Do you debug the sequence and supplies before blaming the retention cell?
• Do you know the zero-pin retention clamp rule and how VC LP reports it?

Follow-up Question & Model Response

"How do you tell a restore-too-early bug from a clock-during-restore bug in simulation?"

Candidate Model Response: Look at when the wrong value appears. If Q is wrong right at the restore pulse and the primary rail was still ramping, the restore came too early. If Q is correct after restore and changes on the first clock edge, the clock started before the inputs were valid or before RESTORE finished. Power-aware simulation shows both clearly, because corrupted values appear as X until the rail is valid.