Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Address power concerns using HLS

Posted: 10 May 2012     Print Version  Bookmark and Share

Keywords:register transfer level  high-level synthesis  SystemC 

The buzzword for 2012 seems to be "power". Without a doubt, 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 towards 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 trade-offs 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 optimisations 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 trade-offs before committing to any given underlying implementation.

The figure 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.

Figure: The three main steps in the methodology (Source: Forte Design Systems—Cynthesizer Methodology Guide).

Algorithm design
The first step in the design process is to define and verify the algorithm of the system at the behavioural level. Design teams may have an algorithm written, typically as a software program, or may be starting from a specification. The first step converts the specification or C/C++ code into a SystemC behavioural model to add hardware detail and a testbench that exercises and verifies the algorithm. Of course, the C/C++ may be used directly with predetermined interfaces. The level of detail will ultimately determine the level of accuracy later in the process.

1 • 2 Next Page Last Page



Comment on "Address power concerns using HLS"
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

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

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top