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 a combinational Catapult C ANSI C++ subset (Mentor Graphics) circuit.
#define SIZE 8 process gcd (xi, yi, rst, ou) #pragma intbits 8 in port xi[SIZE], yi[SIZE]; seven_seg(x) in port rst; #pragma intbits 4 out port ou[SIZE]; int x; { { boolean x[SIZE], y[SIZE]; #pragma intbits 8 int result; write ou = 0; x = x & 0xf; result = 0; if ( rst ) < if (x == 0x0) result = 0xfc; x = read(xi); if (x == 0x1) result = 0x60; y = read(yi); if (x == 0x2) result = 0xda; > if (x == 0x3) result = 0xf2; if (x == 0x4) result = 0x66; if ((x != 0) & (y != 0)) if (x == 0x5) result = 0xb6; repeat { if (x == 0x6) result = 0xbe; while (x >= y) if (x == 0x7) result = 0xe0; x = x – y; if (x == 0x8) result = 0xfe; < if (x == 0x9) result = 0xf6; x = y; /* swap x and y */ return(~result); y = x; } > } until (y == 0); twodigit(y) else int y; x = 0; { write ou = x; int tens; } int leftdigit, rightdigit; outputport(leftdigit, 37, 44, 40, 29, 35, 36, 38, 39); Figure 2. Greatest common divisor algorithm in outputport(rightdigit, HardwareC. Statements within a < > block run in 41, 51, 50, 45, 46, 47, 48, 49); parallel; statements within a { } block execute in tens = 0; parallel when data dependencies allow. while (y >= 10) { tens++; y –= 10; } Figure 2 shows the greatest common divisor (GCD) algo- leftdigit = seven_seg(tens); rightdigit = seven_seg(y); rithm in HardwareC. } Galloway’s Transmogrifier C is a fairly small C subset that supports integer arithmetic, conditionals, and loops.8 Unlike Cones, it generates sequential designs by inferring Figure 3. Two-digit decimal-to-seven-segment a state at function calls and at the beginning of while decoder in Transmogrifier C. Output-port loops. Figure 3 shows a decoder in Transmogrifier C. declarations assign pin numbers.
September–October 2006 377 Electronic System-Level Design
#include “systemc.h” SystemC is a C++ dialect that supports hardware and #include
378 IEEE Design & Test of Computers const dw = 8; behavior even( in event clk, void main(chan (in) c4 : dw, chan (out) c0 : dw) in unsigned bit[1] rst, { in bit[31:0] Inport, int d0, d1, d2, d3; out bit[31:0] Outport, chan c1, c2, c3; in bit[1] Start, out bit[1] Done, void e0() { while (1) { c1 ? d0; c0 ! d0; } } out bit[31:0] idata, void e1() { while (1) { c2 ? d1; c1 ! d1; } } in bit[31:0] iocount, void e2() { while (1) { c3 ? d2; c2 ! d2; } } out bit[1] istart, void e3() { while (1) { c4 ? d3; c3 ! d3; } } in bit[1] idone, in bit[1] ack_istart, par { out bit[1] ack_idone) e0(); e1(); e2(); e3(); { } void main(void) { } bit[31:0] ocount; bit[31:0] mask; enum state { S0, S1, S2, S3 } state;
Figure 6. Four-place buffer in Handel-C. The ? and ! operators state = S0; are CSP-inspired receive and transmit operators. while (1) { wait(clk); if (rst == 1b) state = S0; Like Handel-C, Sharp’s Bach C is an ANSI C variant switch (state) { case S0: with explicit concurrency and rendezvous communi- Done = 0b; cation.14 However, Bach C only imposes sequencing istart = 0b; ack_idone = 0b; rather than assigning a particular number of cycles to if (Start == 1b) state = S1; each operation. Also, although it supports arrays, Bach else state = S0; break; C does not support pointers. case S1: Budiu and Goldstein’s CASH compiler is unique mask = 0x0001; idata = Inport; among the C synthesizers because it generates asyn- istart = 1b; chronous hardware.15 It accepts ANSI C, identifies if (ack_istart == 1b) instruction-level parallelism (ILP), and generates an state = S2; else state = S1; asynchronous dataflow circuit. break; Mentor Graphics’ recent (2004) Catapult C performs case S2: istart = 0b; behavioral synthesis from an ANSI C++ subset. Because ocount = iocount; it is a commercial product, details of its features and lim- if (idone == 1b) state = S3; else state = S2; itations are not publicly available. However, it appears break; to be a strict subset of ANSI C++ (that is, with few, if any, case S3: Outport = ocount & mask; language extensions). ack_idone = 1b; Done = 1b; Concurrency if (idone == 0) state = S0; else state = S3; The biggest difference between hardware and soft- break; ware is its execution model. Software follows a sequen- } } tial, memory-based execution model derived from } Turing machines, whereas hardware is fundamentally }; concurrent. Thus, sequential algorithms that are effi- cient in software are rarely the best choice in hardware. Figure 7. State machine in a synthesizable RTL This has serious implications for software programmers dialect of SpecC. The wait(clk) statement designing hardware—their familiar toolkit of algorithms denotes a clock cycle boundary. is suddenly far less useful. Why is so little software developed for parallel hard- ware? The plummeting cost of parallel hardware mental reason is that humans have difficulty conceiv- would make such software appear attractive, yet ing of parallel algorithms, and thus many more concurrent programming has had limited success sequential algorithms exist. Another problem is dis- compared with its sequential counterpart. One funda- agreement about the preferred parallel-programming
September–October 2006 379 Electronic System-Level Design
model (for example, shared memory versus message thereby forcing the programmer to expose most of the passing), as demonstrated by the panoply of parallel- concurrency. SystemC, BDL, and Ocapi all provide programming languages, none of which has emerged process-level parallel constructs. HardwareC, Handel- as a clear winner. C, SpecC, and Bach C additionally provide statement- Rather than exposing concurrency to the program- level parallel constructs. SystemC’s parallelism mer and encouraging the use of parallel algorithms, the resembles that of standard hardware description lan- more successful approach has been to automatically guages (HDLs) such as Verilog, in which a system is a expose parallelism in sequential code. Because C does collection of clock-edge-triggered processes. Hard- not naturally support user-specified concurrency, such wareC, Handel-C, SpecC, and Bach C’s approaches are a technique is virtually mandatory for synthesizing effi- more like software, providing constructs that dispatch cient hardware from plain C. Unfortunately, these tech- collections of instructions in parallel. niques are limited. The other approach lets the compiler identify paral- lelism. Although the languages that provide parallel Finding parallelism in sequential code constructs also identify some parallelism, Cones, There are three main approaches to exposing paral- Transmogrifier C, C2Verilog, Catapult C, and CASH rely lelism in sequential code, distinguished by their granu- on the compiler to expose all possible parallelism. The larity. Instruction-level parallelism (ILP) dispatches Cones compiler takes the most extreme approach, flat- groups of nearby instructions simultaneously. Although tening an entire C function with loops and conditionals this has become the preferred approach in the com- into a single two-level combinational function evaluat- puter architecture community, programmers recognize ed in parallel. The CASH compiler takes an approach that there are fundamental limits to the amount of ILP closer to compilers for VLIW processors, carefully exam- that can be exposed in typical programs.16 Adding hard- ining interinstruction dependencies and scheduling ware to approach these limits, usually through specu- instructions to maximize parallelism. None of these lation, results in diminishing returns. compilers attempts to identify process-level parallelism. The second approach, pipelining, requires less hard- Both approaches have drawbacks. The latter ware than ILP but can be less effective. A pipeline dis- approach places the burden on the compiler and there- patches instructions in sequence but overlaps fore limits the parallelism achievable with normal, them—the second instruction starts before the first com- sequential algorithms. Although carefully selecting eas- pletes. Like ILP, interinstruction dependencies and con- ily parallelized algorithms could mitigate this problem, trol-flow transfers tend to limit the maximum amount of such thinking is foreign to most software programmers achievable parallelism. Pipelines work well for regular and may be more difficult than thinking in an explicitly loops, such as those in scientific or signal-processing concurrent language. applications, but are less effective in general. The former approach, by adding parallel constructs The third approach, process-level parallelism, dis- to C, introduces a fundamental and far-reaching change patches multiple threads of control simultaneously. This to the language, again demanding substantially differ- approach can be more effective than finer-grained par- ent thinking by the programmer. Even for a programmer allelism, depending on the algorithm, but process-level experienced in concurrent programming with, say, parallelism is difficult to identify automatically. Hall et Posix threads, the parallel constructs in hardware-like al. attempt to invoke multiple iterations of outer loops languages differ greatly from the thread-and-shared- simultaneously,17 but unless the code is written to avoid memory concurrency model typical of software. dependencies, this technique might not be effective. A good hardware specification language must be Exposing process-level parallelism is thus usually the pro- able to express parallel algorithms, because they are the grammer’s responsibility. Such parallelism is usually con- most efficient for hardware. Its inherent sequentiality trolled through the operating system (for example, Posix and often undisciplined use of pointers make C a poor threads) or the language itself (for example, Java). choice for this purpose. Which concurrency model the next hardware design Approaches to concurrency language should employ remains an open question, but The C-to-hardware compilers considered here take the usual software model—asynchronously running either of two approaches to concurrency. The first threads communicating through shared memory—is approach adds parallel constructs to the language, clearly not the one.
380 IEEE Design & Test of Computers Timing for (i = 0 ; i < 8 ; i++) { The C language is mute on the subject of time. It a[i] = c[i]; b[i] = d[i] || f[i]; guarantees causality among most sequences of state- } ments but says nothing about the amount of time it takes to execute each sequence. This flexibility simpli- fies life for compilers and programmers alike but makes Figure 8. It is not clear how many cycles it should it difficult to achieve specific timing constraints. C’s take to execute this (contrived) loop written in C. compilation technique is transparent enough to make Cones does it in one (it is combinational), gross performance improvements easy to understand Transmogrifier-C chooses eight (one per and achieve, and differences in efficiency of sequential iteration), and Handel-C chooses 25 (one per algorithms is a well-studied problem. Nevertheless, assignment). Others, such as HardwareC, allow wringing another 5% speedup from an arbitrary piece the user to specify the number. of code can be difficult. Achieving a performance target is fundamental to hardware design. Miss a timing constraint by a few per- greater challenge to the compiler and is sometimes more centage points and the circuit will fail to operate or the subtle for the designer, but it allows flexibility that can product will fail to sell. Achieving a performance target lead to a better design. Bach C takes a similar approach. under power and cost constraints is usually the only rea- Like HardwareC, the C2Verilog compiler also inserts son to implement a particular function in hardware cycles using fairly complex rules and provides mecha- rather than using an off-the-shelf processor. Thus, an ade- nisms for imposing timing constraints. Unlike HardwareC, quate hardware specification technique needs mecha- however, these constraints are outside the language. nisms for specifying and achieving timing constraints. Transmogrifier C and Handel-C use fixed implicit This disparity leads to yet another fundamental ques- rules for inserting clocks. Handel-C’s are the simplest: tion in using C-like languages for hardware design: where Each assignment and delay statement takes one cycle; to put the clock cycles. Figure 8 shows a program frag- everything else executes in the same clock cycle. ment that is interpreted in at least three different ways by Transmogrifier C’s rules are nearly as simple: Each loop different compilers. Most of the compilers described here iteration and function call takes a cycle. Unfortunately, generate synchronous logic in which the clock cycle such simple rules can make it difficult to achieve a par- boundaries have been defined. There are only two ticular timing constraint. To speed up a Handel-C spec- exceptions: Cones and CASH. Cones only generates com- ification, assignment statements might require fusing, binational logic; CASH generates self-timed logic. and Transmogrifier C might require loops to be manu- Compilers use various techniques for inserting clock ally unrolled. cycle boundaries, which range from fully explicit to The ability to specify or constrain detailed timing fully implicit. Ocapi’s clocks are the most explicit. The in hardware is another fundamental requirement. designer specifies explicit state machines, and each Whereas slow software is an annoyance, slow hardware state gets a cycle. At some point in the SpecC refine- is a disaster. When something happens in hardware is ment flow, the state machines are also explicit, although usually as important as what happens. This is another clock boundaries might not be explicit earlier in the big philosophical difference between software and flow. The clocks in the Cones system are also explicit, hardware, and again hardware requires different skills. but in an odd way—because Cones generates only A good hardware specification language needs the combinational logic, clocks are implicit at function ability to specify detailed timing, both explicitly and boundaries. SystemC’s clock boundaries are also explic- through constraints, but should not demand the pro- it; as in Cones, the clock boundaries of combinational grammer to provide too many details. The best-effort processes are at the edges, and in sequential processes, model of software is inadequate by itself. explicit wait statements delay a prescribed number of cycles. BDL takes a similar approach. Types HardwareC lets the user specify clock constraints, an Data types are another central difference between approach common in high-level synthesis tools. For hardware and software languages. The most fundamen- example, the user can require that three particular state- tal type in hardware is a single bit traveling through a ments should execute in two cycles. This presents a memoryless wire. By contrast, each base type in C and
September–October 2006 381 Electronic System-Level Design
C++ is one or more bytes stored in memory. Although C’s mechanism is convenient for adding to or modifying the base types can be implemented in hardware, C has behavior of existing hardware. Incidentally, SystemC has almost no support for types smaller than a byte. (The one supported more high-level modeling constructs such as exception is that the number of bits for each field in a templates and more elaborate communication protocols struct can be specified explicitly. Oddly, none of these since version 2.0, but they are not typically synthesizable. languages even mimics this syntax.) As a result, straight A good HDL needs a rich type system that allows pre- C code can easily be interpreted as bloated hardware. cise definition of hardware types, but it should also Compilers take three approaches to introducing assist in ensuring program correctness. C++’s type sys- hardware types to C programs. The first, and perhaps tem is definitely an improvement over C’s in this regard. the purest, neither modifies nor augments C’s types but allows the compiler or designer to adjust the width of Communication the integer types outside the language. For example, the C-like languages are built on the very flexible RAM C2Verilog compiler provides a GUI that lets the user set communication model. They implicitly treat all memo- the width of each variable in the program. In ry locations as equally costly to access, but this is not Transmogrifier C, the user can set each integer’s width true in modern memory hierarchies. At any point, it can through a preprocessor pragma. take hundreds or even thousands of times longer to The second approach is to add hardware types to the access certain locations. Designers can often predict the C language. HardwareC, for instance, adds a Boolean behavior of these memories, specifically caches, and vector type. Handel-C, Bach C, and BDL add integers use them more efficiently. But doing so is very difficult, with an explicit width. SpecC adds all these types and and C-like languages provide scant support for it. many others that cannot be synthesized, such as pure Long, nondeterministic communication delays are events and simulated time. anathema in hardware. Timing predictability is manda- The third approach, used by C++-based languages, tory, so large, uniform-looking memory spaces are rarely is to provide hardware-like types through C++’s type sys- the primary communication mechanism. Instead, hard- tem. C++ supports a one-bit Boolean type by default, ware designers use various mechanisms, ranging from and its class mechanism makes it possible to add more simple wires to complex protocols, depending on the types, such as arbitrary-width integers, to the language. system’s needs. An important characteristic of this The SystemC libraries include variable-width integers approach is the need to understand a system’s com- and an extensive collection of types for fixed-point frac- munication channels and patterns before it is running tional numbers. Ocapi, because it is an algorithmic because communication channels must be hardwired. mechanism for generating structure, also effectively takes this approach, letting the user explicitly request The problem with pointers wires, buses, and so on. Catapult C presumably has a Communication patterns in software are often diffi- similar library of hardware-like types. cult to determine a priori because of the frequent use Each approach, however, is a fairly radical departure of pointers. These are memory addresses computed at from C’s call-it-an-integer-and-forget-about-it approach. runtime, and as such are often data dependent and can- Even the languages that support only C types compel a not be known completely before a system is running. user to provide each integer’s actual size. Worrying Implementing such behavior in hardware mandates, at about the width of each variable in a program is not least, small memory regions. something a typical C programmer does. Aliasing, when a single value can be accessed Compared with timing and concurrency, however, through multiple sources, is an even more serious prob- adding appropriate hardware types is a fairly easy prob- lem. Without a good understanding of when a variable lem to solve when adapting C to hardware. C++’s type sys- can be aliased, a hardware compiler must place that tem is flexible enough to accommodate hardware types, variable into a large, central memory, which is neces- and minor extensions to C suffice. A larger question, sarily slower than a small memory local to the compu- which none of the languages adequately addresses, is tational units that read and feed it. how to apply higher-level types such as classes and inter- One of C’s strengths is its flexible memory model, faces to hardware description. SystemC has some facili- which allows complicated pointer arithmetic and essen- ties for inheritance, but the inheritance mechanism is tially uncontrolled memory access. Although very use- simply the one used for software; it is not clear that this ful for system programs such as operating systems, these
382 IEEE Design & Test of Computers abilities make analyzing an arbitrary C program’s com- Languages that ignore C’s memory model don’t sup- munication patterns especially difficult. The problem is port arrays or pointers. Instead they look only at how so great, in fact, that software compilers often have an local variables communicate between statements. easier time analyzing a Fortran program than an equiv- Cones is the simplest; all variables, arrays included, are alent C program. interpreted as wires. HardwareC and Transmogrifier C Any technique that implements a C-like program in don’t support arrays or memories. Ocapi also falls into hardware must analyze the program to understand all this class, although arrays and pointers can assist during possible communication pathways; resort to large, slow system construction. BDL is perhaps the richest of this memories; or do some combination of the two. group, supporting multidimensional arrays, but it doesn’t Séméria, Sato, and De Micheli applied pointer analy- support pointers or dynamic memory allocation. sis algorithms from the software compiler literature to esti- Languages in the second group go to great lengths to mate the communication patterns of C programs for preserve C’s memory model. The CASH compiler takes hardware synthesis.18 Although this is an impressive body the most brute-force approach. It synthesizes one large of work, it illustrates the difficulty of the problem. Pointer memory and puts all variables and arrays into it. The analysis identifies the data to which each pointer can Handel-C and C2Verilog compilers can split memory into refer, allowing memory to be divided. Solving the point- multiple regions and assign each to a separate memory er analysis problem precisely is undecidable, so element. Handel-C adds explicit constructs to the lan- researchers use approximations. These are necessarily guage for specifying these elements. SystemC also sup- conservative and hence might miss opportunities to split ports explicit declaration of separate memory regions. memory regions, leading to higher-cost implementations. Other languages provide communication primitives Finally, pointer analysis is a costly algorithm with whose semantics differ greatly from C’s memory style of many variants. communication. HardwareC, Handel-C, and Bach C provide blocking, rendezvous-style (unbuffered) com- Communication costs munication primitives for communicating between con- Software’s event-oriented communication style is currently running processes. SpecC and later versions another key difference from hardware. Every bit of data of SystemC provide a large library of communication communicated among parts of a software program has primitives. a cost (that is, a read or write operation to registers or Again, the difference between appropriate software memory), and thus communication must be explicitly and hardware design is substantial. Software designers requested in software. Communicating the first bit is usually ignore memory access patterns. Although this very costly in hardware because it requires the addition can slow overall memory access speed, it is usually of a wire, but after that, communication is actually more acceptable. Good hardware design, in contrast, usual- costly to disable than to continue. ly starts with a block diagram detailing every commu- This difference leads to a different set of concerns. nication channel and attempts to minimize Good hardware communication design tries to mini- communication pathways. mize the number of pathways among parts of the So, software designers usually ignore the funda- design, whereas good software design minimizes the mental communication cost issues common in hard- number of transactions. For example, good software ware. Furthermore, automatically extracting efficient design avoids forwarding through copying, preferring communication structures from software is challenging instead to pass a reference to the data being forwarded. because of the pointer problem in C-like languages. This is a good strategy for hardware that stores large Although pointer analysis can help mitigate the prob- blocks of data in memory, but is rarely appropriate in lem, it is imprecise and cannot improve an algorithm other cases. Instead, good hardware design considers with poor communication patterns. alternate data encodings, such as serialization. A good hardware specification language should make it easy to specify efficient communication patterns. Communication approaches The languages considered here fall broadly into two Metadata groups: those that effectively ignore C’s memory model A high-level construct can be implemented in many and look only at communication through variables, and different ways. However, because hardware is at a far those that adopt the full C memory model. lower level than software, there are many more ways to
September–October 2006 383 Electronic System-Level Design
In software, there is little reason to have multiple imple- Table 2. The big challenges for hardware languages. mentations of the same algorithm, but it happens all the Challenge Comment time in hardware. Not surprisingly, C++ doesn’t support Concurrency model Specifying parallel algorithms this sort of thing. Specifying timing How many clock cycles? The languages considered here take two approach- Types Need bits and bit-precise vectors es to specifying such metadata. One group places it Communication patterns Need isolated memories within the program itself, hiding it in comments, prag- Hints and constraints How to implement something mas, or added constructs. The other group places it out- side the program, either in a text file or in a database populated by the user through a GUI. implement a particular C construct in hardware. For C has a standard way of supplying extra information example, consider an addition operation. A processor to the compiler: the #pragma directive. By definition, a probably has only one useful addition instruction, compiler ignores such lines unless it understands them. whereas in hardware there are a dizzying number of dif- Transmogrifier C uses the directive to specify integer ferent adder architectures—for example, ripple carry, width, and Bach C uses it to specify timing and mapping carry look-ahead, and carry save. constraints. HardwareC provides three language-level The translation process for hardware therefore has constructs: timing constraints, resource constraints, and more decisions to make than translation for software. arbitrary string-based attributes, whose semantics are Making many decisions correctly is difficult and compu- much like a C #pragma. BDL has similar constructs. tationally expensive. Furthermore, the right set of deci- SpecC takes the other approach; many tools for syn- sions varies with design constraints. For example, a thesizing and refining SpecC require the user to speci- designer might prefer a ripple-carry adder if area and fy, using a GUI, how to interpret various constructs. power are at a premium and speed is a minor concern, Constructs such as addition, which are low level in but a carry-look-ahead adder if speed is a greater concern. software, are effectively high level in hardware. Thus, Much effort has gone into improving optimization there must be a mechanism for conveying designer algorithms, but it remains unrealistic to expect all these intent to any hardware synthesis procedure, regardless decisions to be automated. Instead, designers need of the source language. A good hardware specification mechanisms that let them ask for exactly what they language needs a way of guiding the synthesis proce- want. Such designer guidance takes two forms: manu- dure to select among different implementations, trad- al rewriting of high-level constructs into the desired ing off between, say, power and speed. lower-level ones (for example, replacing a “+” operator with a collection of gates that implement a carry-look- ahead adder) or annotations such as constraints or hints WHY BOTHER generating hardware from C? It is clearly about how to implement a particular construct. Both not necessary, because there are many excellent proces- are common RTL design approaches. Designers rou- sors and software compilers, which are certainly the tinely specify complex data paths at the gate level cheapest and easiest way to run a C program. So why instead of using higher-level constructs. Constraint infor- consider using hardware? Efficiency is the logical answer. mation, often supplied in an auxiliary file, usually drives Although general-purpose processors get the job done, logic optimization algorithms. well-designed customized hardware can always do it Although it might seem possible to use C++’s opera- faster, using fewer transistors and less energy. Thus, the tor-overloading mechanism to specify, for example, utility of any hardware synthesis procedure depends on when a carry-look-ahead adder should implement an how well it produces efficient hardware specialized for addition, using this mechanism is probably very diffi- an application. Table 2 summarizes the key challenges cult. C++’s overloading mechanism uses argument types of a successful hardware specification language. to resolve ambiguities, which is natural when you want Concurrency is fundamental for efficient hardware, to treat different data types differently. But the choice but C-like languages impose sequential semantics and of algorithm in hardware is usually driven by resource require the use of sequential algorithms. Automatically constraints (such as area or delay) rather than data rep- exposing concurrency in sequential programs is limit- resentation (although, of course, data representation ed in effectiveness, so a successful language requires does matter). Concurrency is the fundamental problem. explicit concurrency, something missing from most
384 IEEE Design & Test of Computers C-like languages. Adding such a construct is easy, but of these languages addresses. This ability appears nec- teaching software programmers to use concurrent algo- essary to raise designer productivity to the level need- rithms is difficult. ed for the next generation of chips. Careful timing design is also required for efficient Looming over all these issues, however, is verification. hardware, but C-like languages provide essentially no What we really need are languages that let us create cor- control over timing, so the language needs added tim- rect systems faster by making it easier to check for, iden- ing control. The problem amounts to where to put the tify, and correct mistakes. Raising the abstraction level clock cycles, and the languages offer a variety of solu- and facilitating efficient simulation are two well-known tions, both implicit and explicit. The bigger problem, ways to achieve this, but are there others? ■ though, is changing programmer habits to consider such timing details. Acknowledgments Using software-like types is also a problem in hard- Edwards is supported by the National Science ware, which wants to manipulate individual bits for effi- Foundation, Intel, Altera, the SRC, and New York ciency. The problem is easier to solve for C-like State’s NYSTAR program. languages. Some languages add the ability to specify the number of bits used for each integer, for example, References and C++’s flexible type system allows hardware types to 1. Handel-C Language Reference Manual, RM-1003-4.0, be defined. The type problem is the easiest to address. Celoxica, 2003. Communication also presents a challenge. C’s flexi- 2. K. Wakabayashi and T. Okamoto, “C-Based SoC Design ble global-memory communication model is not effi- Flow and EDA Tools: An ASIC and System Vendor Per- cient for hardware. Instead, memory should be broken spective,” IEEE Trans. Computer-Aided Design of Inte- into smaller regions, often as small as a single variable. grated Circuits and Systems, vol. 19, no. 12, Dec. 2000, Compilers can do so to a limited degree, but efficiency pp. 1507-1522. often demands explicit control over this. A fundamen- 3. D.M. Ritchie, “The Development of the C Language,” tal problem, again, is that C programmers generally History of Programming Languages-II, T.J. Bergin Jr. don’t worry about memory, and C programs are rarely and R.J. Gibson Jr., eds., ACM Press and Addison-Wes- written with memory behavior in mind. ley, 1996. A high-level HDL must let the designer provide con- 4. G. De Micheli, “Hardware Synthesis from C/C++ straints or hints to the synthesis system because of the Models,” Proc. Design, Automation and Test in Europe wide semantic gap between a C program and efficient (DATE 99), IEEE Press, 1999, pp. 382-383. hardware. There are many ways to implement a con- 5. C.E. Stroud, R.R. Munoz, and D.A. Pierce, “Behavioral struct such as addition in hardware, so the synthesis sys- Model Synthesis with Cones,” IEEE Design & Test, vol. tem needs a way to select an implementation. 5, no. 3, July 1988, pp. 22-30. Constraints and hints are the two main ways to control 6. D.C. Ku and G. De Micheli, HardwareC: A Language for the algorithm, but standard C has no such facility. Hardware Design, Version 2.0, tech. report CSTL-TR- Although presenting designers with a higher level of 90-419, Computer Systems Lab, Stanford Univ., 1990. abstraction is obviously desirable, presenting them with 7. G. De Micheli et al., “The Olympus Synthesis System,” an inappropriate level of abstraction—one in which IEEE Design & Test, vol. 7, no. 5, Oct. 1990, pp. 37-53. they cannot effectively ask for what they want—is not 8. D. Galloway, “The Transmogrifier C Hardware Descrip- much help. Unfortunately, C-like languages, because tion Language and Compiler for FPGAs,” Proc. Symp. they provide abstractions geared toward the generation FPGAs for Custom Computing Machines (FCCM 95), of efficient software, do not naturally lend themselves IEEE Press, 1995, pp. 136-144. to the synthesis of efficient hardware. 9. T. Grötker et al., System Design with SystemC, Kluwer The next great hardware specification language Academic Publishers, 2002. won’t closely resemble C or any other familiar software 10. P. Schaumont et al., “A Programming Environment for language. Software languages work well only for soft- the Design of Complex High Speed ASICs,” Proc. 35th ware, and a hardware language that does not produce Design Automation Conf. (DAC 98), ACM Press, 1998, efficient hardware is of little use. Another important pp. 315-320. issue will be the language’s ability to build systems from 11. Y. Panchul, D.A. Soderman, and D.R. Coleman, System existing pieces (known as IP-based design), which none for Converting Hardware Designs in High-Level
September–October 2006 385 Electronic System-Level Design
Programming Language to Hardware Implementations, Structures,” IEEE Trans. Very Large Scale Integration US patent 6,226,776, Patent and Trademark Office, (VLSI) Systems, vol. 9, no. 6, Dec. 2001, pp. 743-756. 2001. 12. D.D. Gajski et al., SpecC: Specification Language and Methodology, Kluwer Academic Publishers, 2000. Stephen A. Edwards is an associ- 13. R. Dömer, A. Gerstlauer, and D. Gajski, SpecC ate professor in the Computer Science Language Reference Manual, Version 2.0, SpecC Con- Department of Columbia University. sortium, 2001. His research interests include embed- 14. T. Kambe et al., “A C-Based Synthesis System, Bach, ded-system design, domain-specific and Its Application,” Proc. Asia South Pacific Design languages, and compilers. Edwards has a BS from the Automation Conf. (ASP-DAC 01), ACM Press, 2001, pp. California Institute of Technology and an MS and a 151-155. PhD from the University of California, Berkeley, all in 15. M. Budiu and S.C. Goldstein, “Compiling Application- electrical engineering. He is an associate editor of Specific Hardware,” Proc. 12th Int’l Conf. Field-Program- IEEE Transactions on Computer-Aided Design of Inte- mable Logic and Applications (FPL 02), LNCS 2438, grated Circuits and Systems. He is a senior member Springer-Verlag, 2002, pp. 853-863. of the IEEE. 16. D.W. Wall, “Limits of Instruction-Level Parallelism,” Proc. 4th Int’l Conf. Architectural Support for Programming Lan- Direct questions and comments about this article guages and Operating Systems (ASPLOS 91), Sigplan to Stephen A. Edwards, Dept. of Computer Science, Notices, vol. 26, no. 4, ACM Press, 1991, pp. 176-189. Columbia University, 1214 Amsterdam Ave. MC 0401, 17. M.W. Hall et al., “Detecting Coarse-Grain Parallelism New York, NY 10027; [email protected]. Using an Interprocedural Parallelizing Compiler,” Proc. Supercomputing Conf., IEEE Press, p. 49. For further information on this or any other computing 18. L. Séméria, K. Sato, and G. De Micheli, “Synthesis of topic, visit our Digital Library at http://www.computer.org/ Hardware Models in C with Pointers and Complex Data publications/dlib.
ADVERTISER INDEX SEPTEMBER/OCTOBER 2006
FUTURE ISSUE: Advertising Personnel Marion Delaney Sandy Brown IEEE Media, Advertising Director IEEE Computer Society, November-December 2006 Phone: +1 415 863 4717 Business Development Manager Email: [email protected] Phone: +1 714 821 8380 Process Variation and Stochastic Fax: +1 714 821 4010 Email: [email protected] Marian Anderson Design and Test Advertising Coordinator Phone: +1 714 821 8380 Advertising close date: 01 October 06 Fax: +1 714 821 4010 Email: [email protected]
Advertising Sales Representatives
Product Display New England (recruitment) Midwest/Southwest (recruitment) Japan (recruitment) John Restchack John Restchack Darcy Giovingo Tim Matteson Phone: +1 212 419 7578 Phone: +1 212 419 7578 Phone: +1 847 498-4520 Phone: +1 310 836 4064 Fax: +1 212 419 7589 Fax: +1 212 419 7589 Fax: +1 847 498-5911 Fax: +1 310 836 4067 Email: [email protected] Email: [email protected] Email: [email protected] Email: [email protected]
Northwest/Southern CA (recruitment) Europe (recuirtment) Southeast (recruitment) Tim Matteson Hilary Turnbull Recruitment Display Thomas M. Flynn Phone: +1 310 836 4064 Phone: +44 1875 825700 Mid Atlantic (recruitment) Phone: +1 770 645 2944 Fax: +1 310 836 4067 Fax: +44 1875 825701 Dawn Becker Fax: +1 770 993 4423 Email: [email protected] Email: [email protected] Phone: +1 732 772 0160 Email: [email protected] Fax: +1 732 772 0164 Email: [email protected]
IEEE Design & Test of Computers