|
Simo 0.0.1
|
This document introduces how to create a custom main when SimoSim may not be the best fit for simulation. CustomMain.cc is a minimal example.
CMake targets are ready to use. Instead of using Simo::Simo_includes_only, use Simo::Simo. This target includes the headers and the Simo library.
A very minimal CMakeLists.txt is the following:
The only thing that it is required is instantiating a Simo::Context.
Modules are not strictly required to model a simulation. It is also possible plainly use Simo::Context::schedule_* methods to schedule any type of function:
But remember that modules are a convenient way to model components, and they are equipped with convenient methods to create full-fledged systems.
One limitation of SimoSim is that it manages modules and parameters losing the information of the concrete type of modules and parameters. This is a drawback of the module loading mechanism through collections exposed by shared libraries.
Creating a custom main allows to directly use the concrete types. This is useful when the system configuration is known at compile time, so the modules that composes it can be directly instantiated and added to the simulation context with Simo::Context::add_module:
Unit-test at tests/Simo/MainLoopTests.cc or any other unit-test that uses Simo::Context are simple examples of how to write custom mains. Also,the source code of SimoSim is a good example at src/SimoSim/SimoSim.cc.
Instantiating Simo::Context may seem a bit tedious, but it allows to potentially have multiple simulation contexts in the same executable in parallel.
In SystemC only one simulation context is allowed per process. When the simulation stops, it cannot be reinitialized. This is a big limitation for unit-testing where multiple simulations are required to be executed (hacks with forking the process can work, but it is tedious).