Is Low Power Coverage Achievable?

Back in 2005, yes, before the invention of the iPhone, I made a slide to educate users on what to cover in Low Power Verification. Using a simple 3 island test case, I illustrated that verification had to be done in 4 states of operation, with 8 transitions and 16 sequences to be verified. This is after pruning the theoretically possible set of 8 states for on/off voltage islands.

More than a decade later, we have made a lot of progress with the development and adoption of the IEEE 1801 standard (UPF) for expressing low power design intent. An extensive verification methodology has been developed, and VMM/UVM integration of low power verification is common place.

Yet, design and verification teams are struggling to keep up with two vectors – the ever increasing number of IP blocks and subsystems in modern SoCs and the growing use of software for power management.

On the face of it, software-driven power management makes life easier. Bugs in power management can be fixed with relative ease in software by changing the driver. For example, one of the cellular phone SoC designs was overheating while doing nothing more than a phone call. It was discovered that a lot of the unused blocks were not shut down, hence the overheating from the resulting leakage power consumption. A simple driver fix solved the problem as opposed to what would have otherwise taken a costly respin.

However, the overheating issue was discovered in the field! It takes a tremendous amount of effort to validate software and hardware together – especially since mobile operating systems like Android and iOS have many layers of abstraction connecting end applications to low-level routines. Often, this task does not get done before tapeout and barely enough verification/validation is done while qualifying silicon. In the absence of appropriate coverage metrics and test plans, the design is likely to see failures on silicon and/or the field.

The number of islands resulting from hundreds of IP blocks/sub-systems is a big part of this problem too, regardless of whether users have hardware- or software-based power management. The number of islands is in the hundreds, hence the exponential growth in states and transitions. This leads users to specify bare minimum power state tables (PSTs)– just enough to cover the isolation/level shifting requirements. The resulting table is useful for implementation, but does not have much semantic importance for functional verification. For example, if all states in a sequence executed by software are not in the PST, simulating the design through that sequence results in false warnings of illegal states.

This seemingly insurmountable problem has an answer in a mathematical formulation – one that governs the temporal activation/de-activation of hardware resources. This is often arbitrarily expressed as “more always on”, “relatively always on”, etc. in some settings. However, mathematically, voltage islands can be ordered temporally, rather need to be ordered temporally. These relationships can be expressed as a set of temporal inequalities and equivalences.

Island ordering, often called architectural checks, is used today to ensure design structure and the flow of essential control signals between voltage islands. However, the primary intention of island ordering is to establish temporal relationships. Island ordering can greatly help designers prune massive PST tables with hundreds of columns (rails) and exponentially large rows. Island ordering is immediately extensible to transition and sequence checks in dynamic verification.

It is possible to integrate such a mathematical basis into testbench environments – both to generate the stimulus for power management as well as to monitor design response. Assertions on correct/incorrect behavior can also be derived. More importantly, temporal ordering of islands provides a much-needed handle on the coverage question as opposed to simply exercising the on/off functionality of islands. We can now target meaningful states and sequences at a higher level of abstraction, without getting bogged down by thousands of PST entries.

This concept will prove particularly useful for emulation, which runs real software. Specifying mathematical relationships instead of thousands of states (which are still incomplete) greatly speeds up the analysis of whether the design stayed in legal states all along. We can do this in the context of real applications which, in turn, lets the user focus on the real task at hand – power reduction and optimization.

So, we may finally have a handle on low power coverage after all.