Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
2012 will be the year of power, again
Brett Cline
4/25/2012 11:01 AM EDT
Power seems to be the buzzword for 2012. Of course, it always has been important but, for some reason, it seems to be even more important now. Why is that?
Perhaps it is because the number of mobile devices is growing at an extraordinary pace and the competition is fierce. Or, maybe it’s because desktop and server environments (read: cloud and server farms, for example) are hungrier than ever for watts. Or, what if gates really are “free” as we approach smaller design nodes? Has the pendulum swung away from critical area requirements toward power reduction?
In reality, the push for lower power probably is a combination of a number of factors including those above. It also depends on the application for the design. What is certain is that power, just as with area, seems to be important to every design team to some extent. It is up to the tool vendors to find ways to allow design teams to consistently improve quality of results (QoR) in multiple dimensions, including power.
Traditionally the power problem has been attacked from two sides. First, the chip or system architect would make architectural tradeoffs based on past experiences with limited practical data in hopes of getting the higher order bits correct. Then, in register transfer level (RTL) code and below, design and implementation teams would do their best to squeeze out milliwatts while carefully managing the area, performance, power QoR triangle. This was and is a careful balancing act at best, sometimes with disastrous results1.
Ultimately, there are two issues with the above process. At the architectural level, it is much easier (relatively speaking) to make design changes quickly that may have a significant impact on power. However, there is little data about how the chip/system will react once implemented for each of these design changes because the abstraction level is too high. Of course, with the actual RTL code, this isn’t as much of a problem because the detail is there. Making design changes that can significantly impact power in RTL code is generally not possible without changing the architecture, which would take too much time. Even small micro-architecture changes can take a long time in RTL code and do not generally have a significant power benefit.
Chip designers need a way to get better data earlier in the process without committing to specific architectural choices and the RTL code until much later in the process. Further, the RTL code needs to produce a high quality of results across multiple dimensions.
This is where high-level synthesis (HLS) can help. HLS has been known for its ability to raise the abstraction level as compared to RTL with better results (area) in less time. Could HLS be applied to the power problem? The answer is yes.
Using HLS, architects and designers can work together to make high-level architectural decisions based on practical data while allowing the design team to create high-quality design implementations with lower-level power optimizations built-in.
Using a high-level design methodology and SystemC, design teams can implement a relatively simple flow where a high-level transaction-level model (TLM) could be used to make architectural tradeoffs before committing to any given underlying implementation.
Next: Algorithm Design
Perhaps it is because the number of mobile devices is growing at an extraordinary pace and the competition is fierce. Or, maybe it’s because desktop and server environments (read: cloud and server farms, for example) are hungrier than ever for watts. Or, what if gates really are “free” as we approach smaller design nodes? Has the pendulum swung away from critical area requirements toward power reduction?
In reality, the push for lower power probably is a combination of a number of factors including those above. It also depends on the application for the design. What is certain is that power, just as with area, seems to be important to every design team to some extent. It is up to the tool vendors to find ways to allow design teams to consistently improve quality of results (QoR) in multiple dimensions, including power.
Traditionally the power problem has been attacked from two sides. First, the chip or system architect would make architectural tradeoffs based on past experiences with limited practical data in hopes of getting the higher order bits correct. Then, in register transfer level (RTL) code and below, design and implementation teams would do their best to squeeze out milliwatts while carefully managing the area, performance, power QoR triangle. This was and is a careful balancing act at best, sometimes with disastrous results1.
Ultimately, there are two issues with the above process. At the architectural level, it is much easier (relatively speaking) to make design changes quickly that may have a significant impact on power. However, there is little data about how the chip/system will react once implemented for each of these design changes because the abstraction level is too high. Of course, with the actual RTL code, this isn’t as much of a problem because the detail is there. Making design changes that can significantly impact power in RTL code is generally not possible without changing the architecture, which would take too much time. Even small micro-architecture changes can take a long time in RTL code and do not generally have a significant power benefit.
Chip designers need a way to get better data earlier in the process without committing to specific architectural choices and the RTL code until much later in the process. Further, the RTL code needs to produce a high quality of results across multiple dimensions.
This is where high-level synthesis (HLS) can help. HLS has been known for its ability to raise the abstraction level as compared to RTL with better results (area) in less time. Could HLS be applied to the power problem? The answer is yes.
Using HLS, architects and designers can work together to make high-level architectural decisions based on practical data while allowing the design team to create high-quality design implementations with lower-level power optimizations built-in.
Using a high-level design methodology and SystemC, design teams can implement a relatively simple flow where a high-level transaction-level model (TLM) could be used to make architectural tradeoffs before committing to any given underlying implementation.
(Source: Forte Design Systems - Cynthesizer Methodology Guide)
The graphic above illustrates the three main steps in the methodology, including the algorithm definition and verification, the architecture definition and verification, and the RTL code creation and verification. The final implementation phase for RTL logic synthesis and below has been omitted because there are no practical changes to that flow from what is done today.
Next: Algorithm Design
|
|
|
|
|
Navigate to related information