Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > EDA/IP

Design for power methodology: From architectural plan to signoff

Posted: 30 Apr 2012 ?? ?Print Version ?Bookmark and Share

Keywords:system-on-chip? power integrity? register-transfer-language level?

At the physical design phase, the use of various SoC-level power management techniques such as power-gating has a direct impact on power integrity, and therefore must be analyzed as early in the design flow as possible. Other techniques that can impact the power integrity include voltage islands (i.e., power supply partitioning), dynamic voltage and frequency scaling (DVFS), and body bias (including adaptive body bias).

RTL design, power debug
During this phase of a DFP methodology, power must be treated as an RTL design objective because RTL coding styles and design decisions affect power as well as function, timing, and area. One motivating factor that compels design teams to deploy RTL power analysis is that it is important to know as early as possible if the design is on track to meet its power specification. However and perhaps more significantly, in an RTL to GDSII (layout) flow, design decisions can be made only at the RT level. Once the RTL code is frozen, synthesis and physical design tools automatically implement the design. This implementation is by its very nature restrictive, and has only a marginal impact on the power consumption of the design.

Though it is possible to accurately analyze power consumption at the gate-level, it does not easily map back to the RTL constructs, making it difficult for intelligent design decisions to be made with significant impact on power consumption. So an RTL power analysis and power consumption debug environment is essential for power-efficient SoC design.

During the RTL design phase, it is important to debug the design's power consumption. Power consumption debug is not the same as obtaining the RTL power number. Instead, it means interactively analyzing where and how much power is being consumed; understanding where power is being wasted in the design, and ultimately making RTL design changes to remove wasted power and lower overall power consumption. Power debug can be done at the block, unit (i.e., collection of blocks), or full-chip level. Most power consumption bugs are due to redundant activity in the design, and are more difficult to detect than functional bugs because often times the design can still function correctly while consuming excessive power. An example of a power consumption bug is shown in figure 2.

Figure 2: Example of a power consumption bug.

In figure 2, for a particular mode of operation, Processors 2 through 4 were intended to be shut down (i.e., not performing any operations), while Processor 1 was active. However, RTL power analysis reveals that even though the three processor clocks were turned off, Processors 2 through 4 were still showing significant dynamic power.

An RTL power debug environment would reveal that the data stream coming to these processors was not shut off; causing some internal logic to toggle before arriving at the register, but because the register clock was disabled, register outputs were not toggling and no functional error was detected.

In practice, RTL designers must consider signal and function inter-dependencies and understand the relationship between data and clock signal frequencies to uncover the wasted power in their design. In order to do power consumption debug effectively, it is important to analyze block-to-block and module-to-module interactions. Using the interactive power debug approach, designers can detect wasted power conditions that when corrected, often will result in significant power savings at the expense of a few simple RTL code changes.

RTL power refinement
At this phase of a DFP methodology the focus is on reducing power consumption at the RTL operand, or 'function' level. Because of the fine-grained level of detail needed in this phase, the task is very amenable to automation. However, it is important to point out that RTL power reduction is not optimization. Power reduction techniques available at the RT level of abstraction do not have detailed knowledge of timing, and therefore cannot optimize the design to achieve a specific target. Instead, such techniques are best used in a guided fashion; automated but not automatic. In an automated approach, the power reduction tool would present an opportunity to reduce power, but the designer would make the ultimate decision, if and how an RTL change should be implemented.

?First Page?Previous Page 1???2???3???4?Next Page?Last Page

Article Comments - Design for power methodology: From a...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top