By expanding to include support for power intent formats, the same IDE used to develop the design and verification code can ensure consistency across all files. The result is faster adoption, easier specification, and a more robust approach to low-power design.
Most, if not all, system-on-chip (SoC) designs today must meet strict requirements for low-power operation. This has led to many techniques to reduce power consumption, with major implications for both the design and verification teams. In the last few years, the concept of a power intent file that captures the key features has gained traction. Writing and maintaining this file is much easier with an integrated development environment (IDE) that supports power intent specification and can correlate it to the RTL for the chip design.
The most obvious reason for the elevated importance of power is that so many ubiquitous consumer devices run on batteries. From smartphones and wearables to tablets and laptops, many devices spend the bulk of their lifetime running on battery power. Although there have been some impressive advances in battery technology, the consumer always wants batteries to last longer. Even for large systems such as servers and network switches, “green” laws and the desire to manage electricity costs may require a lower-power design.
Fortunately, design engineers have come up with a wide range of techniques to reduce power consumption, from circuit-level innovations to system-level software control. Many of the techniques rely on dividing the chip design into power domains, each of which can be controlled independently. It may be possible to turn a power domain off and on entirely, a process that may require saving and restoring of essential state. In other cases, power may be reduced by lowering the voltage or the clock speed of the power domain. The popular dynamic voltage and frequency scaling (DVFS) technique does both.
In all cases, the idea is to minimize power for portions of the chip not currently critical for operation, with the ability to spin back up to full power and performance when needed. Some SoCs contain so much diverse functionality that there is never a time when the entire chip is active. Designers count on this, with the result that the chip would be destroyed by thermal runaway if all blocks were running. Proper specification and management of power domains are critical to prevent such a catastrophe.
As these techniques were invented and deployed, it turned out that significant portions of the low-power design and verification flow could be automated. For example, a tool with knowledge of the power domains could insert into the design isolation cells between blocks turned off and those still active, or level shifters between blocks running at different voltage thresholds. Such tools require some sort of input file defining power domains, power-control signals, and other relevant information.