Three of DCRouter's 24 planted bugs are low-power bugs (BUG_20, 21, 22): sleeping with an output locked, port 3 unable to wake the router, credits lost while asleep. All three are functional: ordinary simulation caught them once the stimulus paused and the checks looked (Parts 4 and 5). Now the SoC team adds a power switch that turns DCRouter's domain off entirely. The bugs that move into the plan are different in kind, and ordinary simulation cannot see them.
What does a low-power verification strategy contain?
The obvious plan treats power features like any other features and tests them in ordinary RTL simulation. That works for functional power logic, which is just logic. A powered-off domain, however, does not exist in plain RTL simulation: every signal stays at its last value. Isolation that should clamp outputs, retention that should save state, and sequencing that should order supplies and resets are invisible unless the simulator models power.
Kind | Examples | Verified by |
|---|---|---|
Functional power management | Sleep entry and exit rules, wake sources, clock gating enables, power-controller state machines | Ordinary simulation and assertions (DCRouter's R13, lesson 5.3); formal where properties are written (lesson 7.9's credit conservation covers credits during sleep) |
Structural power intent | Domains, supplies, switches, isolation cells, retention registers, level shifters (fact V10) | Static power-intent checks and power-aware simulation |
The interaction | Software and power controller sequencing domains while traffic is in flight | Power-aware chip-level tests with real software (lesson 8.5) |
Method | Finds |
|---|---|
Static power-intent checks | Missing isolation or level shifters on crossings; retention specified on the wrong registers; supply connection errors |
Power-aware simulation | Logic reading corrupted outputs of an off domain; state not restored after power-up; wrong isolation values; sequencing races |
Ordinary simulation (and formal where properties are written) | Functional sleep and wake logic, wake sources, idle detection (DCRouter's BUG_20, 21, 22) |
Power-aware emulation and silicon | Long software flows through many power transitions |
Features for each power mode and each transition, including transitions with work in flight (lesson 11.7's escape class).
Coverage of the power state machine: every state, every transition, every wake source.
The power intent reviewed and checked statically before power-aware simulation.
Power-aware regression tier for domain-switching tests.
Software power-management sequences as chip-level scenarios.
Practice | Purpose |
|---|---|
Power intent in UPF maintained with the RTL | One description used by simulation, implementation and checks |
Static checks on every power-intent change | Structural errors caught cheaply |
Power-aware simulation of every domain transition | Isolation, retention and sequencing exercised |
A team (illustrative) verified a block's sleep logic thoroughly in ordinary simulation and signed off. In silicon the block's domain was switched off by the power controller while a neighbouring block still read one of its status outputs, which was clamped to the wrong value because its isolation cell had been specified with the wrong clamp value. Ordinary simulation held the output at its last, correct-looking value; only power-aware simulation, which models the domain switching off and the isolation cells taking over, would have shown the bad clamp.
They are functional bugs in DCRouter's sleep logic, which ordinary simulation models; no power domain is switched off.
Their last values, as if the domain were still on, hiding isolation and retention bugs.
Low power has two kinds of risk: functional power logic and structural power intent.
Functional logic needs ordinary methods; power intent needs static checks and power-aware simulation.
Plan every power state, transition and wake source, especially with work in flight.