Today I’ve read two enlightening articles about SystemC and its practical use on assessing performance of a hardware Electronic System Level (ESL) design, which is what we must do in MULTICUBE project.
SystemC: Hardware-Oriented Constructs in C++. A C++ library for ESL design and verification
George F. Frazier. January 01, 2005.
The author says that the principal motivation of using a high level systems description language is the millions and millions of gates that nanotechnology has managed to build into an integrated circuit, a new degree of semiconductor integration that is now possible and that has led to the emergence of very complex and versatile “systems on a chip.” In the early days of EDA, a simulator could track the state of every gate on a circuit board. As complexity blossomed, newer methodologies has emerged for simulating systems at a courser grain (RTL, TLM, …), generalizing system representation to a higher level, where the simulation of systems is viewed as a behavioural flow, as a series of inputs and outputs, not clock cycles.
Now It’s all about developing Electronic System Level (ESL) models of IP Cores that can be exchanged, reused, and grouped to construct modular systems (MpSoC). Reuse and modularity have spurred interest in developing an object-oriented technology for ESL. That is SystemC, which is a C++ class library for system design based on Standard C++. OSCI provides a free “reference implementation” distributed with an open-source license.
There are also commercial implementations such as Cadence’s NC-SystemC/Incisive and CoWare’s ConvergenSC System Designer (The companies have mixed their products now) NC-SystemC, for example, supports many features not available in the OSCI simulator, including mixed-language capabilities via the Incisive platform, advanced debugging facilities, a transaction/wave-form viewer and advanced data-probing methodologies, simulation of models that are 100 times faster than RTL, transaction recording, and a System Verification Library that is now a part of OSCI. Cadence put its verification technology as open source named as Open Verification Methodology (OVM)
SystemC provides the elements that model typical constructs in a chip or system design: modules, ports, interfaces, and channels. A module can contain ports, processes, channels, internal data, and other modules. A port is the boundary through which a module communicates with the outside world. A module’s interfaces are the set of operations that it supports. Interfaces are similar to (and implemented as) abstract methods in C++. Finally, channels implement the interfaces that define the module’s signature. Below this is the event-driven simulation engine that ties the system design to the simulator. The simulation is controlled by discrete event-simulation constructs in SystemC, such as mechanisms for specifying time granularity, port sensitivity, runtime semantics of processes (if the process is a separate thread, for example), a central scheduler, and so on. Advanced facilities exist for specifying different models of computation (RTL, Transaction Level, Functional, Dataflow) and communication refinements.
Finally, the author develops two examples in SystemC. The first example is a multiplier, where he shows the SystemC macros for a module: SC_MODULE, SC_CTOR and SC_METHOD. The second example is a FIFO channel, which can be used to interconnect modules. Here we can see the concurrency description with sc_events, SC_HAS_PROCESS and SC_THREAD (implemented with POSIX threads, win32 fibers or QuickThreads) The channel concept is achieved with the interface programming (sc_interface) concept which separates specification from implementation.. A top module with a sc_main runs the show (simulates all the blocks) There is a SystemC scheduler handling the events during simulation with eight steps. It is interesting the concept of delta cycle as a construct to simulate concurrent behaviour.
The second article shows a methodology to improve the performance measurement at high levels (transaction, functional) in ESL designs:
Smita Ratnam, Philips Semiconductors
Aniruddha Baljekar, Philips Semiconductors
Models at higher level of abstraction (e.g. SystemC models) are required for driver development, tuning of system software, architectural exploration/verification, performance analysis, power measurements etc. While SystemC models suffice the needs of driver development and architectural exploration, cycle accurate models are required for performing performance analysis, architectural verification, tuning of application code and power analysis. Models at higher levels of abstractions are not cycle accurate. Alternatives are to use emulators, which are very costly.
The author then look for a methodology to address cycle accuracy and performance measurement of a SystemC model and then fine tuning it by benchmarking it with RTL as a golden reference model. Methodology in brief:
- Mapping of the SystemC function calls to the specific signals
- Design a verification environment which can be reused for RTL and SystemC
- Write test cases to generate same sets of transaction/burst for SystemC and RTL.
- Capture the specific data required for comparison
- Perform analysis and fine tune the SystemC model
- Execute regression tests on SystemC and RTL design
- Benchmark with respect to RTL design
This methodology has some limitations: RTL has to be available as a reference for doing a comparison with the SystemC model. Fine tuning of the SystemC model is needed according to the findings with RTL as a reference.
To accomplish the experiment, the author uses cadence tools (Specman, eVC, IUS, Transaction Explorer, …) He uses traces (eVC results) at RTL and TLM levels, so the SystemC function calls are mapped to the relevant RTL signals.