Kai-Hylla.de  

Last Update: 03 Jun 2018
October 2007 – April 2008

The SystemC/Simulink Tool Kit was created during my master's thesis, written in 2008 at Robert Bosch GmbH. Aim of my master's thesis was to create an interface that allows the developer to use SystemC modules inside a MATLAB/Simulink simulation environment. This allows reusing the same modules in a SystemC as well as in a Simulink environment. This is especially useful in a simulation-based verification flow. A system description can initially be implemented as Simulink model. After the correctness of the high-level Simulink model has been shown, the system can be transformed into a more detailed SystemC description. On both levels the same test bench modules can be used, assuring that both descriptions of the system fulfil the same requirements. Reusing test bench modules also reduces the likelihood of errors and speeds up the development.

Embedding SystemC modules into a Simulink environment is done by a set of wrappers. These wrappers implement a so-called S-Function, which can be used inside Simulink. Inside the Simulink environment SystemC modules appear as ordinary Simulink building blocks. Ports of the SystemC module can be connected to Simulink building blocks using connecting lines. Synchronisation as well as data conversion is done automatically and completely transparent.

The wrapper S-Function instantiates the SystemC module, sets up Simulink-specific parameters like the sample time, and is responsible for the data conversion. All in all there are three wrapper classes. The first one is used the forward S-Function calls, implemented in C to a C++-class. The second class instantiates ordinary SystemC modules. And finally, the third class allows to instantiated special SystemC test bench modules.

Most difficult part when implementing a co-simulation between SystemC and Simulink is the synchronisation. Both environments use different concepts of how the simulation is driven. SystemC is event driven, meaning that there is an event-queue that is processed event by event. Simulink however uses a so-called sample time that defined the points in time when a building block is to be updated. Unfortunately there is no golden solution covering all possible combination of occurring events and sample time. So five synchronisation procedures have been implemented, each covering a certain scenario.

Scenario 1
uses a variable sample time and is suitable for modules that do not have incoming signals. Outgoing signals are driven by internal events, only. The event queue is used to determine the next point in time when the next event occurs.
Scenario 2
is used if Scenario 1 applies, but no solver supporting a variable sample time is available. In this case fixed sample time is used.
Scenario 3
occurs if the SystemC module has incoming signals but no internal period. In this case the module is updated if an incoming signal changes.
Scenario 4
is used if the module as incoming signals and an internal period. In this case a so-called base period is used, which unifies the sample times of incoming signals and the internal period.
Scenario 5
is a special case of Scenario 4. In this case the module has no outgoing signals. Therefore a dummy port is required that gets the base period assigned.

The second problem to cope with is data conversion between both environments. In order to provide a different conversions with respect to the different data types provided by Simulink as well as different Simulink toolboxes like the FixedPoint toolbox, a flexible solution was implemented. When instantiating a SystemC module inside a Simulink model a parameter can be given to the S-Function, specifying which data conversion should be used. Currently there are three types of conversion possible.

Implicit
This is a simple conversion, where all SystemC data types are mapped to the default Simulink data type double. As the name implies, conversion is done implicitly, meaning that a simple static cast is performed.
Simulink
Besides the default type double, Simulink provides other data types like integer, booleans, etc. From all Simulink data types the best fitting one is chosen.
FixedPoint
The last converter currently available uses the FixedPoint toolbox. This converter allows a precise representation of SystemC’s fixed-point data types.

If other data types are required or if different ports of the same module should be converted in different ways, Simulink provides a large set of converters that can be instantiated inside the model.