Special Technology Report
Automating low-power design – a progress report
By Richard Goering et al.
09/03/08
A great deal of attention has been paid to low-power IC design, and for good reason – power consumption has become a critical, if not the most critical, issue in system-on-chip (SoC) design. While progress has been made, designers note that much more remains to be done to automate the low-power design and verification flow, especially at higher levels of abstraction.
This report identifies the bottlenecks that designers are finding in the low-power design flow, including the lack of automation at the electronic system level (ESL), and talks about some of their successes. Drawing primarily upon user experiences, it discusses the following topics:
• ESL to GDSII challenges
• Planning and implementation of power management techniques
• Architectural issues, including memories and embedded software
• ESL low-power flow – capabilities and limitations
• RTL through physical design
• Challenges of low-power verification and test
In the RTL-to-GDSII implementation flow, things look better – many IC designs have successfully incorporated power management techniques such as clock gating, power gating, multi-Vdd (multiple supply voltages), dynamic frequency and voltage scaling, and body bias. The implementation of these techniques is not fully automated, and evaluating potential tradeoffs is not easy, but there are some power analysis and optimization tools that can help.
EDA vendors, meanwhile, have created two formats – Common Power Format (CPF) and Unified Power Format (UPF) – that allow users to express power intent in a consistent way throughout the RTL-to-GDSII flow. Both are being successfully deployed, and they're easing low-power design and verification challenges, but designers are caught in the middle of a standards war between the two competing formats.
If we're talking about RTL-to-GDSII digital hardware logic design, low-power design is doing fairly well. But beyond that realm, several huge gaps remain. Embedded software and operating systems can have a huge power impact, but little help is available to evaluate it. Memory is a major consumer of dynamic and leakage power, but is easily overlooked. Analog/mixed-signal blocks need to be power-aware, but tools and methodologies are lacking. And power management techniques, especially those that involve multiple power domains, profoundly impact and complicate functional verification.
"If you don't factor in power throughout the whole development cycle, it is just not going to be optimized," said Ron Tessitore, vice president of advanced application platforms at Qualcomm. "If you don't architect it properly, you are not going to be able to achieve the power target. Technology selection is really important, and so is how you develop the software and write the algorithms. Finally, there's the optimization cycle, including test and refinement."
Asked about the biggest gap in the low-power design flow, Tessitore responded as did several other design managers questioned for this report: "The architectural, ESL level, so you can make the right tradeoffs up-front for your low-power architecture." A second major gap, he noted, is the lack of support for power-aware software development.
"Today, decisions are made at RTL or sometimes below," said Philippe Magarshack, group vice president and central CAD and design solutions manager at STMicroelectronics. "We want to go above that to an architectural-level definition."
"Assessing power at the architectural level is still an ad-hoc approach, based on spreadsheets where IP [intellectual property] level numbers are captured and manipulated based on application use cases," said Herve Menager, architect for design methodology and flows at NXP Semiconductor. "Productivity improvements in implementation allow more trials of alternative architectures. So now the bottleneck appears at the architectural decision level."
Designers struggle with an apparent conflict between high-level decision making and accuracy. "The higher the abstraction level, the greater the leverage to save power," said Juergen Karmann, senior staff engineer for design methodology at Infineon. "On the other hand, power analysis is most accurate on the final physical layout."
There are other concerns. David Hui, AMD fellow, said that the biggest low-power design challenge today is accuracy. This shows up in two ways, he said; the difficulty of analyzing power in the face of leakage variations, and the challenge of developing accurate stimuli that represent real-world operations.
Designer priorities may differ, but there is no controversy over the need for power management techniques at 90 nm and below. According to the 2005 International Technology Roadmap for Semiconductors (ITRS), the trend towards higher power density is far outstripping the ability to meet power design requirements (see Figure 1). The growth of leakage (static) power as process nodes shrink is a major reason for that.

