Simics provides support to cooperate with other applications, either by linking Simics in the other application, or by making the other application a part of Simics.
Simics has been built so it can be embedded into another application: it consists in a small simics binary and several libraries, such as libsimics-common, which contains the core functionality. The main binary can be replaced so that, by integrating the Simics libraries, all Simics functionality can be included as a part of another application.
The Simics Base package contains the source code of a Simics binary replacement located in src/misc/simple-simics/. The following files are included:
Makefile.linuxMakefile.mingwsimple-simics.cThe simple-simics illustrates the main steps to integrated Simics:
SIM_init_environment(). init_arg_t structures, filling it with initialization arguments and their values. Make sure the last entry has NULL fields. The structure is described in the API Reference Manual.SIM_init_simulator2() with the list as parameter. Once there, there are two ways of controlling the simulation.
Simics can run its own main loop, which can be done by calling SIM_init_command_line() followed by SIM_main_loop(). Once this is done, Simics will not return control to the caller, so other means of communication must be put into place if the calling application needs to react to simulation events. For example, a dedicated Simics extension might be taking over.
Simics can also accept commands one at a time, with SIM_run_command(). In that case, the interface stays in control of the calling application.
There are a few caveats that needs to be taken into account when embedding Simics:
The paths that contain Simics libraries and their dependencies must be in the search path for libraries. This is usually done in the Simics start scripts, so when embedding Simics, the controlling application has to make the necessary configuration changes itself:
[simics]/host/bin (the Simics libraries) and [simics]/host/sys/lib (system dependencies provided along with Simics). [simics]\win64\bin.Even when embedded, Simics uses the standard and error outputs for its messages, which might interfere with the controlling application's output.
When starting the simulation via SIM_run_command(), Simics does not return control to the application until the simulation is somehow stopped. This makes it important, if not indispensable, to place appropriate callbacks in the simulation to keep control of what is going on. Callbacks can be placed in real-time, via SIM_realtime_event(), or directly in the simulation using haps and events.
To integrate another application into Simics you need to be able to build the application as a Simics module or at least as a shared library you can load from a Simics module. If this is not possible see chapter 44 for how to connect your application to Simics.
The communication between Simics and the application needs to use the Simics APIs. The exact nature of the communication depends on what the embedded application does.
If your application runs its own simulation which needs to be integrated with the Simics simulation you should use the Simics Device API and the Model-to-Model and Model-to-Simulator interfaces to integrate with Simics. This basically makes the module containing the application a normal model module, as described in the Model Builder User's Guide.
If the application simulates one or more processors which you want to appear as processors in the Simics simulation use the Processor API, documented in the Processor Model Integration Guide, instead.
Your application can also integrate with Simics as an extension module using the Simulator API and Simulator-to-Simulator interfaces as described earlier in this document.
Of course, these categories of applications are not rigid. An application may need to use parts of the Simulator API to do its work, for example it may need to use SIM_register_work or SIM_thread_safe_callback even though it is mostly a model.