Transitioning from C/C++ to SystemC in high-level design

John Sanguinetti

May 31, 2010

John Sanguinetti

Some of the fundamental differences between software and hardware implementations are:

• Hardware is hierarchical, and the communication between subunits (subroutines in software, modules in hardware) is different. While only a few calling conventions implement software interfaces, there are many more possibilities for hardware interfaces. Plain old C (PoC) provides call by value, which, along with the ability to pass pointers, suffices for subroutine calls. However, there is no facility for representing the myriad variations of hardware interfaces. For example, ready-valid, trigger-done, AMBA bus read/write, custom bus-there are often good reasons for a hardware implementation to use a custom interface.

• The cost of memory access in hardware is much higher than in software. Consequently, PoC algorithms often simply store a lot of data in memory, then access it in whatever fashion is convenient for the algorithm. By contrast, the same algorithm implemented in hardware can often be done with a much smaller window of the data being processed at a time, and either written once or passed on to another processing phase. Image processing algorithms are usually done this way. The algorithm in software will simply iterate over the whole image, while the hardware implementation will work on a smaller window that moves over the image, as Example 1 demonstrates.)


Click on image to enlarge.

• Conditional expressions are cheap in software but can be expensive in hardware. This is illustrated when accessing array elements with a variable index when the array is mapped onto dedicated hardware registers, shown in Example 2.


Click on image to enlarge.

Design optimization
It's convenient to use a different language for the architecture design step rather than Plain old C, because C does not provide the ability to represent a few key hardware-related features, notably hierarchy, data-path widths, and concurrency. SystemC was developed for just this reason. SystemC is not a separate language, but simply a C++ class library that provides the missing features. It's far easier to do architecture design in SystemC than it is to do it in C.

Example 1 shows a C algorithm as it would be written for software implementation and how it would be modified for hardware implementation. Making the change to SystemC from the original C is a small step compared with the iterative process that takes place while refining the hardware implementation.

Example 2 shows a SystemC fragment that adds two elements from an array, where each operand is half the array apart. The straightforward original code results in two big muxes when implemented in hardware. The less obvious modified code results in a much smaller hardware implementation.

The examples show transformations made to source code to produce a better hardware result out of high-level synthesis. These are examples of optimization where the modified code will result in a smaller, more efficient hardware implementation when high-level synthesis is applied. In many cases, the design process is one of successive optimizations in order to get a hardware implementation that is as small, fast, and/or power efficient as possible. This is a manual process, where the hardware designer uses his knowledge and experience to make the appropriate code transformations.

One can ask why such a manual process is necessary, since the promise of high-level synthesis is to remove the drudgery of mapping higher-level operations to hardware. The answer is that there are many ways to implement an algorithm in hardware, and no single choice is the best under all design constraints. Some transformations, it could be argued, should always be done, and could thus be implemented in the high-level synthesis tool, as in Example 2. However, there are a great many examples of code where the high-level synthesis tool could in principle recognize the original without requiring the code to be rewritten but in practice requires the designer to do the transformation. No high-level synthesis tool will recognize them all (at least within our lifetimes), which means the hardware designer will always have a job.

< Previous
Page 2 of 3
Next >

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER