What happens if save/restore signals have incorrect polarity, and what UPF assertion mechanism catches this?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Technical Explanation
set_retention_control's -save_signal and -restore_signal each carry an explicit sense ({sig high} or {sig low}). If the declared sense doesn't match how the signal is actually driven, the retention register could save or restore at the wrong time — or worse, save and restore could both appear active simultaneously, which is logically incoherent. UPF provides a built-in consistency check for exactly this: set_retention_control's -assert_r_mutex, -assert_s_mutex, and assert_rs_mutex options, which assert that the save and restore signals are mutually exclusive — the clearest error-prevention mechanism available for retention correctness.
Architecture-level Reasoning
Save and restore are supposed to be mutually exclusive conditions by construction (you cannot be saving state and restoring it at the same instant), so building a mutual-exclusion assertion directly into the retention-control command gives the tool a direct way to catch a polarity or sequencing bug rather than only discovering it through simulation mismatches.
Step-by-step Walkthrough
1) Declare the retention control strategy with explicit senses: set_retention_control UP_RET_POLICY -domain PD_UP -save_signal {NSAV low} -restore_signal {RETN high}. 2) Add -assert_r_mutex/assert_s_mutex/-assert_rs_mutex to have the tool assert that save and restore cannot be simultaneously active given the declared senses. 3) If the actual driven polarity of NSAV or RETN doesn't match what was declared, the mutual-exclusion assertion is the mechanism positioned to flag the inconsistency. Note: in some tool implementations, -assert_r_mutex/-assert_s_mutex/assert_rs_mutex on set_retention_control are parsed but ignored — so this assertion mechanism is not necessarily enforced by every tool implementation.
Command
set_retention_control PD_COP_RET -domain PD_COP -save_signal {U_PC/
SRE high} -restore_signal {U_PC/SRE low} -assert_r_mutex assert_s_mutex -assert_rs_mutexSwitch-by-switch
-save_signal {sig high|low}: the save control net and its active
sense. -restore_signal {sig high|low}: the restore control net
and its active sense. -assert_r_mutex / -assert_s_mutex / assert_rs_mutex: built-in checks asserting save and restore are
mutually exclusive given the declared senses.Expected Result
Save and restore signals whose declared senses correctly reflect how they are actually driven, with the mutual-exclusion assertions (where enforced) confirming save and restore are never simultaneously active.
Possible Implementation Error
Declaring -restore_signal {RETN high} when RETN is actually driven active-low in the real control logic, so the retention register is commanded to restore at the wrong time relative to the intended sequence — or, in the Mychip example, using the same signal U_PC/SRE for both save (high) and restore (low), which depends entirely on that single signal's sense being exactly right in both directions.
Likely Tool / Clp Warning
In some tool versions, -assert_r_mutex/-assert_s_mutex/assert_rs_mutex on set_retention_control are parsed but ignored — so a polarity bug protected only by these assertions may not actually be flagged, even though they are the intended mutual-exclusion mechanism.
Root Cause
The save/restore sense is a plain user-declared attribute in set_retention_control with no independent verification against the actual RTL/UPF drive polarity beyond the (possibly-ignored) mutual-exclusion assertions.
Debugging Sequence
1) Trace the actual driven polarity of the save and restore signals back to the power controller RTL/UPF. 2) Compare against the {sig high|low} declarations in set_retention_control. 3) Confirm whether the specific tool version in use actually enforces -assert_r_mutex/-assert_s_mutex/-assert_rs_mutex, or only parses and ignores them, before relying on the assertion as a safety net. A save/restore polarity mismatch is a functional correctness defect (state corruption on shutdown/wake) that must be verified independently before signoff, especially if the assertion mechanism is not enforced by the tool version in use.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising