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.

Power architecture
Following the definition of the chip/system architectural specification, the next step in the development process is to refine the power architecture. For example, the architectural specification may specify that a certain block should be implemented in such a way that it is capable of being completely powered down. In the power architecture portion of the process, the team will determine just how often this block is to be shut down, and also any interdependencies among this block and other blocks and modes.

To place this in perspective, before a certain block is powered down, it may be necessary to first power down one or more other blocks in a specific order, and to ensure that each block is completely powered down before a subsequent block is powered down. Similarly, when this portion of the design is restored to its operating condition, it will be necessary to ensure that the various blocks are powered up in a specific order.

Compounding the problem is the fact that different blocks may be powered down in different combinations and in different sequences while the device is in different operating modes. Furthermore, the power architecture has to be capable of handling a reversal of the power-up or power-down processes in mid-sequence. Following some period of inactivity, for example, the system may decide to initiate a power-down sequence. While in the middle of this sequence, however, an external stimulus may be detected (say, an incoming signal on a wireless device) that requires this portion of the design to be functioning. What should happen in this case? Will the system be forced to complete the entire power-down sequence, or can it abort the sequence and immediately commence to power blocks up again (in the defined order, of course).

The power architecture phase relies on system-level switching activity and profiling data captured during the chip/system architecture process. In addition to powering down blocks and/or placing them in sleep modes, other aspects of the power architecture include the following:

• Multi-supply multi-voltage (MSMV)
• Power shut-off (PSO)
• Substrate biasing
• Dynamic voltage and frequency scaling (DVFS)
• Clock gating

Applying any of these techniques requires a significant amount of effort and involves a certain amount of risk. In the case of MSMV implementations, for example, it will be necessary to consider low-power cells, level-shifter cells, and so forth. Similarly, in the case of PSO, designers have to choose between "simple power shut-off" where everything in the block is powered down, and "state retention power shut-off," in which the bulk of the logic is powered down but key register elements remain "alive." This latter technique can significantly reduce the subsequent boot-up time, but state-retention registers consume power and also have an impact on silicon real-estate utilization.

Substrate biasing is typically applied only to portions of the design. The idea here is that a functional block typically doesn't need to run at top speed for the majority of the time, in which case substrate biasing can be applied, which causes that block to run at a slower speed but with significantly reduced leakage power.

DVFS is used to optimize the tradeoff between frequency and power by varying the voltage or frequency in relatively large discrete "chunks." For example, the nominal frequency may be doubled to satisfy short bursts of high-performance requirements or halved during times of relatively low activity. Similarly, a nominal voltage of 1.0V may be boosted to 1.2V to improve the performance, or reduced to 0.8V to reduce the power dissipation. Each of these scenarios has to be tested in the context of surrounding blocks, which may themselves switch from one mode to another.

Even the well-understood technique of clock gating – which was originally planned in the chip/system architectural exploration phase and now has to be followed up in the power architecture phase – can pose a complex problem. For example, should clock gating be performed only at the bottom of the tree (the leaf nodes), at the top of the tree, in the middle of the branches, or as a mixture of all of these cases? There are tools to make this more efficient by moving the clock-gating structures upstream and/or downstream and performing splitting and cloning, but all of this adds substantially to the task of physically implementing the clock tree and also to the verification problem.

As market requirements continue to impose stringent performance, area, and power requirements, the majority of designs will require a combination of power management techniques. However, things that would probably work without any problems if only a single technique were used become much more complicated when multiple techniques are used concurrently.

The end result is that the power architecture phase requires access to a variety of exploration and "what-if" analysis tools, and all of these tools need to be able to account for effects such as MSMV and substrate biasing. For example, timing analysis and power estimation engines should be able to accommodate "what-if" scenarios such as "what happens if the voltage on Block A is lowered to 0.8V at the same time as substrate biasing is applied to Block B?"

As the power architecture team evaluates different scenarios and makes decisions – such as which blocks will be running at which voltage and/or frequency and with what biasing (if any) in which operating modes – these decisions need to be captured in the Common Power Format (CPF) file to be used in the downstream design, implementation, and verification portions of the flow. Furthermore, the CPF facilitates performing "what-if" analysis, because it allows engineers to easily and quickly make a change in one place that will subsequently "ripple" throughout all of the design, analysis, implementation, and verification tools.

Power-aware design
In this context, "design" refers to the portion of the flow where – taking the results from the power architecture phase – the design engineers capture the RTL descriptions for the various blocks forming the design. The designers associated with each block are responsible for ensuring that block will meet its functional, timing, and power requirements while using the minimum silicon real estate.

This means the designers need to know the target voltage level(s) for their block so that they can understand the various timing and power challenges. If the system as a whole employs multiple voltage levels, level shifters must be inserted between domains, and the designers must know if these are present in their timing paths because these cells could result in significant cell delays.

Designers need the ability to quickly and easily explore and evaluate alternative micro-architectures, such as unraveling loops, resource sharing, varying the number of pipeline stages (more stages result in higher performance at the expense of increased power consumption, area utilization, and latency), using hardware accelerator(s) versus microcode, and so forth. With regard to power-centric design, this involves the ability to capture toggle values to gain an accurate estimation of power – first with the RTL representations and later at the gate level.

Designers also need to know if their block will be a power-shutdown block, as this will affect design and implementation. For example, how quickly is it required for the block to enter into – and recover from – the shutdown mode? Using state retention registers offers the fastest recovery, but these registers require more area than do their non-retention counterparts. If state retention is to be used, will all of the registers in the block use them, or will it be used only for a subset of the registers? It is important for designers to be able to perform quick "what-if" analyses to determine the optimum number of state retention registers. Also, using state retention registers will require a special state retention power grid, which is likely to add some area overhead to their block.

Even for a common technique, such as clock gating, there are multiple alternative scenarios (e.g., some design teams code the clock-gating structures directly into their RTL, while others implement clock gating using synthesis technology during the implementation phase, and some teams use a mixture of both these techniques).

Formal analysis can play a very important role in verifying the power-centric functional aspects of the design. As each block is coded, power-centric assertions can be associated with that block; for example: "When this block is instructed to enter its power shutdown mode, the 'isolation' signal should go active first followed – after some minimum delay – by the power shutdown signal going active. Also, assertions will be associated with both clusters of blocks and at the full-chip level to ensure that blocks power down and power up in specific sequences depending on the current operating mode." Formal analysis is of particular interest when identifying potential livelock/deadlock conditions that result from blocks being powered up and/or powered down, thereby causing states to appear between blocks that would not appear during the normal operation of the device. This type of issue cannot be exhaustively checked by any means other than formal verification.

One important consideration is that every power-centric aspect of a design would traditionally have been hard-coded into the RTL. This can cause problems, because the same block can be used in multiple implementations with different power intent. For example, a block may be used at a certain voltage level and/or have a certain power shut-down profile in one instantiation in the design, and a different power profile in another instantiation in the same design. And, of course, blocks of RTL are often re-used in multiple chips whose power requirements may be vastly different.

Conventionally, implementation-specific intent of this type has been captured using constraints and tool scripts, or by being hand-coded directly into the RTL implementation. However, this approach is prone to error, especially as things may change during the design process. This is a major advantage of the Common Power Format (CPF), which captures design intent that can be shared across the design, implementation, and verification tools throughout the flow.
Power-Aware Implementation
The implementation phase is where all of the hard work performed during the chip/system architecture, power architecture, and design phases comes to fruition with the aid of power-aware engines for logic synthesis, clock gating, placement, clock-tree synthesis, routing, and so forth. In addition, during the implementation phase, the logical and physical structures needed for the various power techniques are created. These include power grid synthesis, power plane implementation, and insertion of level shifters, switch cells, isolation cells, and state-retention cells.

Top-down multi-dimensional optimization: One key requirement for low-power design is the ability of logic and physical synthesis engines to concurrently optimize for timing, area, and power tradeoffs. For example, by replacing low-Vt cells with high-Vt cells, optimization engines can reduce leakage power at the expense of performance. However, power cannot be an afterthought to the optimization process where first the timing targets are achieved and later on cell swapping is done to reduce power. This means that right from the logic synthesis stage and all the way to routing, the optimization engines need to create structures that can meet performance targets while minimizing the use of low-Vt cells.

Similarly, in the case of MSMV designs, it is important that the optimization engines understand power domains top down so that they have full visibility to optimize across entire timing paths. The top-down optimization approach for MSMV designs leads to superior timing, area, and power tradeoffs. Furthermore, the ability to explore power-timing tradeoffs at the top level eliminates the need for multiple iterations that are common in bottom-up partitioning.

Clock-gating challenges: Though clock gating has been used for some time as an effective technique to reduce dynamic power, today's stringent power specs demand more sophisticated gating techniques. The most sophisticated form of clock gating currently available is multi-stage gating, in which a common enable is split into multiple sub-enables that are active at different times and/or under different operating modes. And, of course, the process is further complicated when it comes to clock trees that pass through different power domains, especially when one or more of those power domains are candidates for power shut-off.

Power-aware design planning: Power domains must be shaped and placed; power pads and switches must be placed and optimized; and power routing must be planned. Silicon virtual prototyping helps the partitioning process by minimizing the wirelength of the high switching probability wires, which lowers the dynamic power. This requires tools that can understand which wires contribute to the most capacitance and are able to find ways to minimize the interconnect capacitance through optimal partitioning and floorplanning.

