In my last post I briefly mentioned that when designing
hardware with SystemC, you do not need to allocate logic to register
boundaries. And I said that was a blog post for another day.
The first step is to separate the core
functionality of the block from the way it interfaces to the system. So if you
were designing an MPEG decoder, the decoding algorithm would be the core
functionality. If it used AXI to communicate with the system, the AXI
protocol would be the interface.
You can then describe the core using purely "untimed" SystemC.
This is nice because you can focus on describing and verifying the algorithm
itself, not worrying about how it will be implemented to meet the spec of a
particular application. If you want to add some wait() statements to represent
where you know you will need latency, that's fine. But you don't need to
distribute them across logic, you can just stack them. That would be a
The interface to the system in most cases is dependent on
protocol timing. So the interface would be cycle-accurate SystemC. Yes, being
cycle-accurate means that simulation will run more slowly than if it were
purely untimed, but you need that amount of timing fidelity to cover a large
swath of your verification plan (you do start every project with a vPlan, don't
you?). This SystemC model still runs
significantly faster than verifying interfaces at the RT Level, but for another
order of magnitude speedup, you can swap out the cycle-accurate interface to
use a Transaction-Level Model (TLM).
TLM basically abstracts the signal-level details of a
communication protocol into a function call. This function call specifies the attributes of
a payload -- the command, address, data, enables, etc. So instead of having to
wiggle individual signals in the proper order, you just issue a function call
to, say, read data. Using this more abstracted version simplifies design, speeds
verification runs, and perhaps most importantly makes debugging waveforms much
During synthesis, this TLM model gets refined to its
corresponding signal-level model. The
advantage of SystemC as a language is that you have complete flexibility to
quickly and accurately describe any complex protocol. For commonly used bus protocols such as AXI
or OCP, you can simply plug and play from a pre-verified TLM library.
Back to my previous post -- the nice thing about all this is
that it is all contained in SystemC, and provided you write synthesizable
SystemC, it can all be synthesized by a single tool like C-to-Silicon Compiler.
So here is a case where we are partitioning the design, but this is to enable
portability by separating the computation from the communication. You could
describe everything in one module, but that would limit where you could use
your core. And in any case, it is all one language, one synthesis flow.
What exactly is
synthesizable SystemC? I think that will be my next topic.