Figure 1 – Power trends are outstripping power requirements. Better design techniques are needed to close the gap. (Source: Silicon Integration Initiative (Si2), derived from ITRS 2005 Power Consumption Trends for SoC-PE).
What are designers worried about?
Everyone talks about "low power," but what do they really mean by that term? Why do we care about power, and what do we want to do about it? The answers vary greatly from one application to another. In some cases, the concern is maximizing battery life; in others, it's fitting into a cost-effective package, or reducing heat, or reducing the energy consumption of server farms. Dynamic power is the greater concern in some SoC designs, while leakage power dominates in others.
"You'll get me on a soap box here," said Stephen Padnos, methodology architect at wireless chip design firm Atheros. "Right now, power is sort of a buzz word. Everyone says 'low power' but they don't explain what it really means. You have to sit down and really understand what they mean by 'low power' instead of opening up some textbook and randomly throwing things at the problem."
With leakage power increasing faster than dynamic power (Figure 1), you might think that everyone would be most concerned about leakage. Not so. "In general, I think optimizing leakage is conceptually straightforward," Padnos said. "I think dynamic is a harder problem." One reason is the difficulty of identifying good vectors for dynamic power analysis.
When it comes to mobile multimedia devices, said STMicroelectronics' Magarshack, "the name of the game is optimizing the dynamic power of applications that may run either separately or concurrently." Optimizing dynamic power has "definitely" become more important than optimizing leakage power, "and unfortunately for the designer, the optimization of dynamic power is actually more difficult than static," he said.
At AMD, where Hui works with GPUs and CPUs, designers are concerned about maximizing battery life for notebook computers and containing thermal design power for desktop devices. One of the most vexing challenges is predicting and controlling the impact of process variations on leakage. For fast silicon, he noted, the leakage variation from typical to worst-case could be a factor of 3, 4 or 5.
Your specific power concerns are very much dependent on your application, noted Ameesh Desai, senior director for design tools and methodology at LSI Corp. "If a chip is going into some kind of mobile application, then leakage becomes very important. However, if it is a wired application, and it is in a high-performance storage or networking area, leakage may not be that significant. Dynamic power might be dominant," he said.
The net result: "There is no silver bullet. There is no one solution that will solve all problems. You have to look at a whole suite of different capabilities. There is a ton of techniques you can apply."
To read more please download the full special technology report on low power as PDF
This report identifies the bottlenecks that designers are finding in the low-power design flow, including the lack of automation at the electronic system level (ESL), and talks about some of their successes. Drawing primarily upon user experiences, it discusses the following topics:
• ESL to GDSII challenges
• Planning and implementation of power management techniques
• Architectural issues, including memories and embedded software
• ESL low-power flow – capabilities and limitations
• RTL through physical design
• Challenges of low-power verification and test
Overview: ESL to GDSII challenges
The biggest low-power design bottleneck, many design managers say, is at the architectural or electronic system level (ESL), where the potential power savings are the greatest and where the methodology and tool support is weakest. Design teams are struggling with spreadsheets and back-of-envelope calculations to make power-critical decisions about hardware/software partitioning, processors, memories, clocking, and use of multiple power domains. Power modeling, especially at the system level, lacks a standardized approach and may provide insufficient information.In the RTL-to-GDSII implementation flow, things look better – many IC designs have successfully incorporated power management techniques such as clock gating, power gating, multi-Vdd (multiple supply voltages), dynamic frequency and voltage scaling, and body bias. The implementation of these techniques is not fully automated, and evaluating potential tradeoffs is not easy, but there are some power analysis and optimization tools that can help.
EDA vendors, meanwhile, have created two formats – Common Power Format (CPF) and Unified Power Format (UPF) – that allow users to express power intent in a consistent way throughout the RTL-to-GDSII flow. Both are being successfully deployed, and they're easing low-power design and verification challenges, but designers are caught in the middle of a standards war between the two competing formats.
If we're talking about RTL-to-GDSII digital hardware logic design, low-power design is doing fairly well. But beyond that realm, several huge gaps remain. Embedded software and operating systems can have a huge power impact, but little help is available to evaluate it. Memory is a major consumer of dynamic and leakage power, but is easily overlooked. Analog/mixed-signal blocks need to be power-aware, but tools and methodologies are lacking. And power management techniques, especially those that involve multiple power domains, profoundly impact and complicate functional verification.
"If you don't factor in power throughout the whole development cycle, it is just not going to be optimized," said Ron Tessitore, vice president of advanced application platforms at Qualcomm. "If you don't architect it properly, you are not going to be able to achieve the power target. Technology selection is really important, and so is how you develop the software and write the algorithms. Finally, there's the optimization cycle, including test and refinement."
Asked about the biggest gap in the low-power design flow, Tessitore responded as did several other design managers questioned for this report: "The architectural, ESL level, so you can make the right tradeoffs up-front for your low-power architecture." A second major gap, he noted, is the lack of support for power-aware software development.
"Today, decisions are made at RTL or sometimes below," said Philippe Magarshack, group vice president and central CAD and design solutions manager at STMicroelectronics. "We want to go above that to an architectural-level definition."
"Assessing power at the architectural level is still an ad-hoc approach, based on spreadsheets where IP [intellectual property] level numbers are captured and manipulated based on application use cases," said Herve Menager, architect for design methodology and flows at NXP Semiconductor. "Productivity improvements in implementation allow more trials of alternative architectures. So now the bottleneck appears at the architectural decision level."
Designers struggle with an apparent conflict between high-level decision making and accuracy. "The higher the abstraction level, the greater the leverage to save power," said Juergen Karmann, senior staff engineer for design methodology at Infineon. "On the other hand, power analysis is most accurate on the final physical layout."
There are other concerns. David Hui, AMD fellow, said that the biggest low-power design challenge today is accuracy. This shows up in two ways, he said; the difficulty of analyzing power in the face of leakage variations, and the challenge of developing accurate stimuli that represent real-world operations.
Designer priorities may differ, but there is no controversy over the need for power management techniques at 90 nm and below. According to the 2005 International Technology Roadmap for Semiconductors (ITRS), the trend towards higher power density is far outstripping the ability to meet power design requirements (see Figure 1). The growth of leakage (static) power as process nodes shrink is a major reason for that.

