When several retention strategies could apply to a register, which one wins?

Short Answer

ICC2 resolves overlapping retention strategies by granularity, not by the order you wrote them: an explicitly named register beats a Verilog process or always block, which beats an instance, which beats a strategy that names only the domain. A -no_retention strategy outranks a retaining one, but a finer retaining strategy still wins over a coarser -no_retention, and a true tie goes to the strategy created first.

Technical Explanation

• Granularity order: explicit register in -elements, then a Verilog process or always block, then an instance in -elements, then a domain-only strategy.
• -no_retention: outranks strategies without it, yet the ICC2 MV UG example shows a register-level retain beating an instance-level -no_retention.
• Ties: when two strategies at one level claim a register, the first created keeps it and the register is removed from the later one.
• Retention lists: set_retention_elements (UPF) names registers that must be retained together or not at all; a partly retained list is an error.
• Refinement: set_retention (UPF) with -update unions new -elements into a strategy, but cannot turn a domain-based strategy into an element-based one.
• Type filter: -applies_to flop or latch restricts element type and does not change precedence.
• Legacy form (still accepted by ICC2/PT): set_retention_control (UPF) carrying the save and restore signals, with -retention_power_net on the strategy.

# [UPF]  mychip.upf
set_retention RET_ALL -domain PD_COP -retention_supply SS_AON -save_signal {cop_save high} -restore_signal {cop_restore high}
set_retention RET_DBG -domain PD_COP -elements {U_COP/u_dbg} -no_retention
set_retention RET_KEY -domain PD_COP -elements {U_COP/u_dbg/key_reg} -retention_supply SS_AON -save_signal {cop_save high} -restore_signal {cop_restore high}
set_retention_elements RL_FSM -elements {U_COP/u_fsm/state_reg U_COP/u_fsm/cnt_reg}
set_retention RET_FSM -domain PD_COP -elements {RL_FSM} -retention_supply SS_AON -save_signal {cop_save high} -restore_signal {cop_restore high}
set_retention RET_KEY -domain PD_COP -update -elements {U_COP/u_dbg/key2_reg}
# [ICC2]  icc2_shell
report_mv_cells -retention
check_mv_design -retention

What To Check

• For each register, list every strategy that could claim it and the level each works at.
• No domain-wide strategy is expected to override a finer one.
• Retention lists are covered completely by one retaining strategy.
• Every retaining strategy has save and restore signals and an always-on retention supply.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): report_mv_cells -retention shows key_reg and key2_reg retained under RET_KEY, the rest of u_dbg as plain flops, and all other PD_COP flops under RET_ALL or RET_FSM.
• Suspicious (illustrative): U_COP/u_fsm/cnt_reg is retained by RET_ALL instead of RET_FSM, so the list is not being applied as written.
• Hard stop: Only one register of RL_FSM is retained, a partly retained list that the standard treats as an error.

What The Interviewer Is Testing

• Can you rank strategies by granularity without relying on file order?
• Do you know how -no_retention and retention lists interact with precedence?

Follow-up Question & Model Response

"You want all of u_dbg unretained except one key register. How do you write it?"

Candidate Model Response: Put -no_retention on the u_dbg instance and a retaining strategy on the key register by name. The register-level strategy is finer, so it beats the instance-level -no_retention for that one flop. Everything else in u_dbg falls under -no_retention, which outranks the domain-wide RET_ALL at the instance level. report_mv_cells -retention should then show exactly one retention cell in u_dbg.