Design Article
Comment
patrickg42
Dr DSP
Power is one more area for a possible design iteration loop that will bust ...
Design for power methodology
William Ruby
4/20/2012 10:22 AM EDT
Abstract
Power is a daunting challenge for modern system-on-chip (SoC) designs, from both the power consumption and power integrity perspectives. Achieving low-power, from mobile and wireless designs to consumer devices to high-performance networking and computing applications that face power supply and cooling limitations, is now critical to design success. At the same time, rising complexity and chip-level power management techniques make power integrity analysis from chip-to-package-to-system essential. Designing for low-power and power integrity is not automatic – there is no “low-power” button. This article describes a holistic design for power methodology that spans from architectural decisions through front-end design to physical implementation and sign-off.
Power is a key challenge in modern IC designs for various applications. The power challenge is comprised of two fundamental aspects: power consumption and power integrity. From mobile and wireless designs where extending battery life is essential to product competitiveness, to consumer devices with package cost constraints, to high-performance networking and computing applications facing power supply and cooling limitations, reducing power consumption is now mission-critical. At the same time, rising design complexity and the use of chip-level power management techniques such as power-gating is forcing design teams to ensure power integrity from chip-to-package-to-system. A modern system-on-chip (SoC) design flow consists of many steps including various levels of abstraction, from system-level and architectural design to detailed physical implementation. Power considerations are important in every step of the design flow, however, only at the high levels of abstraction – at the architectural and hardware design register-transfer-language level (RTL) – are where a significant impact on overall power consumption can be achieved. In order to manage both power consumption and power integrity effectively, design teams must adopt a holistic design-for-power (DFP) methodology, spanning architectural decisions through front-end design to physical implementation and sign-off. A DFP methodology is illustrated in Figure 1.

Architectural and hardware/software trade-offs
Architectural trade-offs must take into account performance, cost (or area for SoC designs), and power consumption. In addition to this multi-dimensional design requirement, SoC and system architects must also consider the implications of deploying a particular design function in hardware versus software. Traditionally, these trade-offs have been performed using spreadsheets and other ad-hoc approaches. While these methods do have a certain amount of utility, a more structured and deterministic solution is needed in this area. As designs grow more complex, a significant portion of the design may be reused from previous generations, so a modeling approach where pre-existing blocks of functional units can be characterized for their power, performance, and area parameters is a key enabler for multi-dimensional trade-off analysis.
Evaluation and application of SoC-level power management techniques
There are several SoC-level power management techniques currently being used and gaining acceptance. One technique is power-gating, or power shut-off. Power-gating means that the power supplies to entire blocks or functional units on the chip can be turned off, resulting in near-zero dynamic and static power consumption. Although power-gating is conceptually simple to understand, design and implementation is quite complex. From the front-end perspective, power supply control signals and their proper sequence need to be designed. During physical design, power supply switches must be carefully placed. Retention, isolation, and level-shifter cells must be used to ensure proper functional correctness of the design, as well as design reliability. In addition to design implementation concerns, it is also important to determine how many power domains are needed, and how many blocks in the design will be power-gated to achieve power consumption goals. While initial analysis may be done with improvised methods similar to those used for architectural trade-offs, if the design description is available using a hardware description language (HDL) at the RT level of abstraction, then power analysis can be performed for various what-if partitioning scenarios. In addition, once the design power intent is finalized, a common power format (CPF) or unified power format (UPF) file can be created for the downstream design flow implementation.
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 and RTL 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.

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.
Power is a daunting challenge for modern system-on-chip (SoC) designs, from both the power consumption and power integrity perspectives. Achieving low-power, from mobile and wireless designs to consumer devices to high-performance networking and computing applications that face power supply and cooling limitations, is now critical to design success. At the same time, rising complexity and chip-level power management techniques make power integrity analysis from chip-to-package-to-system essential. Designing for low-power and power integrity is not automatic – there is no “low-power” button. This article describes a holistic design for power methodology that spans from architectural decisions through front-end design to physical implementation and sign-off.
Power is a key challenge in modern IC designs for various applications. The power challenge is comprised of two fundamental aspects: power consumption and power integrity. From mobile and wireless designs where extending battery life is essential to product competitiveness, to consumer devices with package cost constraints, to high-performance networking and computing applications facing power supply and cooling limitations, reducing power consumption is now mission-critical. At the same time, rising design complexity and the use of chip-level power management techniques such as power-gating is forcing design teams to ensure power integrity from chip-to-package-to-system. A modern system-on-chip (SoC) design flow consists of many steps including various levels of abstraction, from system-level and architectural design to detailed physical implementation. Power considerations are important in every step of the design flow, however, only at the high levels of abstraction – at the architectural and hardware design register-transfer-language level (RTL) – are where a significant impact on overall power consumption can be achieved. In order to manage both power consumption and power integrity effectively, design teams must adopt a holistic design-for-power (DFP) methodology, spanning architectural decisions through front-end design to physical implementation and sign-off. A DFP methodology is illustrated in Figure 1.

Figure 1: Design-for-Power Methodology
Architectural and hardware/software trade-offs
Architectural trade-offs must take into account performance, cost (or area for SoC designs), and power consumption. In addition to this multi-dimensional design requirement, SoC and system architects must also consider the implications of deploying a particular design function in hardware versus software. Traditionally, these trade-offs have been performed using spreadsheets and other ad-hoc approaches. While these methods do have a certain amount of utility, a more structured and deterministic solution is needed in this area. As designs grow more complex, a significant portion of the design may be reused from previous generations, so a modeling approach where pre-existing blocks of functional units can be characterized for their power, performance, and area parameters is a key enabler for multi-dimensional trade-off analysis.
Evaluation and application of SoC-level power management techniques
There are several SoC-level power management techniques currently being used and gaining acceptance. One technique is power-gating, or power shut-off. Power-gating means that the power supplies to entire blocks or functional units on the chip can be turned off, resulting in near-zero dynamic and static power consumption. Although power-gating is conceptually simple to understand, design and implementation is quite complex. From the front-end perspective, power supply control signals and their proper sequence need to be designed. During physical design, power supply switches must be carefully placed. Retention, isolation, and level-shifter cells must be used to ensure proper functional correctness of the design, as well as design reliability. In addition to design implementation concerns, it is also important to determine how many power domains are needed, and how many blocks in the design will be power-gated to achieve power consumption goals. While initial analysis may be done with improvised methods similar to those used for architectural trade-offs, if the design description is available using a hardware description language (HDL) at the RT level of abstraction, then power analysis can be performed for various what-if partitioning scenarios. In addition, once the design power intent is finalized, a common power format (CPF) or unified power format (UPF) file can be created for the downstream design flow implementation.
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 and RTL 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.
Navigate to related information


Dr DSP
4/20/2012 5:33 PM EDT
Power is one more area for a possible design iteration loop that will bust schedules. Starting at the top and working down sees like a good technique, but wouldn't it be better to automate as much as possible. Remember when you had to do timing optimization manually? Let's hope soon power can use a much more automated approach.
Sign in to Reply
patrickg42
4/27/2012 3:22 AM EDT
The "Architectural and hardware/software trade-offs" paragraph states:
"Traditionally, these trade-offs have been performed using spreadsheets and other ad-hoc approaches. While these methods do have a certain amount of utility, a more structured and deterministic solution is needed in this area."
The solution exists and is already used by major mobile wireless players: It's ACEPlorer from Docea Power.
Sign in to Reply