Design Article
Transitioning from C/C++ to SystemC in high-level design
John Sanguinetti
5/31/2010 10:15 PM EDT
In high-level design, high-level code is put through a series of steps on its way to becoming register transfer level (RTL) code. The first step, algorithm design, is usually done in C or C++, where the high-level code that describes how the system will function is created. To be implemented in hardware, this high-level code must be converted to RTL code, using a synthesis tool. It's almost never the case, however, that high-level synthesis using the result of the algorithm design phase will produce a desirable RTL implementation. An architecture design phase that precedes high-level synthesis is required in order to produce RTL code with the desired characteristics.
Making a translation to SystemC for this step has become the preferred high-level design method. In this article, I'll give some examples of steps taken in the architecture design phase that can help you achieve good RTL code.
High-level design has many advantages over the more commonplace design flow that begins with RTL code. Among the most compelling advantages is the improved verification efficiency that a higher level of abstraction offers. It's apparent to the point of being self-evident that when the source code of a design is created, fewer errors occur if the source is at a higher abstraction level than if it is at a lower level. However, a process is still required to verify the transformations that are applied to the design description as it proceeds through the design flow from creation to final realization.
Figure 1 shows the initial steps in the high-level design (HLD) flow. Figure 2 shows the flow with the verification steps and the design loops added. A verification step after each design step can result in a loop back to fix a design error. Another loop after each of the two synthesis steps can return you to the architecture design step, where you'll improve whatever relevant design criteria have not been met. This loop back to the architecture design step is a key part of the high-level design process.
 Click on image to enlarge. |
 Click on image to enlarge. |
Architecture design
The architecture design step in Figure 1 is the fundamental "hardware design" step in a high-level design flow. High-level design, particularly when done using "Plain old C," is often presented as a process where the designer simply takes a C algorithm, runs it through a high-level synthesis tool, and gets high-quality RTL. This high-quality result, however, almost never happens.
The architecture design step is where hardware design is done for a fundamental reason. Algorithms developed in C are software representations, and there are very different costs and benefits between hardware and software implementations.
|
|
|
|
|
KarlS
6/16/2010 1:37 PM EDT
Do you call it a bug when temp_array2 is never accessed?
Also, there are embedded memory blocks that are much more efficient than "flattening" the array into registers and muxes.
Sign in to Reply
Lundin
6/18/2010 2:42 AM EDT
Yes there is a bug in example 2:
j<=32
He will write out of bounds to the array.
There is also a bug in example 1:
for(j=0...; i+=4)
for(i=0; ... ; i++)
It shouldn't even compile.
Sign in to Reply
jsang
6/19/2010 6:31 PM EDT
There are indeed errors in example 1 and example 2 as has been pointed out. Poor proof-reading. There is another error in example 2 -- the last line should read:
data = tmp_array1[idx] + tmp_array2[idx];
This is an interesting example, since the loop with the two temporary arrays will disappear entirely at synthesis time. While it would certainly be smaller to use an embedded memory, it wouldn't be faster. The synthesis tool can't know which the user wants without some guidance. Once the user tells the tool that he wants to use registers, doing a transformation like this would be possible for the tool to do automatically, but it's pretty unlikely.
--John Sanguinetti
Edited by: ESD editorial staff: SRambo on Jun 21, 2010 9:27 AM
Sign in to Reply
KarlS
6/20/2010 11:49 AM EDT
So what are we here for? Synthesis will throw the design away, even though it is supposed to be a "tool" to use to do the design. We have a flat statement that an embedded memory is smaller, but not faster. BUT of course there are no numbers for anything, just the typical academic hype.
data = tmp_array1idx + tmp_array2idx; OR
data = tmp_array1[idx] + tmp_array2[idx]; ???
Sign in to Reply
KarlS
6/20/2010 11:54 AM EDT
Sorry, the edit did not work
data = tmp_array1idx + tmp_array2idx; OR
data = tmp_array1[idx] + tmp_array2[idx];
I tried to put brackets around idx.
Sign in to Reply
ESD editorial staff: SRambo
6/21/2010 9:25 AM EDT
The brackets don't work on the Embedded.com/EE Times Group forums. Our web developers are aware of the problem.
--Susan Rambo
Managing Editor
Embedded Systems Design magazine
Sign in to Reply
ESD editorial staff: SRambo
6/21/2010 9:49 AM EDT
Attached are the examples from the author's (John Sanguinetti's) original text as submitted to ESD magazine, in case this provides some clarity.
--Susan Rambo
Managing Editor
Embedded Systems Design magazine
Sign in to Reply
Lundin
6/22/2010 9:52 AM EDT
Oh yeah what does that mean? Access idx + 32 of an 32 byte long array. That's the same thing as writing
if(idx != 0) seg_fault();
We have some high quality code in those examples!
Sign in to Reply
KarlS
6/22/2010 12:58 PM EDT
Quote from above:
Post Message: Reply
Type a reply to the thread using the form below. When finished, you can optionally preview your reply by clicking on the "Preview" tab. Otherwise, click the "Post Message" button to submit your message immediately. unQuote
Maybe while fixing the brackets they can put the Preview button where I can find it!!!!!!!!!!!!!
Sign in to Reply
KarlS
6/22/2010 1:18 PM EDT
It is not only the quality of code in the examples, it is the usability of the tools produced by the same people. Yes, I mean it is utterly stupid that synthesis programmers think it's OK to throw away things they don't understand. For instance I remember a project in a major company where error detection was top priority. Control logic was duplicated then compared and parity checks were all over the place until synthesis decided to throw away the dupes, so there went all the carefully designed checking..
Now we have ESL that creates a lot of mysterious HDL Then synthesis may or may not throw some away and the designer is saddled with the task of making the whole mess work. Of course it will only take hours to create RTL for each pass so the designer can get simulation results to analyze.
Sign in to Reply
ESD editorial staff: SRambo
6/23/2010 5:42 PM EDT
KarlS,
Thank you for pointing out this forum's Kafkaesque instructions about the preview tab (there is no preview tab as far as I know). Just today, after reading your comment, I reminded the editors-in-chief and the manager of our web of development that the preview tab needs to be added.
And once again, thanks to everyone for your patience in using this forum. Although the user experience can be improved, the automatic posting still beats having to have an editor post every reader's response by hand, as we used to have to do a few years ago. (For one, we'd never have any discussions if you had to wait for an editor to pos or approve your comment.) If, however, you have posted something that you'd really like to have fixed, contact me by e-mail using the word "Forum" somewhere in your subject line. I can edit or remove your comments.
--Susan
Susan Rambo
Managing Editor, Embedded Systems Design magazine
Site editor, Industrial Control Designline
EE Times Group
Email: susan.rambo@ubm.com
Sign in to Reply
jsd66
7/8/2010 4:46 PM EDT
I wonder how this article would incorporate the advent of a tool such as Catapult. Does the appearance of such a tool imply we are moving faster than anticipated towards the PoC->RTL frontier??
Sign in to Reply