I have heard or read the question 'Why not SystemC?' often enough, and maybe you have also been asking yourself the same question when you discovered new Domain-Specific Languages (DSLs) for hardware design, such as our own language called Cx. Another phrase that often follows is "But your language is not a standard, contrary to SystemC!" (this could be a sign that you're not talking to an early adopter, but rather to somebody who is placed later on the technology adoption lifecycle). Many researchers, designers, engineers have been saying for years that SystemC was not the answer, this post is dedicated to them :-)
So what is SystemC? It is a standard C++-based framework (templates + classes) that allows engineers to model their system, simulate it, do architectural exploration (= answer the question how should the system be partitioned in hardware and software?). It includes Transaction-Level Modeling capabilities, so you can model buses, DMAs, etc. and see what works best for your system. SystemC has numerous advantages: it works well, it has been developed by big companies for years and therefore is supported by many large vendors, it is open-source, etc. Many EDA vendors doing HLS support SystemC, so it could be proof that it is, in fact, made for hardware design; that, or SystemC is about as interesting as HLS for whole chip design (among other things, that article by Kevin Morris explains why HLS has been pretty much abandoned except for your basic data-oriented loop-and-array DSP algorithm).
First things first, SystemC is not a hardware description language. Quoting from the standard IEEE 1666-2011 (section 1.2 Purpose):
The general purpose of this standard is to provide a C++-based standard for designers and architects who need to address complex systems that are a hybrid between hardware and software.
Using SystemC to design a hardware-only system is like using a hammer to open a can (with the help of a chisel in that case), that's the law of the instrument by Abraham Maslow:
I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
It might work, it will simply require much more effort than if you used the right tool though :mrgreen:
Regardless, so what if you decide to use SystemC to design hardware? What's wrong with it, from a technical point of view?
- it is based on C++. The problem is that C++ (like C) was made for software, which is why SystemC has to use templates (e.g. scint and scuint) in conjunction with operator overloading to provide the bit-accurate computations available in any Hardware Description Language (HDL). It mostly succeeds in my opinion, except with the poor choice of having different classes depending on if you want numbers smaller or bigger than 64 bits :D The problem is that the price to pay is huge, because one has to be able to parse and analyze C++, a very complex task in itself. Or one should develop a SystemC compiler only, understanding only SystemC-compatible code (of course then what would be the point of making SystemC C++-based?).
- SystemC shares the biggest disadvantages of HDLs. Because it was created with simulation in mind, there is no guarantee that a SystemC program can be synthesized. Funnily enough, this led to the definition of a Synthesizable Subset, akin the infamous coding styles used in RTL design. And just like HDLs, the fact that it was created for modeling and simulation, does not mean that simulation is faster: because SystemC is mostly a template system, the model and the implementation are heavily correlated. SystemC uses fibers (lightweight threads) internally, which are much slower than fiber-less execution due to context switches.
- Low-level SystemC is still RTL. On every synchronous task, designers still have to say that they want a rising-edge clock sensitive process. They still have to write reset behavior, declare signals, and think about whether they will describe the datapath and the control of their FSM in separate processes or not. It is even possible to describe gate-level behavior with SystemC :shock: The language does not improve the description of connections between modules compared with VHDL/Verilog: it is still tedious, and looks more like spaghetti code than ever.
- HLS of behavioral SystemC is a dead-end. High-Level Synthesis has fundamental limitations when it comes to analyzing sequential code and extracting parallelism out of it. If you write anything more complex than a loop with fixed bounds working on data with simple dependencies (so-called 'loop-and-array' code), things start to get ugly. If you use pointers and dynamic memory allocation (something very frequent in C/C++), your code will be useless for HLS. What you end up doing is writing some code in a way that is acceptable for HLS (with the appropriate directives/constraints so that the tool behaves itself), and then for the rest resort to RTL SystemC :-|
- Developing with SystemC is hard. When you develop any kind of system, the earlier you discover errors, the better. But remember, SystemC is just a messy layer on top of C++, so in this context 'error checking' consists of compile-time error checking (at the C++ level) and runtime error checking. Besides being slow to compile (explanations why on StackOverflow and DrDobbs), C++ has notoriously horrible error messages (for a good laugh check out the FQA). When you make a (compile-time) error in SystemC, you get a C++-level error message. And when your mistake concerns elaboration (for instance you connected two connections to a single input by mistake), you will only discover it at runtime... All of this probably does not apply if you are using a SystemC-dedicated environment, but then once again in that case why use SystemC at all, rather than a true standalone language that does not suffer from any of C++ weaknesses?
As I said at the beginning, if you use SystemC to model/simulate mixed hardware/software systems, it is perfectly fine! What I mention here are only problems if you design hardware with SystemC, and if you do, good luck to you!