Commentary: ANSI C won't work for ESL

While SystemC has been accepted by most systems, semiconductor, and EDA companies as the language of choice for high-speed system-level modeling, there is a continued debate over which language is best for electronic system level (ESL) synthesis.

Some prefer ANSI C or C++. They argue that the breadth of algorithmic software available in these languages and the large numbers of people familiar with them make them a natural fit for synthesizing hardware implementations from high-level algorithmic descriptions.

These arguments have some merit, and at first blush the prospect of re-using existing software source code for hardware implementation looks fast and easy. Unfortunately, hardware designers attempting this while continuing to meet the challenging power consumption, silicon area, and performance demands of today's high-volume consumer oriented systems-on-chip will encounter two intractable problems. Source code optimized for execution on a processor is unsuitable for direct hardware implementation, and C and C++ have a fundamental inability to express constructs that are necessary for effective hardware design.

The unsuitability of existing software-oriented C or C++ source code for creation of hardware implementation stems from the origin of these languages. Dennis Richie, the developer of the C language has described it and its predecessor BCPL as "close to the machine" in that the abstractions they introduce are readily grounded in the concrete data types and operations supplied by conventional computers. C and C++ naturally implement:

• A single process with sequential execution
• Variables of only a few specific sizes
• A single, relatively large, addressable memory
• Communication through subroutine parameters, function call return values, and by passing a pointer to data stored in memory

Contrast this with the characteristics of an efficient hardware implementation:

• Multiple blocks executing in parallel for maximum throughput
• Variables with bit-widths carefully tuned to conserve every flip-flop
• Dedicated point-to-point communication channels and hierarchical bus structures to maximize parallelism and available bandwidth

Software developers are so used to coding for execution on conventional computers that they systematically and unconsciously optimize for these architectures. While creating quality hardware from an existing software description is an enticing goal, in practice it is unachievable. For example, many video processing software packages use many large frame buffers to pass data between intermediate stages of an algorithm implemented as subroutines. This is perfectly reasonable on a modern computer where memory is abundant.

Refinement for efficient hardware will require different optimizations. In the video processing case, the pixels might be streamed between the stages with each stage executing in parallel. Each stage would utilize the minimum buffer size needed according to its particular algorithm. Rather than trying to build hardware from existing software source, a better approach is to refine the algorithm for hardware implementation and to use good design practices and C++ techniques to build it in a modular way that maximizes the amount of source code that can be used for both implementation and simulation purposes.

Because SystemC is a C++ library, it retains some of the benefit of being able to re-use existing C and C++ code. A C algorithm is a good place to begin refinement for implementation. Because it is often written to minimize system resources used, a C algorithm optimized for use as embedded software is often an even better beginning.