In recent years, power consumption has moved to the forefront of digital integrated circuit (IC) development concerns. The combination of higher clock speeds, greater functional integration, and smaller process geometries has contributed to significant growth in power density. Furthermore, with every new process generation, leakage power consumption increases at an exponential rate.
It is common to think of low-power designs only in the context of handheld, battery-powered devices such as personal digital assistants (PDAs) and cell phones. And it is certainly fair to say that this class of device is at the top of low-power development concerns. In reality, however, power consumption (and corresponding heat generation) is also of significant interest to semiconductor segments with fixed installations, such as networking, set-top boxes, and computing devices. For example, the InformationWeek "Power Surge" article on 27 February 2006 reported that data center electricity costs are now in the range of US$3.3 billion annually, and it can cost more to cool a data center than it does to lease the floor space in which to house it. Additionally, consumers increasingly demand quieter devices for their living rooms and desktops, and low-power designs help manufacturers eliminate noisy cooling fans from set-top boxes and other products.
Over recent years, a wide variety of techniques have been developed to address the various aspects of the power problem and to meet evermore-aggressive power specifications. These include (but are not limited to) the use of clock gating, multi-switching threshold (multi-Vt) transistors, multi-supply multi-voltage (MSMV), substrate biasing, dynamic voltage and frequency scaling (DVFS), and power shut-off (PSO). The power, timing, and area tradeoffs among the various power management techniques are illustrated in Fig 1 below.
1. Power, timing, and area tradeoffs associated with
the various power management techniques.
(Click this image to view a larger, more detailed version)
As expected, the use of more advanced approaches – such as MSMV and PSO – reduces power consumption, but at the same time increase the complexity associated with design, verification, and implementation methodologies. Although using a single technique in isolation could be relatively simple, often a combination of these techniques must be used to meet the required timing and power targets. Using multiple techniques concurrently could result in an extremely complex design flow. A key requirement is consistency throughout the flow such that the use of one technique preserves any gains from other techniques. This also requires a good understanding of the various low-power techniques and their respective tradeoffs, as highlighted in Fig 1.
Furthermore, "low power" isn't just something that is "bolted" on at the end of the development process. To meet aggressive design schedules, it is no longer sufficient to consider power only in the implementation phase of the design. The size and complexity of today's ICs makes it imperative to consider power throughout the design process, from the chip/system architectural phase; through the implementation architecture phase; through design (including micro-architecture decisions); and all the way to implementation with power-aware synthesis, placement, and routing. Similarly, to prevent functional issues from surfacing in the final silicon, power-aware verification must be performed throughout the development process.
A key enabler of a modern power-aware design flow is the ability to capture and preserve the intent of the chip architects and designers throughout the design flow. This requires a common specification format that can be used and shared across the entire design chain, from architectural specification ("this block has three power modes") to verification ("will the chip recover if these blocks are put to sleep in this order?").
The current state-of-the-art in such a specification is the Common Power Format (CPF), which is managed under the auspices of the Silicon Integration Initiative (Si2) consortium's Low Power Coalition. CPF is a new design language that addresses limitations in the design automation tool flow. It provides a mechanism to capture architects' and designers' intent for power management and it enables the automation of advanced low-power design techniques. CPF allows all design, implementation, verification, and technology-related power objectives to be captured in a single file and then applies that data across the design flow, providing a consistent reference point for design development and production.
There are three major benefits of using CPF to drive the design, verification, and implementation steps of the development flow. First, it helps designers achieve the required chip specs by driving the implementation tools to achieve superior tradeoff among timing, power, and area. Second, by integrating and automating the design flow, it increases designer productivity and improves the cycle time. Third, by eliminating the need for manual intervention and replacing ad hoc verification methodologies, it reduces the risk of silicon failure due to inadequate functional or structural verification.
This article introduces the various aspects of power-aware design during chip/system architectural specification, power architecture definition, design, physical implementation, and verification.
Chip/system architectural specification
Power-aware design starts with the architectural specification of the chip/system. This is where the most significant tradeoffs can be made. To define the most appropriate architecture for a design, it is necessary to understand the algorithms being used and the "space" of the application. To address this, it is now common practice to model the system at a high level of abstraction and to use this model to determine bandwidths (how much data needs to be moved around) and how much processing power is required to achieve these bandwidths.
One critical task is to partition the system into its hardware and software components. Hardware implementations are fast and consume relatively little power, but they are "frozen in silicon" and cannot be easily modified to address changes in the standards or the protocols. By comparison, software implementations are slow and consume a relatively large amount of power, but they are extremely versatile and can be modified long after the chip has gone into production.
Another area that is receiving increasing attention is the creation of the software compiler so as to generate power-tuned machine code (e.g., generating code that occupies memory in a non-sequential manner such that only a single address bit is toggled when accessing "adjacent" words in the machine code).
Regarding the hardware portions of the design, "block" partitioning should be defined in the context of the types and quantities of data that are flowing through the system. The goals here should be to minimize both inter-block communication and the frequency at which the majority of signals will be switching.
Also at the architectural stage, evaluations should be made as to which blocks are not performance-critical, so that they could potentially be run at a lower voltage and/or frequency to conserve power. In some designs, certain blocks may be suitable candidates to utilize voltage-frequency scaling techniques, in which case it is necessary to determine (and document) how the performance-voltage-frequency feedback mechanism will function. Similarly, in some designs, certain blocks may be suitable candidates for "sleep mode" or completely shut down to conserve power when they are inactive. This means that the architects will define different "modes" and then specify which blocks will be on or off (or asleep) in each mode, or even blocks that have different power/performance requirements for the different modes.
Another key consideration is IP selection, which relates to both internal and third-party IP. In the case of one real-world design that exceeded its power budget, an unexpected amount of leakage was tracked down to the memory IP obtained from a third party. Thus, in addition to its core functionality, an IP block should be evaluated in the context of the device architecture's low-power requirements. Is it required for this block to be capable of being placed in sleep mode and/or completely shut down, for example? And if so, does this IP block support the required functionality?
Clock gating also must be planned during the architectural phase. This technique can significantly reduce the design's dynamic power consumption since the clock trees can account for one-third to one-half of a chip's dynamic power consumption.
Another consideration for today's multi-million-gate designs is the interconnect mechanism used to link the large numbers of components. For instance, conventional synchronous bus architectures constantly burn power, even if they aren't actually moving any data around. One solution is to move to a globally asynchronous locally synchronous (GALS) architecture. In this case, data flows as fast as possible through the self-timed (asynchronous) interconnect network because there is no waiting for clock edges, and the power consumed by the buses is dictated by their traffic loads. Furthermore, the clocks associated with the synchronous blocks can be stopped (or gated) when those blocks are not being used.
The problem is that implementing any low-power technique involves time, engineering resources, and risk, and all of this is extremely design dependent. What will be the return of using each technique? A particular technique may convey tremendous power-reduction benefits with one design and negligible payback with another design, while adding the same amount of risk to both. Furthermore, one technique may impact the effects of another technique unless both approaches are considered "holistically." Thus, it is extremely important to have a good understanding of the various low-power techniques and their respective tradeoffs. Also, it is necessary to have a good understanding of any impacts each power-reduction technique will have on other chip goals such as timing and area.
These considerations are extremely complex and require the design team to adopt advanced low-power techniques without compromising their productivity or increasing the risk associated with the project. Thus, a key requirement is the ability to capture any power-related architectural decisions in a form that can be accessed and used throughout the remainder of the flow. This requires the use of a common specification format – such as CPF – that can be used and shared across the entire design chain, from architectural specification ("this block has three different power modes") to verification ("will the chip recover if these blocks are put to sleep in this order?").
Keeping the power profiles of the various blocks in the CPF and separate from the RTL is a key consideration when re-using blocks (in the form of RTL code) in different applications – or even different parts of the same design – where power requirements may differ.
