In order for any piece of electronic product to go to full production, it has to be modeled, designed, simulated and the design verified before a prototype can be crafted. Based on the performance and may be “feel” of the prototype, a decision and hence a commitment is made to take it to production phase, or iterate the through the process. As an embedded systems developer, focus is mainly on the modeling, design and prototyping stage rather than production.
The first thing to come to mind is the tool used for this work. While traditionally Hardware Description Languages (HDLs) have been successfully used to design, model and verify embedded electronic devices, the fact that those designs are becoming more and more complex as the forces of the market change (more demand within limited production time), some alternative methods have been proposed. One seemingly great alternative is System Level Design. This is involves modeling the device at a higher level of abstraction (with primitive details hidden) and performing verifications of the design functionality. When satisfied with the functionality, details are added step by step lowering abstraction until an implementation model is realized. This is usually referred to as the top-down design methodology. As at the time of writing of this post, one very useful tool for system level design is Systemc.
What is Systemc?
Systemc is a set of C++ libraries and macros that allows for combined hardware and software modeling. It is bundled with an event driven simulation kernel that provides a platform to simulate plain C++ processes. The processes, as they run in the simulator, can exchange data. This data can be in form of all available C++ data-types, the added systemc library data-types and user defined types. Systemc implements three major category of classes that make design and modeling at system level a success. First are the RTL classes that bundle the modules, concurrent processes and bit-accurate data-types. These make Systemc closely resembles HDLs like VHDL and Verilog. Next are the communication classes. They provide a means for data transfer and synchronization protocols. Here we have channels that transfer data through module ports. Lastly are the verification classes. These are used mainly to create test benches for the simulation and verification. They contain random number generation, tracing and logging, signals as well as some means for matching of protocols.
There are two main advantages of systemc as a high level modeling language. First, it allows for models to be crafted really quick through use of macros and templates. This makes modeling easier while iterating the design process. Another interesting fact is that it allows for processing and communication decoupling when it comes to refinement. Details can be added by replacing abstract channels with bus implementation in a model while the model’s processing modules remain unchanged. This allows for refinement to be done for different parts independently as required and execution of simulation at the same time. Signals and data from high-level abstract objects can be interfaced to low-level components. If a part of design requires early testing and a decision to be made, it doesn’t have to wait till all the other parts are clearly defined in details for it to be tested. So systemc covers modeling all the way from high level (software) to the hardware level by providing both hardware and software data-types.
systemc offers a simulated real-time environment while executing your model, that can be used in one of two ways:
1) For untimed models -> every process executes in zero time and the model does not take into consideration any delays or jitter due to data propagation in the hardware. this is mostly the starting point to just verify the design functionality.
2) For timed models -> The time factor can be added to the untimed model. As such, the simulation takes into account the delays due to hardware jitter and execution is not done in zero time. From the designer’s end, it is required of you to insert delay(secs) instructions in the code with ‘secs’ corresponding to the amount of delay expected in the hardware or its estimate. The environment then offers means to tap the time and signal data and damp it for later analysis and visualization such as VCD files or even standard terminal output.
You might have realized that most of the Systemc tutorials out there start you up with simple models of digital circuits like counters and adders. That is a great way to learn the Systemc library but if you are already good in C++ and systems design, for a fairly complex design, then the top-down approach is what you need. It requires you understand how to represent your system in a high-level model leaving out the complex details and focusing on functionality, but later be able to add those details through abstraction levels, down the hierarchy and across domains. You can have a look at the Gajski’s Y chart and Gajski-Kuhn chart for an Overview of this methodology.
Next: An example – The Systemc high-level executable elevator model