The Challenges of Synthesizing Hardware from C-Like Languages Stephen A. Edwards Columbia University must find it (a difficult task) or the Editor’s note: designer must use language extensions This article presents one side of an ongoing debate on the appropriateness and insert explicit parallelism. Neither of C-like languages as hardware description languages. The article examines solution is satisfactory, and the latter various features of C and their mapping to hardware, and makes a cogent argument that vanilla C is not the right language for hardware description if requires that C programmers think dif- synthesis is the goal. ferently to design hardware. —Sandeep K. Shukla, Virginia Polytechnic and State University My main point is that giving C pro- grammers tools is not enough to turn them into reasonable hardware design- THE MAIN REASON people have proposed C-like lan- ers. Efficient hardware is usually very difficult to describe guages for hardware synthesis is familiarity. Proponents in an unmodified C-like language, because the language claim that by synthesizing hardware from C, we can effec- inhibits specification or automatic inference of adequate tively turn every C programmer into a hardware design- concurrency, timing, types, and communication. The er. Another common motivation is hardware-software most successful C-like languages, in fact, bear little codesign: Designers often implement today’s systems as a semantic resemblance to C, effectively forcing users to mix of hardware and software, and it’s often unclear at learn a new language (but perhaps not a new syntax). the outset which portions can be hardware and which As a result, techniques for synthesizing hardware from can be software. The claim is that using a single language C either generate inefficient hardware or propose a lan- for both simplifies the migration task. guage that merely adopts part of C syntax. I argue that these claims are questionable and that Here, I focus only on the use of C-like languages for pure C is a poor choice for specifying hardware. On the hardware synthesis and deliberately omit discussion of contrary, the semantics of C and similar imperative lan- other important uses of a design language, such as vali- guages are distant enough from hardware that C-like dation and algorithm exploration. C-like languages are far thinking might be detrimental to hardware design. more compelling for these tasks, and one in particular, Instead, successful hardware synthesis from C seems to SystemC, is now widely used, as are many ad hoc variants. involve languages that vaguely resemble C, mostly its syntax. Examples of these languages include Celoxica’s A short history of C Handel-C1 and NEC’s Behavior Description Language Dennis Ritchie developed C in the early 1970s,3 (BDL).2 You can think of executing C code on a tradi- based on experience with Ken Thompson’s B language, tional sequential processor as synthesizing hardware which had evolved from Martin Richards’ Basic from C, but the techniques presented here strive for Combined Programming Language (BCPL). Ritchie more highly customized implementations that exploit described all three as “close to the machine” in the greater parallelism, hardware’s main advantage. sense that their abstractions are similar to data types and Unfortunately, the C language has no support for user- operations supplied by conventional processors. specified parallelism, and so either the synthesis tool A core principle of BCPL is its memory model: an 0740-7475/06/$20.00 © 2006 IEEE Copublished by the IEEE CS and the IEEE CASS September–October 2006 375 Electronic System-Level Design Ritchie listed a number of infelicities in the language Performance or bust caused by historical accident. For example, the use of Throughout this article, I assume that optimizing perfor- break to separate cases in switch statements arose mance—for example, speed under area and power con- because Ritchie copied an early version of BCPL; later straints—is the main goal of hardware synthesis (beyond, of versions used endcase. The precedence of bitwise-AND course, functional correctness). This assumption implicitly is lower than the equality operator because the logical- shapes all my criticisms of using C for hardware synthesis and AND operator was added later. should definitely be considered carefully. Many aspects of C are greatly simplified from their On the one hand, performance optimization has obvious BCPL counterparts because of limited memory on the economic advantages: An efficient circuit solves problems PDP-11 (24 Kbytes, of which 12 Kbytes were devoted to faster, is cheaper to manufacture, requires less power, and so the nascent Unix kernel). For example, BCPL allowed forth. Historically, this has been the key focus of logic synthe- the embedding of arbitrary control flow statements with- sis, high-level synthesis, and other automated techniques for in expressions. This facility doesn’t exist in C, because generating circuits. limited memory demanded a one-pass compiler. On the other hand, optimization can have disadvantages Thus, C has at least four defining characteristics: a set such as design time and nonrecurring engineering costs. The of types that correspond to what the processor directly distinction between full-custom ICs and ASICs illustrates this. manipulates, pointers instead of a first-class array type, A company like Intel, for example, is willing to invest an enor- several language constructs that are historical accidents, mous number of hours in designing and hand-optimizing its and many others that are due to memory restrictions. next microprocessor’s layout because of the volume and mar- These characteristics are well-suited to systems soft- gins the company commands. A company like Cisco, howev- ware programming, C’s original application. C compil- er, might implement its latest high-end router on an FPGA ers have always produced efficient code because the C because it doesn’t make economic sense to design a com- semantics closely match the instruction set of most gen- pletely new chip. Both approaches are reasonable. eral-purpose processors. This also makes it easy to A key question, then, is: What class of problems does hard- understand the compilation process. Programmers rou- ware synthesis from C really target? This article assumes an tinely use this knowledge to restructure source code for audience of traditional hardware designers who want to design efficiency. Moreover, C’s type system, while generally hardware more quickly, but other articles target designers who very helpful, is easily subverted when needed for low- would otherwise implement their designs in software but need level access to hardware. faster results. The soundness of my conclusions may well These characteristics are troublesome for synthesiz- depend on which side of this fence you’re on. ing hardware from C. Variable-width integers are natur- al in hardware, yet C supports only four sizes, all larger than a byte. C’s memory model is a large, undifferenti- undifferentiated array of words. BCPL represents inte- ated array of bytes, yet hardware is most effective with gers, pointers, and characters all in a single word; the many small, varied memories. Finally, modern compil- language is effectively typeless. This made perfect sense ers can assume that available memory is easily 10,000 on the word-addressed machines BCPL was targeting, times larger than that available to Ritchie. but it wasn’t acceptable for the byte-addressed PDP-11 on which C was first developed. C-like hardware synthesis languages Ritchie modified BCPL’s word array model to add the Table 1 lists some of the C-like hardware languages familiar character, integer, and floating-point types now proposed since the late 1980s (see also De Micheli4). supported by virtually every general-purpose processor. One of the earliest was Cones, from Stroud et al.5 From Ritchie considered C’s treatment of arrays to be charac- a strict subset of C, it synthesized single functions into teristic of the language. Unlike other languages that have combinational blocks. Figure 1 shows such a function. explicit array types, arrays in C are almost a side effect Cones could handle conditionals; loops, which it of its pointer semantics. Although this model leads to unrolled; and arrays treated as bit vectors. simple, efficient implementations, Ritchie observed that Ku and De Micheli developed HardwareC6 for input the prevalence of pointers in C means that compilers to their Olympus synthesis system.7 It is a behavioral must use careful dataflow techniques to avoid aliasing hardware language with a C-like syntax and has exten- problems while applying optimizations. sive support for hardware-like structure and hierarchy. 376 IEEE Design & Test of Computers INPUTS: IN[5]; Table 1. C-like languages for hardware synthesis. OUTPUT: OUT[3]; rd53() Language Comment { Cones Early, combinational only int count, i; count = 0; HardwareC Behavioral synthesis centered for (i=0 ; i<5 ; i++) Transmogrifier C Limited scope if (IN[i] == 1) count = count + 1; SystemC Verilog in C++ for (i=0 ; i<3 ; i++) { Ocapi Algorithmic structural descriptions OUT[i] = count & 0x01; C2Verilog Comprehensive count = count >> 1; } BDL Many extensions and restrictions (NEC) } Handel-C C with CSP (Celoxica) SpecC Resolutely refinement based Figure 1. A function that returns a count of the Bach C Untimed semantics (Sharp) number of 1’s in a five-bit vector in Cones. The CASH Synthesizes asynchronous circuits function is translated into