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
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
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 significantbenefits of SystemC hardware design.