Design Article
The war is over: C++ and SystemC coexist in a single flow
Thomas Bollaert and Mike Fingeroff, Mentor Graphics Corp.
12/15/2010 10:38 AM EST
Interfaces
An interface implies a protocol, and a protocol means time. So generally they fall under the category of control. Interfaces can be complex or simple and they can be custom or standard.
When timing is part of the interface behavior, such as with bus protocols, SystemC is the better choice. With protocols, you usually want to test how something is done: is it compliant. Therefore, you need to simulate and test the impact of the interface on the timing in the source description, because time is a property of protocols. Therefore, you should use SystemC. Because the protocol is hard coded in the source, you can test the consequence of a specific protocol in the source, and the HLS tool will not change it; it will build it how you tell it to.
Yet, for simpler interfaces, such as point-to-point connections found in processing blocks and processing pipelines, we recommend C++ because the goal is to make sure the transfer of data is “safe,” regardless of how it is implemented. In other words, all you care about is what it does. This does not have timing information and does not need to be simulated.
If you care only about the outcome, the what, you don’t want to redesign the interface in your own model. You simply pull from a library definition the interface implementation that fits your needs. Since you don’t have the actual protocol model in the source, the source behaves correctly. Thus, instead of committing to the interface in the source you wait to commit to it as you go through synthesis. This pure sequential ANSI C/C++ implementation preserves the ability to change from one interface protocol to another without modifying the source, resulting in less chance for errors and more time for exploring design space options.
An example system with a bus-based communication architecture is shown in Figure 1. The system contains a master and two slaves communicating through an AMBA 3.0 AHB-Lite bus. This example shows how to combine untimed functional descriptions with cycle-accurate interface protocols wrapped in Modular IO classes. In this example, the master is assumed to be the target for HLS. The rest of the components in the system are considered external, from a synthesis stand point. However, these external components exist in the testbench for verification.
The master and slaves communicate using Modular IO interface classes that abstract the protocol used for communication. The reason for this is to improve ease-of-use and design reuse. The master consists of three, two-way handshake interfaces and an AHB-Lite bus interface (bus I/F). The two-way handshake interfaces are: command interface (cmd in I/F), data in interface (data in I/F), and the data out interface (data out I/F). Depending on the commands received from cmd in I/F, the master would do one of the following: 1) read samples from data in I/F and write it to Slave 1 memory using bus I/F, 2) one at a time, read samples from Slave 1 memory using bus I/F, filter it using FIR filter, and write the result to Slave 2 memory using bus I/F, and 3) read samples from Slave 2 memory using bus I/F and write it out on data out I/F.
Figure 1: Bus-based communication architecture.
(Click on image to enlarge)
Figure 2: Using interface synthesis to add a timed protocol to C++ interfaces.
Next: Hierarchy
An interface implies a protocol, and a protocol means time. So generally they fall under the category of control. Interfaces can be complex or simple and they can be custom or standard.
When timing is part of the interface behavior, such as with bus protocols, SystemC is the better choice. With protocols, you usually want to test how something is done: is it compliant. Therefore, you need to simulate and test the impact of the interface on the timing in the source description, because time is a property of protocols. Therefore, you should use SystemC. Because the protocol is hard coded in the source, you can test the consequence of a specific protocol in the source, and the HLS tool will not change it; it will build it how you tell it to.
Yet, for simpler interfaces, such as point-to-point connections found in processing blocks and processing pipelines, we recommend C++ because the goal is to make sure the transfer of data is “safe,” regardless of how it is implemented. In other words, all you care about is what it does. This does not have timing information and does not need to be simulated.
If you care only about the outcome, the what, you don’t want to redesign the interface in your own model. You simply pull from a library definition the interface implementation that fits your needs. Since you don’t have the actual protocol model in the source, the source behaves correctly. Thus, instead of committing to the interface in the source you wait to commit to it as you go through synthesis. This pure sequential ANSI C/C++ implementation preserves the ability to change from one interface protocol to another without modifying the source, resulting in less chance for errors and more time for exploring design space options.
An example system with a bus-based communication architecture is shown in Figure 1. The system contains a master and two slaves communicating through an AMBA 3.0 AHB-Lite bus. This example shows how to combine untimed functional descriptions with cycle-accurate interface protocols wrapped in Modular IO classes. In this example, the master is assumed to be the target for HLS. The rest of the components in the system are considered external, from a synthesis stand point. However, these external components exist in the testbench for verification.
The master and slaves communicate using Modular IO interface classes that abstract the protocol used for communication. The reason for this is to improve ease-of-use and design reuse. The master consists of three, two-way handshake interfaces and an AHB-Lite bus interface (bus I/F). The two-way handshake interfaces are: command interface (cmd in I/F), data in interface (data in I/F), and the data out interface (data out I/F). Depending on the commands received from cmd in I/F, the master would do one of the following: 1) read samples from data in I/F and write it to Slave 1 memory using bus I/F, 2) one at a time, read samples from Slave 1 memory using bus I/F, filter it using FIR filter, and write the result to Slave 2 memory using bus I/F, and 3) read samples from Slave 2 memory using bus I/F and write it out on data out I/F.
Figure 1: Bus-based communication architecture.
(Click on image to enlarge)
The master’s interface and port definitions are provided below:
Master1 uses the wait_in interface class to receive commands and data. It uses the wait_out interface class to send data out.
The sc_cthread process inside the master is provided below:
The sc_cthread process inside the master is provided below:
Figure 2 shows the advantages of using untimed C++ synthesis when only simple point-to-point protocols are required. The top-level C++ source contains only untimed C++ variables with no concept of interface protocol. The process of interface synthesis allows designers to specify simple, timed protocols as constraints during the synthesis process.
Figure 2: Using interface synthesis to add a timed protocol to C++ interfaces.
Next: Hierarchy
|
|
|
|
|
Navigate to related information
DKC
12/16/2010 3:35 AM EST
What war? SystemC is just a C++ class library. It would pretty lame not to be able to have them coexist.
How about analog and power? When will we see -
"The wait is over: C++ and Spice coexist in a single flow"?
Sign in to Reply
cfelton_emb
2/16/2011 5:33 PM EST
Python and spice coexist in a single language.
Sign in to Reply
stevekuznicki
12/16/2010 9:22 AM EST
DKC - yes, i was a bit perplexed by the title as well. Multiple HLS technologies should co-exist in a single work-flow, not only these. It is really in what application you are designing for and what VnV activities are required- which can really impact the quality of the product and TTM.
Sign in to Reply
jskull
12/23/2010 4:12 AM EST
Why is the example given for these HLS tools always a trivial datapath block such as an FIR filter?
It gives the impression, rightly or wrongly, that the tools are only good for simple pipelines. I am not losing sleep over those sorts of designs.
Sign in to Reply
Rishiyur.Nikhil
1/18/2011 5:57 PM EST
"... but it has been proven that it is easy to extract parallelism from sequential sources."
This will come as news to everyone in the High Performance Computing community, who have been attempting to do this unsuccessfully for over 40 years. It will also be news to the authors of the numerous textbooks on parallel algorithms (if extracting parallelism was easy, why would we need them?)
Sam Fuller (CTO Analog Devices) and co-author Lynette Millett have the opposite opinion: "Experience has shown that parallelizing sequential code or highly sequential algorithms effectively is exceedingly difficult in general." in their article "Computing Performance: Game Over or Next Level", IEEE Computer, January 2011, pp. 31-38, reporting on the NSF-sponsored study by the Computer Science and Telecommunications Board of the US National Academy of Sciences.
Sign in to Reply
Jack.Erickson
1/24/2011 9:35 AM EST
This article shows that SystemC is required to do any real design. Since SystemC is a class lib of C++, thus a superset, and since SystemC processes can contain pure untimed C++ code, shouldn’t the article be titled: “SystemC is the language of ESL”.
Also why does the article avoid the very popular TLM standard which enables easy separation of the interface from the computation and yields large simulation speedups (instead of inserting an RTL interface from a library)?
For those interested in how to do production design with SystemC, there's an archived EETimes webinar by Mark Warren aptly titled "Practical application of high-level synthesis in SoC designs".
Sign in to Reply
mr88cet
2/17/2011 1:05 PM EST
Maybe this example might help clear up some of the "huh?!" discussion: Your task is to HLS a block that crunches data in a certain way, and is interfaced into a certain system environment.
For the crunching part, you want to use the HLS tool to help you examine lots of microarchitectures, meaning implementation possibilities (various data widths, depths of pipelining, etc.). You may even want to create two or three different implementations at different price/performance points, but the tool must create the RTL for all of those different implementations. You only change a few microarchitectural parameters, pipeline-depth, for example, push a button and out pops radically different RTL.
In the meantime, however, there are interfaces to the world around that algorithmic portion that absolutely must proceed according to a very exact, and possibly intricate, timing definition. You have to ensure that those timing concerns are never violated. It's possible, for example, that a certain implementation of that algorithmic logic will not be able to process the data quickly enough to satisfy the data rates of the interface.
If that's the case, we want the HLS tool, not the designer, to limit the available choices of microarchitectures so that the bandwidth requirements of the interface will never be violated.
Sign in to Reply