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 of a binary Python module (a Python C extension), which contains the core functionality. This can be imported from any Python, but one can also write a main binary in C that imports the module, by initializing Python in the standard way and using the Python C API.
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.linux64Makefile.win64simple-simics-py-main.csimple-simics-own-main.cThe simple-simics-py-main example use Py_BytesMain to initialize Python using
standard command line arguments and run the Simics Python application, i.e. run
the contents of __main__.py.
The simple-simics-own-main example initialize Python explicitly, load the
Simics Python module, and then use the Simics API to control the simulation.
If running the Simics Python application, Simics will run its own main loop, so it will not return control to the caller. 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.
When using the Simics API directly, the interface stays in control of
the calling application, which can for example use SIM_run_command()
to control Simics.
There are a few caveats that needs to be taken into account when embedding Simics:
The PYTHONHOME environment variable must be set to point to the
Python installation used, unless the binary is placed inside the
Python installation, where the main Python binaries are. Note that
on Windows, PYTHONHOME should point to the lib/python3.X
directory inside the Python installation.
In the case when the Python module is loaded explicitly, the
PYTHONPATH environment variable must be set to point to its parent
directory, i.e. the [host] directory inside the
Simics-Base installation.
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:
linux64/bin (the Simics libraries) and linux64/sys/lib (system dependencies provided along with Simics). The library search path can be extended using the LD_LIBRARY_PATH environment variable (or the binary can be built with an RPATH setting).win64\bin. The library search path can be extended using Windows API calls such as AddDllDirectory, or on some systems using the PATH environment variable.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.
If necessary, the environment variable SIMICS_INIT_PROJECT can be
set to point to a Simics project. Simics will then use that project
in the usual fashion.
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 46 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.