The “language war” in high-level system (HLS) design has been waging for a while now. You’ve probably read a lot of online publications touting the advantages of using SystemC over ANSI C to design at an abstract level. If you were to take what everyone is saying and boil it down to a few key points, they might sound something like this:
- ANSI C is a sequential language.
- ANSI C cannot execute two subroutines or functions concurrently.
- ANSI C executes your code in a single flow, one line after another.
- ANSI C-based HLS tools either limit themselves to single-block designs or provide a proprietary mechanism to mimic concurrency.
- ANSI C HLS tools don’t give you a way to accurately simulate what a real piece of hardware does.
- SystemC, on the other hand, is a standardized superset of C++ that supports multiple concurrent processes.
- SystemC supports hierarchy and modules.
- SystemC allows communication between those modules at the transaction or pin level.
- SystemC gives hardware designers the ability to tackle the very complex design and interface tasks they face every day.
Notice first I said “superset of C++” instead of “language.” That’s because SystemC is indeed not a language: it’s a family of C++ classes specifically geared toward hardware design constructs like modules, ports, concurrency, clocks, resets and channels.
The list above is short, but to see what far-reaching consequences these points have for hardware designers, consider the following:
Let’s say you use an ANSI C tool that can only work with single blocks. If you have a multiple block system, you can produce each block one at a time. But there’s a catch: how do you verify that system? According to the tool, that’s your problem. It’s up to you to somehow stitch these blocks together in RTL and do all the verification in RTL.
If you use an ANSI C tool that mimics concurrent simulation using proprietary libraries or other non-standard techniques, you are locked into that proprietary flow. Want to drive yourself crazy? Just try using this flow to create some IP cells and distribute them to your customers. Those customers will have to use (and own) the same tool just to run a simulation.
The proprietary library approach also takes liberties to get your ANSI C code to act like real hardware. To emulate the dataflow of your design they will typically have you partition the design so each block is a subroutine, and require you to call proprietary APIs inside the subroutines to manage that dataflow. One common approach is to have you conditionally execute the algorithms inside the subroutines depending on the availability of data reported by these API calls.
Sound messy? It is. And when you consider that it takes an API call (also proprietary) to determine if there is data in the channel, then you start to understand how these libraries are rudimentary static simulators at best.
If you have a fairly simple design that has a sequential algorithm, can be controlled by a single finite state machine, processes the same number of inputs and outputs every cycle, and uses a limited set of interfaces to communicate, then ANSI C may work fine for you. But the truth is that real projects aren’t that simple. Complex designs have multiple processes operating concurrently, they communicate with things like external memories and they send data through interfaces that must be customizable.
If you use the SystemC classes for HLS design, you have a real built-in, event-driven simulator to support your verification efforts. SystemC supports multiple modules that can execute concurrently, can share data in memories, and can synchronize their execution using real signal-level protocols. In other words, it allows you to attack the biggest design problems by breaking them down into multiple blocks and connecting them with channels that follow a protocol.
And with SystemC, you can easily simulate these blocks together to make sure everything is working correctly.
Can you do all this with ANSI C? You could, but how much time are you willing to spend writing the specialized hardware classes that already exist with SystemC?
There’s a lot more I could say about this, but I’ll let someone else do it for me. John Sanguinetti, Forte’s CTO, just published this article in EETimes’ EDA DesignLine that takes another look at the verification angle.
Next time, I’ll take a little deeper look into another important advantage of SystemC in HLS design: its support of structural hierarchy.