Figure 1 – Power trends are outstripping power requirements. Better design techniques are needed to close the gap. (Source: Silicon Integration Initiative (Si2), derived from ITRS 2005 Power Consumption Trends for SoC-PE).
What are designers worried about?
Everyone talks about "low power," but what do they really mean by that term? Why do we care about power, and what do we want to do about it? The answers vary greatly from one application to another. In some cases, the concern is maximizing battery life; in others, it's fitting into a cost-effective package, or reducing heat, or reducing the energy consumption of server farms. Dynamic power is the greater concern in some SoC designs, while leakage power dominates in others.
"You'll get me on a soap box here," said Stephen Padnos, methodology architect at wireless chip design firm Atheros. "Right now, power is sort of a buzz word. Everyone says 'low power' but they don't explain what it really means. You have to sit down and really understand what they mean by 'low power' instead of opening up some textbook and randomly throwing things at the problem."
With leakage power increasing faster than dynamic power (Figure 1), you might think that everyone would be most concerned about leakage. Not so. "In general, I think optimizing leakage is conceptually straightforward," Padnos said. "I think dynamic is a harder problem." One reason is the difficulty of identifying good vectors for dynamic power analysis.
When it comes to mobile multimedia devices, said STMicroelectronics' Magarshack, "the name of the game is optimizing the dynamic power of applications that may run either separately or concurrently." Optimizing dynamic power has "definitely" become more important than optimizing leakage power, "and unfortunately for the designer, the optimization of dynamic power is actually more difficult than static," he said.
At AMD, where Hui works with GPUs and CPUs, designers are concerned about maximizing battery life for notebook computers and containing thermal design power for desktop devices. One of the most vexing challenges is predicting and controlling the impact of process variations on leakage. For fast silicon, he noted, the leakage variation from typical to worst-case could be a factor of 3, 4 or 5.
Your specific power concerns are very much dependent on your application, noted Ameesh Desai, senior director for design tools and methodology at LSI Corp. "If a chip is going into some kind of mobile application, then leakage becomes very important. However, if it is a wired application, and it is in a high-performance storage or networking area, leakage may not be that significant. Dynamic power might be dominant," he said.
The net result: "There is no silver bullet. There is no one solution that will solve all problems. You have to look at a whole suite of different capabilities. There is a ton of techniques you can apply."
Add Comment - please log-in to comment
SCDsource newsletter subscribers may post a comment - Register for free!Back to Home Page
