It is amazing, at times, how much disinformation there appears to be. Sometimes this disinformation is created by the EDA companies themselves, because they are trying to smooth over deficiencies in their tools. Sometimes disinformation manifests itself just because of how the industry moves over time. And sometimes we run into disinformation issues simply because things are not obvious.
In order to address this problem, in this column I want to go back to something very fundamental, which is to look at the languages that are being used as the input to transaction-level synthesis. Later, I hope to progress to some more "meaty stuff" related to pipelines and scheduling.
As far as I am aware, C, C++, SystemC, Bluespec (both variants as discussed below), and Simulink (even a graphical language is a language) comprise the complete set of languages being used as the input to transaction-level synthesis on the market today. I want to start by first dealing with some issues surrounding the C, C++, SystemC spectrum, because there is a lot of confusion as to which is “higher level” than the other. The problem is that there are two ways to look at the issue, and these two ways will lead you to come to two different conclusions.
First, let's consider the diagram shown above. This says that the C language is quite capable of defining everything necessary at the block level, but descriptions written in C are not highly reusable or adaptable to different usage scenarios.
Next we have C++, which has become the language of choice for most software developers, not because it has any capabilities that are not present in C, but because it makes things so much easier. It enhances productivity and enhances reuse.
Now consider SystemC. This has nothing that cannot be described in C++; in fact, SystemC is nothing more than a C++ library. It does not extend the language in any way, and thus there is nothing that can be written in SystemC that could not be written in C++ or C. What SystemC adds are things that extend C++’s utility for defining things found in the hardware world in ways that make it more productive to use.
SystemC also provides other capabilities that enable it to fit into a hardware development flow. That means that SystemC is capable of defining system-level tasks -- composed of both hardware and software -- better than C++, and it is definitely better at describing hardware-only tasks. So, I ask you at this stage, which language is at a higher level of abstraction? It would appear that SystemC can more usefully be used for describing system-level behavior, whereas C is less suitable.
Next page >