Physical implementation of low-power structures: Multiple power domains in MSMV and PSO techniques require the insertion, placement, and connection of specialized power structures, such as level shifters, power pads, switch cells, isolation cells, and state-retention cells.

In particular, PSO requires a special set of implementation considerations. For example, designers need to make a tradeoff between using fine- and coarse-grained power gating. Fine-grained gating includes a power-gating transistor in every standard cell, which has a large area penalty but eases implementation. Coarse-grained gating reduces the area penalty by using a single gate to cut off power to an entire block, but requires sophisticated analysis to determine the gating current of the switched-off block. In addition, turning on several blocks at once could lead to the problems of ground bounce and latch-up current due to IR drop. This requires dynamic gate power analysis to better understand the turn-on characteristics of a block and minimize the rush current or ground bounce effects.

Signal integrity considerations: With increasing clock frequency and lowering of supply voltages, there is increasing sensitivity to signal integrity (SI) effects such as crosstalk-induced delay changes and functional failures. With the use of advanced power management techniques, SI analysis becomes even more complicated. For example, in a PSO design, a spurious signal caused by an SI aggressor could shut down an entire module. Similarly, the use of multi-Vt cells can lead to the creation of super-aggressors with low-Vt while weakening their high-Vt victims. Overall, multi-Vt, MSV, and PSO techniques require implementation and analysis tools to be power aware so they can account for SI effects.

Low-power formal verification: Low-power designs could fail due to a number of structural errors, such as missing level-shifters/isolation logic; redundant level-shifters/isolation cells; bad power-switch connections; and bad power and ground connections. Some possible functional errors include bad state-retention sleep/wake sequences and bad logic for power gating and isolation. Thus, it is important that designers use robust formal verification techniques to identify and rectify these structural and functional errors. A major consideration is to ensure that each power-centric implementation technique is executed in a holistic manner, taking account of all of the other techniques being employed on a particular design. Each technique has to be supportive of the other techniques, and any power savings achieved from one technique needs to be maintained and preserved by the other techniques. For example, one of the most basic savings in power is to not use the biggest drivers. A slight reduction in margins will result in a smaller design occupying less area and consuming less power. But if the design environment does not support power-aware timing closure, it may negate any power savings achieved earlier in the process by adding too many cells for delay fixing.

Similarly, the practice of adding extra timing margin early in the process to ensure easy timing closure will negatively impact power consumption. Thus, once again, it is important that all optimization techniques simultaneously consider all of the implementation objectives to achieve the best possible solution.

Using the Common Power Format (CPF) is the key to effective power-aware implementation. The CPF captures the intent of chip architects and designers and enables automatic optimization during the implementation. And again, having this specification separate from RTL enables re-use of a block in different power profiles.

By employing automation tools that understand the designer's power intent through CPF for optimization, design planning, and layout steps, design teams can achieve superior timing and power tradeoff while improving the productivity and cycle time during the implementation phase.

Power-aware verification
Verifying today's extremely large and complex designs is both expensive and resource intensive. In fact, verification can account for as much as 70 percent of a digital IC's development time and resources.

Verification commences with the planning process. Once the top-level verification goals have been established, individual items to be tested are detailed, the way in which each item will be verified is defined, and the required coverage metrics for each item are specified.

In a modern design and verification environment, the human and machine-readable verification plan is complemented by a sophisticated and intelligent verification management application. This takes the executable verification plan and automatically deploys the appropriate tools required to perform the various facets of the verification. These tools include formal verification engines, software simulators, hardware accelerators, and emulators. The verification management application automatically balances the jobs for each verification session to make optimal use of all available resources.

Two key attributes of the verification management application are to bring visibility and predictability into the verification process. For example, the executable verification plan can specifically define certain verification metrics (such as coverage goals) that must be achieved by certain dates/milestones. These milestones are used to pace the team and to ensure that commitments to other groups and external customers are met.

The verification management application automatically accesses the log files from the various verification engines, parses them, and analyzes the results. It compares the required metrics with the actual results and reacts accordingly by re-deploying resources to address any problem areas. Furthermore, users (managers and engineers) can employ the verification management application to generate frequent, accurate, and concise reports in real time. At the push of a button, a manager can immediately see which portions of the design have been verified and which have not. If things are starting to slip, the team can quickly re-deploy effort to focus on problem areas.

In the past, verification plans of this type were based on various coverage metrics (assertion coverage, code coverage, functional coverage, etc.). In the case of a power-aware design and verification environment, the verification process also needs to take account of any power-centric aspects of the design. For example, before a certain block is powered down, it may be necessary to first power down one or more other blocks in a specific order, and to ensure that each block is completely