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
Algorithm Design
The first step in the design process is to define and verify the algorithm of the system at the behavioral 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 behavioral 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.
It is important to have a testbench that exercises the algorithm as much as possible and as early as possible. This will reduce the time spent on verification at the later stages of the design flow. Creating a testbench at this stage means a designer can use fast behavioral/TLM simulations to verify the algorithm. Also, having accurate stimulus will improve the accuracy of the power estimation process.
The testbench should be designed so that it can be used unchanged for the high-level behavior model and when verifying the RTL code created by the HLS tool and ultimately the gate-level output of logic synthesis. This usually means correctly designing the interfaces between the testbench and the design under test (DUT) so that they are flexible, use handshaking, and do not depend on specific timing delays or cycle counts.
Using this type of testbench will allow a designer to aggressively explore the design space. He or she can perform various tradeoffs for latency, throughput, area, and power and try different code transformations such as pipelining or datapath optimization without worrying about breaking the functionality.
Architecture Design
To obtain good results in the hardware design process, it is essential to properly architect the design. Issues such as I/O and memory interfaces, design partitioning into multiple blocks or modules, data communication between them, and data access patterns affect quality of results.
As a result, these issues must be considered from the beginning of the design process. Time spent on these decisions early will save time optimizing synthesis results and meeting design targets. Of course, it is very difficult to make these decisions without reasonable data.
With a traditional RTL process, this is typically done on spreadsheets or with block diagrams. With SystemC and HLS, architects can use a functional model to quickly test design tradeoffs and get high-level estimates of how each architecture will perform. However, to get more detail for area and power it is essential to get to RTL and perhaps beyond RTL, depending on the design team’s needs.
The first step in the design process is to define and verify the algorithm of the system at the behavioral 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 behavioral 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.
It is important to have a testbench that exercises the algorithm as much as possible and as early as possible. This will reduce the time spent on verification at the later stages of the design flow. Creating a testbench at this stage means a designer can use fast behavioral/TLM simulations to verify the algorithm. Also, having accurate stimulus will improve the accuracy of the power estimation process.
The testbench should be designed so that it can be used unchanged for the high-level behavior model and when verifying the RTL code created by the HLS tool and ultimately the gate-level output of logic synthesis. This usually means correctly designing the interfaces between the testbench and the design under test (DUT) so that they are flexible, use handshaking, and do not depend on specific timing delays or cycle counts.
Using this type of testbench will allow a designer to aggressively explore the design space. He or she can perform various tradeoffs for latency, throughput, area, and power and try different code transformations such as pipelining or datapath optimization without worrying about breaking the functionality.
Architecture Design
To obtain good results in the hardware design process, it is essential to properly architect the design. Issues such as I/O and memory interfaces, design partitioning into multiple blocks or modules, data communication between them, and data access patterns affect quality of results.
As a result, these issues must be considered from the beginning of the design process. Time spent on these decisions early will save time optimizing synthesis results and meeting design targets. Of course, it is very difficult to make these decisions without reasonable data.
With a traditional RTL process, this is typically done on spreadsheets or with block diagrams. With SystemC and HLS, architects can use a functional model to quickly test design tradeoffs and get high-level estimates of how each architecture will perform. However, to get more detail for area and power it is essential to get to RTL and perhaps beyond RTL, depending on the design team’s needs.
|
|
|
|
|
Navigate to related information