Low power design is here to stay

Governmental regulations have been a more recent driver. Driven by the popularity of green initiatives, specifications have been standardized for power consumption for almost all household electronic gadgets. The regulations impose limits on how much energy a device can consume when it is idle, which has the far reaching effect of extending low power design to even plugged-in-the wall devices. What is new is that almost all electronic designs are becoming power managed designs. Verification of low power designs, which until recently was a challenge for just a handful of all designs, is fast becoming every designer's problem.

Verification impact
Designers employ a wide range of design techniques to manage power. All the techniques focus on one principle —turn off logic that is not required for the functioning of the chip at a given point in time. Additional design elements and control circuitry are deployed to apply the "off when not needed" principle. In its simplest form, a design is partitioned into a number of power domains that can be independently turned on or off. Any such partitioning requires that the sections of the chip driven by signals in a powered off domain be protected from corrupting signals in an operating domain. More complex techniques rely on changing the voltage and/or the frequency of operation depending on the task that has to be executed by the logic within a power domain. The idea is to supply the minimum voltage necessary to power an operational domain because power consumption is highly impacted by voltage. The additional design complexity immediately correlates to new bugs.

Detection of these bugs would have been just a linear extension of the effort involved for non low power designs but for the fact that with each partition of a design into different power domains, the number of combinations that must be considered for verification increases exponentially. First, you have a design that can operate in different functional modes. Then you have each functional mode associated with a power state representing its operating voltage. Finally, you have the design making transitions from one operating mode to another, which may involve one or more transitions of power states in a specific order. Combine all these and you have a perfect verification storm because now you must verify that the design correctly operates in each functional mode in the corresponding power state as well as makes the intended transitions in the proper sequence.

Voltage awareness- Key to low power verification
Designs in the non-low power era were voltage agnostic. Even the high level description (HDL) languages described a design state as on (1) or off (0). This simplistic view will not suffice any more. Low power design requires understanding the value of voltages. A design in standby (idle mode) is not set to 0 volt. It is some intermediate value between 0 volts and the operating voltage. Even the operating voltage changes when techniques such as dynamic voltage scaling are used. Designs are increasingly using multiple supply voltages, whose values are different. Without knowledge of the actual voltage values and the power domains they control, verification results are meaningless and error-ridden. Voltage value-aware verification is a must to avoid nasty surprises in silicon.

Automated assertions —Tackling verification complexity
Every new process technology doubles the number of transistors in a given silicon area. If this sounds familiar, it is because this is Moore's law. Each low power design technique requires monitoring of well-known and understood sequences of events. For example, power gated designs require that the outputs of a domain be isolated before shutting off the power domain. During simulation, a late isolation enabled signal can be automatically monitored at every output of a powered down domain. Verification tools for low power need to incorporate the smarts to profile a design, understand what power management techniques are applied to it, and automatically generate and track the appropriate assertions for such sequences and flag them as errors should they be triggered. In the absence of such automation, low power designers and verification teams are stuck with manually generating thousands of assertions hoping to cover every possible sequence at all appropriate points in the design. Being human, it is conceivable that they may miss a few. All it takes is one missed assertion and a little bad luck for the design to fail exactly at the location where an assertion was missed. The moral of this story —you need assertions to manage the design complexity, and you can't leave this to chance. Automation is the answer.