More on System-C

Some weeks ago, I published a posting from my colleague Richard Vlamynck, who was explaining the ideas behind System-C and modeling at different levels of abstraction. He promised to write more and I was very pleased to receive a new contribution …

It’s just me again, blogging about hardware models in general and System-C in particular.

Earlier, I’d mentioned the fact that System-C can be used to produce real hardware if desired and Mike commented that System-C was even more useful when used to produce test models of hardware.

So, what’s the difference? Let’s take a look.

Well, it’s a lot of work to use System-C as the starting point to create actual working silicon, but it’s almost easy to use System-C to create a accurate functional model of how the silicon would behave. So, while there’s just as much work to use System-C or Handel-C or Verilog or VHDL to build silicon chips, there is a lot less work to use System-C to build highly useful models of what is destined to be your custom chip.

Some year in the last millennium, I was working on the first color laser printer for some big company in silicon valley and we needed to experiment with different hardware models. We had a brilliant hardware design team and every two weeks we received a new motherboard for the new laser printer. Some times we would get a motherboard with one CPU and sometimes we would get a motherboard with dual CPU’s. We could run imaging processes on one CPU and we could run I/O processes on the other CPU. (see photo)

That is to say that our modeling technology was to build prototype motherboards and actually run the printer control language software (postscript and hpl) on all the different prototypes.

Then out of those dark ages of 1992 we emerge into the present era where we can build virtual prototypes using System-C instead of fabricating a new motherboard every time we have a better idea for resources or interconnect.

What if I had some way to experiment with hardware and software interaction with power and timing but I did not have to keep building actual hardware?

Is it possible for a software engineer to build a reasonably accurate model of hardware by simply referring to the datasheet for some arbitrary hardware device?

The answer is yes. System-C is currently the best bridge between the hardware and software worlds.

At one of our customer sites, they struggled to find engineers who could develop SystemC models. Their hardware engineers did not know C/C++. So, they assigned model development to embedded software engineers. I was quite skeptical at first, but have been proved wrong. They have taken to it quite well, and are happily converting datasheets into SystemC models, with occasional help from hardware engineers who can look at the VHDL to detail behavior not clear in the datasheet.

So now I might have you thinking that you’ll just get a datasheet for a simple piece of hardware like a uart or an ethernet or an APB peripheral, and then use System-C to create a model. It’s that easy, isn’t it? The answer is yes and no.

Without some SystemC tool, or infrastructure, writing such a model from scratch would not be simple. We haven’t talked about the SystemC interfaces, and this makes the task a little more complex. As with all other languages, System-C is easy to get started with, but requires diligence to master.

So now you’re saying, “Master SystemC and create models within my product schedule, certainly not!”

The good news is that SystemC has broad support for simulation and much of the original constructs now form the basis of its modern day use. Current day use has been refined over the years to a higher level of abstraction than its original use. In addition to that, one can create (or dare I say “purchase”), standard use templates.

That is, on top of the original SystemC usage is the newer SystemC constructs (for the initiated I mean TLM 2.0), and on top of that the user may add or obtain some additional layers of code to further simplify what the end user must do. Given all this, the user can now focus on just the core functionality of the model they wish to create; e.g.

• What hardware ports are there for the model to connect to other models. That is how many buses must it connect to, are there interrupt signals (and I don’t mean what are the details of the bus, just is there a bus)?
• What are the registers in the model, what do they do? (I don’t think I’ve lost anyone here…)
• What processes must be done in the model? You might think of these as RTOS tasks whose behavior is based on the state of the registers.
• And of course the needed data structures, state machines, etc. that go into the tasks that make up the model.

What about all that other messy hardware stuff like clocks, and flip-flops, and gates, and control signals, and on and on? It’s lost in the abstraction!

This is really the new news, that the functionality you think about when interacting with a hardware block is just that information needed to describe it! All that other hardware stuff is needed to “implement” the hardware. All that stuff is a necessary evil to get it to work, its not why its built.

For modern day models, we need to only focus on why the model was built, not how it was built.

There are a couple different types of timing models, you can make a loosely timed model or you can make an approximately timed model. That sounds almost the same doesn’t it, but there’s a difference.

In a future blog, we can talk about timing models in System-C. OK?