BSV by Example - Computation Structures Group

For speed, one starts with the native speed of compiled C++. Software virtual platforms use sophisticated
technology like just-in-time cross-compilation to deliver impressive execution speeds,
for example booting an entire guest operating system in seconds. TLM models avoid the overheads
of event-driven simulation (by sticking to SC METHOD and avoiding SC THREAD and
SC CTHREAD). If they must use events, they play tricks like “temporal decoupling” to amortize
the overhead.
While all these tricks are laudable (and perhaps adequate for some modeling purposes), unfortunately
performance drops steeply as one adds almost any architectural detail, such as actual
parallelism, interconnect contention, memory or I/O bottlenecks, cycle-accurate device models, and
so on. Performance also drops steeply when one adds any instrumentation at all (which is necessary
for performance modeling). Further, since the basic substrate is C++, it is extraordinarily difficult
to achieve any speed up by exploiting multi-core hosts.
In summary, as you add architectural detail (for accuracy), you lose speed. Development time
increases sharply, as programmers contort the code to apply tricks to restore speed.
One attempted solution is to use FPGA-based execution for the architecturally detailed component(s)
of the system model. This is still a problem because of the logistical difficulties of dealing
with multiple languages and paradigms for different components, because the software side may still
run too slowly, because bandwidth constraints in communicating between the software and FPGA
sides may anyway limit speed, and because of limited visibility into the FPGA-side components. Further,
conventional approaches have problems in creating the FPGA-side components (see synthesis
discussion below).
High-Level Synthesis (HLS) from C++ and SystemC is often held out by many in the industry as
a potential way forward. Unfortunately there are serious problems in using C++ and SystemC as a
starting point. A central issue is architecture, architecture, architecture.
It is well understood that the key to high-performance software is good algorithms. Further, good
algorithms are designed by people with training and experience, and not by tools (a compiler only
optimizes an algorithm we write, it doesn’t improve the algorithm itself). Similarly, the key to highperformance
hardware (measured as area, speed, power) is good architecture. Hence, it is crucial to
give designers the maximum power to express architecture; all the rest can be left to tools.
Unfortunately, HLS from C++ does exactly the opposite—it obscures architecture. These HLS tools
try to choose an architecture based on internal heuristics. Designers have indirect, second-order
controls on this activity, expressed as “constraints” such as bill-of-materials limits for hardware
resources and pragmas for loop transformations (unrolling, peeling, fusion, etc.). It is hard (and
often involves guesswork) to “steer” these tools towards a good architecture.
HLS from C++ has another serious limitation. It is fundamentally an exercise in “automatic parallelization”,
i.e., in automatically transforming a sequential program into a parallel implementation.
This problem has been well-studied since the days of the earliest vector supercomputers like the
CDC 6600 and Cray 1, and works (and even then, only moderately) for “loop-and-array” codes.
This is because the key technologies needed for automatic parallelization, namely dependence analysis,
alias analysis, etc., on the CDFG (Control/Data Flow Graph) have been shown to be feasible
only for simple loops, often statically bounded, working on arrays with simple (affine, linear) combinations
of loop indexes. Such loop-and-array computations of course exist in a few components
in an SoC, notably the signal-processing ones, but are absent in the majority of the SoC, which are
more “control-oriented” (processors, memory systems, interconnects, DMAs and data movers, I/O
peripherals, etc.). Even in the DSP space, note that modern DSP algorithms are also becoming
more control-oriented in order to become more adaptive to noise (for signal processing) and actual
content (for audio and video codecs).
Finally, HLS from C++ has yet another serious limitation. It is well known that, for the same computation,
one may choose different algorithms depending on the computation model and associated
cost model of the platform. This is why there are entire textbooks on parallel algorithms—they
12