SystemC: It's Neither Complicated Nor Belligerent!

I was recently talking to a customer who was looking to move up in abstraction from RTL to SystemC for all the usual good reasons (increased verification productivity, broader micro-architecture exploration, easier re-use, etc). However he was concerned that the learning curve for his team would be too high. He specifically referenced an article by one of our competitors that positioned SystemC as something different from C++ (and according to the article was apparently once at war with it), and then went on to describe all the nuances associated with the choice of which elements of the design to model in which "language."

Having recently come from the RTL world myself, I understand the customer's concerns. He knew how to get his design done using RTL. Now he was going to have to learn multiple languages, figure out where to apply each, and presumably use different paths to get through verification and synthesis.

If you're designing a real chip, you don't have time for that.

Let's see if we can simplify a bit: C++ is a superset of C. SystemC is a superset of C++.

A little more detail:

• C++ adds pre-built constructs like classes, objects, and templates to the base C language to make it more re-usable.
• SystemC adds pre-built constructs like hierarchy, ports, concurrency, transaction-level queues, signals, and fixed point datatypes to make it easier to use C++ for hardware design.

This is nice because if you have the tools to properly support SystemC, then you can connect algorithm/system design directly to production hardware design, and move most of the verification and micro-architecture exploration to a higher level of abstraction.

So if you're designing a (insert your design here....really, it works for any type), you would first develop the algorithm and test its effectiveness, throughput, etc. using C/C++. Once you are satisfied with that, you then use the SystemC constructs to provide further detail as to how this algorithm would map to hardware. This means the dataflow architecture and associated control logic, the memory architecture, the communication protocols, and so on. However you do not need to allocate logic to clock cycles, model state machines, model resource sharing, or other implementation details. The high-level synthesis tool will take care of that. Yes, the interfaces should be cycle-accurate (that's a blog post for another day). But the point is that the whole thing is designed in high-abstraction SystemC, verified in SystemC using existing verification methodologies, and synthesized together down to RTL according to the goals of the target application and the capabilities of the process library.

If you want a bit more explanation, I suggest you check out Mark Warren's webinar from back in December:

Practical application of high-level synthesis in SoC designs

Mark does a great job explaining things in terms hardware designers can relate to. And we can start diving down in to some more details in this space.

But to start with, don't be overwhelmed. Yes, the old C-based and HLS tools required a lot of methodology overhead, but the modern tools like C-to-Silicon and Incisive verification are finally unlocking the significant benefits of SystemC hardware design.

Jack Erickson