What is power-aware simulation, and what does "corruption" mean?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Short Answer
Power-aware simulation runs your RTL or netlist together with the UPF, so supplies can switch off during a test. When a supply set enters a state whose simstate is CORRUPT, the simulator corrupts what it powers: state elements and the nets they drive go to X, and those processes stop evaluating. That turns a missing clamp, a controller that switches in the wrong order, or a retention register restored too early into visible X on signals your testbench already checks.
Technical Explanation
- Simstates: each supply set power state carries a simstate. The predefined ON state is NORMAL, and OFF and ERROR are CORRUPT.
- CORRUPT: powered state elements and the nets they drive take the HDL default value (X for 4-state logic and VHDL std_logic) and stop evaluating.
- Partial states: CORRUPT_ON_ACTIVITY, CORRUPT_ON_CHANGE and two CORRUPT_STATE forms model weak supplies; NOT_NORMAL is a placeholder treated as CORRUPT, never NORMAL.
- Retention in sim: the retained value survives while the retention supply is on, but a save or restore attempted while the domain is off corrupts it.
- Isolation in sim: a clamped output stays clean unless the isolation control is corrupted or the isolation supply leaves NORMAL.
- Declare it:
add_power_state SS_COP -state OFF {-supply_expr {power == {OFF}} -simstate CORRUPT}(UPF) attaches the simstate to a supply set state. - Implementation ignores it: ICC2 keeps
-simstatein the output UPF but does not use it for implementation.
Common Mistake
The Trap: Defining a custom shutdown state, say SLEEP on SS_COP, by copying the ON line, so it carries -simstate NORMAL.
- U_COP keeps evaluating while its rail is off, so no X appears and every missing clamp passes; 1801-2015 also forbids a later
-updatefrom changing that simstate. - Give each shutdown state a CORRUPT simstate on the supply set state; a simstate on a power domain state is an error in 1801-2015.
Follow-up Question & Model Response
"What bugs does power-aware simulation find that a static checker like VC LP does not?"
Candidate Model Response: Static checks prove structure: the isolation cell exists, its supply is right and its enable is the UPF signal. Simulation proves behaviour over time, such as the controller releasing ISE before PD_COP finished restoring. It also shows whether firmware drives the power controller in the right order, and whether a restore fires before the rail is back. Static tools cannot judge that, because they do not know when each signal toggles. You need both, since a perfectly built design can still be sequenced wrong.
Practical Example
Design Scenario: (illustrative) A test powers down PD_COP by driving the switch enable low. SS_COP enters OFF with simstate CORRUPT, and U_COP outputs go to X. Outputs through ISO_COP_OUT stay at clamp 0 into PD_CPU, but U_COP/irq_out, which the strategy missed, carries X into U_CPU and an interrupt status register goes X. The same test shows a second bug on wake: ISE releases two cycles before RESTORE completes, so PD_CPU samples X for those two cycles. A static check would also catch the first bug, but the second only exists in time. The fix list is one extra element in ISO_COP_OUT and a longer wait in the controller.
Low-Power & UPF Handbook
Master Low-Power VLSI & Multivoltage Design
Read the complete low-power guide library covering power domains, level shifters, isolation clamps, state retention, and UPF signoff verification.
Continue practising