Unfortunately, hardware-accurate modeling and synthesis to hardware are problematic in SystemC and, with its current approach, are likely to remain so. The root cause is the model of computation — threads and events.

First, as eloquently argued by Lee and Ousterhout (in [L1] and [01]), the thread model is very difficult to use for any serious concurrent programming, and hardware systems have complex concurrency. Second, threads and events are so far removed from hardware that hardware-accuracy is difficult, and synthesis intractable, unless the design is written essentially as RTL. Behavioral synthesis is often cited as a solution, but its current incarnation only works for applications with loop-and-array scientific/technical algorithms, and leaves untouched the majority of hardware blocks, which have heterogeneous and irregular structures with complex control.

What ESL needs is a bridging model of hardware, rather than threads and events. A bridging model raises the level of abstraction while retaining the fundamental essence of hardware: fine-grain parallel state transitions on fixed circuit structures organized into a module hierarchy. This will allow architects and designers to work at a high level while retaining a sense of predictability and control in the structures they design. An implementation of such a bridging model exists in Bluespec SystemVerilog (BSV) — and, the recently introduced ESL Synthesis Extensions (ESE) to SystemC address this need for SystemC.

Rules and atomic transactions

Consider the block diagram below. The hardware represented by thread1 inserts an item x into table A whenever some condition cond1 is true. Similarly, thread2 removes an item y from table A, transforms it using into z using combinational function f() and inserts z into table B whenever cond2 is true. Thread3 removes an item w from table B whenever cond3 is true.

Suppose table A is a shared resource that can only be accessed once in any particular cycle; we specify that thread1 has priority over thread2 if cond1 and cond2 are simultaneously true. Similarly, thread2 has priority over thread3 for access to table B.

The behavior is expressed in the following SystemC code:

Updates to state elements (the tables) are controlled not only by the conditions in the spec, but also by terms that arbitrate access to the shared resources, since accesses are scheduled. For example, thread2’s actions require not only the spec condition cond2 but also the scheduling condition !cond1 (by being in the first “else” clause).

Similarly, thread3’s action not only requires the specified cond3, but also that either cond2 is false (meaning thread2 won’t contend on table B) or cond1 is true (meaning thread2 won’t contend even if cond2 is true, because thread1 has priority over thread2). Note that scheduling conditions have a non-local, transitive effect — thread3 is affected by thread1’s condition cond1, even though they do not directly share any resources, because of the intervening thread2.

Synthesizability introduces further complication. Synthesizable subsets usually require that code is organized in a state centric fashion. Each state element must be updated in only one process, and all the updates to a state element must be collected in an if-then-else or case statement. To collect updates to table B in a single if-then-else, the code becomes: