Review low-power transitions as system behaviour

The transition matters as much as the state

A low-power design is often described by its operating states, but many difficult behaviours occur while moving between them. A subsystem can be idle, active, isolated, retained or powered down, with software and hardware coordinating the transitions. The review must explain which sequences are legal and how the rest of the system observes them.

This brief is about planning and verification. It does not report a measured power reduction or prescribe a universal power architecture. The actual design intent, technology, libraries and product requirements determine which mechanisms are available and what evidence is required.

Build a shared state model

List power domains, supply states, clocks, resets and externally visible interfaces. Identify the owner of each transition request and acknowledgement. State whether outstanding work must finish, be canceled or be preserved before the transition proceeds. Without that contract, firmware and hardware can each behave reasonably while disagreeing about when shutdown is safe.

Map retention and initialization requirements to specific state elements. A retained value is useful only if its validity and restoration sequence are understood. Describe what happens after an incomplete transition or unexpected reset. The recovery path should be part of the architecture rather than a collection of special cases added during debug.

Review boundary protection

Isolation prevents a powered-down or otherwise invalid domain from driving inappropriate values into an active domain. Review where isolation is applied, the intended clamp values and the sequence in which it is asserted and released. The correct value depends on the receiving interface and its protocol.

Level shifting, clock handling and reset relationships also require implementation-aware review. A functional model can help explain intent, while structural and physical checks address other parts of the problem. Keep the evidence from these methods distinct so that a passing simulation is not mistaken for proof of every implementation property.

Exercise software and traffic interactions

Test transitions while interrupts are pending, queues contain work and interfaces are stalled, if those situations are legal in the product. Confirm that a driver receives an understandable completion or error outcome. If software must quiesce the device first, verify that the handshake covers all relevant activity.

Review timeout and retry behaviour. A transition request that is never acknowledged should lead to a defined response, not an indefinite wait that is invisible to the application. The test plan should include recovery from failed entry and failed exit, with observations that distinguish a hardware issue from an incorrect software sequence.

Measure power under stated workloads

Power estimates and measurements depend on activity, operating conditions and the stage of the design. Define representative workloads and the observation window. Separate leakage, active operation and transition overhead where the method supports that distinction.

A low steady-state power number may not improve the product if transitions are frequent or wake-up latency prevents useful work. Compare alternatives using the product’s duty cycle and response requirements. Label estimates and physical measurements accurately, and preserve the configuration that produced each result.

A transition-review worksheet

Choose one legal power-down sequence and list each observable event: request, quiesce, isolation, state preservation, clock handling and supply transition, as applicable to the architecture. Record the owner and prerequisite for every event. Review the reverse sequence separately instead of assuming that reversing the arrows produces a correct wake-up flow.

Now introduce an interrupt or an incoming transaction at a boundary in the sequence. Decide whether it is completed, deferred, rejected or used to cancel the transition. Check that the decision is visible to the requesting component. A local state machine can reach its intended state while leaving another part of the system waiting indefinitely.

Finally, discuss interruption by reset and the state from which recovery begins. Identify what information survives and what must be reconstructed. Turn the agreed examples into verification scenarios and firmware integration tests. Keep the worksheet linked to the power-intent and software revisions so that a change in sequencing triggers the appropriate review. The exercise provides a concrete way to connect architecture, implementation and application behaviour without treating a power-state diagram as sufficient evidence by itself.

Make release assumptions visible

The handoff should include the state model, sequencing rules, firmware responsibilities, power-intent collateral and the relevant verification results. List unsupported transitions and any required delays or prerequisites. Update the documentation when the implementation changes the assumptions.

This creates a shared reference for architecture, verification, firmware and physical implementation. It also gives later integrators a way to understand what the block promises. The checklist supports a project-specific review; it is not a claim that an unspecified design is power-verified or ready for production.

Review the effect of configuration changes on the transition model. Enabling an optional peripheral or changing a clock source can introduce activity that the original quiesce sequence did not cover. Treat those changes as reasons to revisit the relevant tests and ownership assumptions, rather than assuming that all low-power evidence transfers unchanged.

What to bring. What to review.

Questions before you begin.