This section provides a short but comprehensive list of the major product characteristics and features of Simics 6. For more detailed descriptions, refer to the complete Simics documentation.
Simics is deterministic, forcing the exact same sequence of simulated instructions and device events to occur when rerunning the simulation. A deterministic simulation greatly simplifies debugging of target systems.
Observation of the simulated system by scripts, GUI, command line and actions like checkpoint creation is non-intrusive; i.e., the simulation does not change although observation is being done.
Simics exports two well-defined application programming interfaces (APIs) based on C, available from both C and C++. One for device modeling, the Device API and one for extending the simulator, the Simulator API. The two APIs are also available in Python, and there is a small Python-only API in addition.
Simics follows the standard semantic versioning rules. This implies that in minor releases (where only the second digit in the version number changes), there can be additions to the API, but not removals, so Simics maintains ABI compatibility. Hence there is no need to recompile modules when upgrading.
The API remains compatible with previous Simics releases. When building modules written for an older version of Simics, the API to use must be specified.
The Simics product is distributed as a single common base package, with several add-on packages. There is typically one add-on package for every modeled system architecture. Installing support for a new architecture for example does not require the base package to be re-installed. Add-on packages and the base package can be upgraded independently of each other within the same major release.
The simulation state of an entire Simics simulation can be saved to disk and restored at a later time in a host independent format. Saving a checkpoint can be done at any point in time during a simulation. Checkpoints are stored in a combination of human readable configuration files and binary files for large state (such as simulated disk or memory) and can be annotated with a clear text description. Checkpoints are incremental by default, i.e. only data that has changed since the last checkpoint is saved. But independent, stand-alone checkpoints can also be created. Only the simulated state is saved in a checkpoint; session data such as simulator preferences and statistics is not. It is also possible to include a recording of user and network input in a checkpoint. Old checkpoints can usually be loaded into newer versions of Simics.
The simulation state can also be saved as in-memory snapshots. This is similar to checkpoints but is used within one simulation session. Snapshots can be loaded later, thus jumping between different points in simulation time.
Persistent data, such as disk images and NVRAM contents that survive power-cycling, can be saved and restored at any time without the need to save the complete simulated state.
Simics simulations are configured using objects and object attributes. The configuration language is used to setup machines and connect machines via networks. Configurations are host independent and can be created programmatically. Although editing by hand is possible configurations are typically created by tools, such as the component system. Objects can be added to and removed from the simulation at any time.
The primary configuration system uses components that represent actual replaceable hardware units, such as mother-boards, disks, keyboards, PCI cards and network links. Components support hot-plugging if applicable, and they also make sure that only valid hardware configurations are set up.
The configuration system supports hierarchies of objects as a way to impose structure of large and complex system. Some configuration aspects are inherited based on the hierarchy, simplifying setup.
Simics can record all input coming from the real world, allowing replay of a simulated session. Since the simulation is deterministic, a session can be rerun with the exact same result. Asynchronous input includes network traffic, serial port communication, keyboard and mouse input. The recording can also be saved separately or together with a checkpoint.
The Hybrid Simulation feature allows integration between Simics and an external, much more timing accurate simulation model. As the accurate model will run significantly slower than a Simics functional model, the functional model can be used for workload positioning. Once this has been done, the simulation state can be transferred (and transformed) into the accurate model, and simulation can be continued.
Integration of external timing accurate models require specific development, please contact Simics Support for more information.
Simics is built and distributed as a binary Python extension module. It can be used with any sufficiently recent Python interpreter that is compatible with standard CPython binary modules.
In Simics, one can use Python for both simple and more advanced scripting, with access to the full Simics API.
The Simics specific command line interface (CLI) can also be used to write scripts.
The Simics Quick-Start Platform for x86 is a model of a standard Intel®-based personal computer (PC). The virtual platform boots from a TianoCore-based open-source UEFI (Unified Extensible Firmware Interface) and can run modern Linux, Windows*, and other operating system distributions. The platform is highly configurable and includes aspects like the number and types of processor cores, memory size, disks, network setup, PCIe* cards, and more.
Simics includes a virtual network server which provides a number of common network services over IPv4, and in some cases IPv6, on Ethernet networks. These include BOOTP, DHCP, DHCPv6, DNS, FTP, NTP, RARP, and TFTP.
A wide range of common computer standards are supported and implemented in Simics in some form. There is often generic support for common protocols that can be extended for specific devices.
Simics can utilize more than one host core to get improved simulation performance for both target systems that can be partitioned into multiple machines, called cells in Simics, and for tightly-coupled multi-processor target systems based on the ARM, PPC and x86 architectures.
A simulation can be distributed over several Simics processes, either running on the same real host or on multiple networked hosts. A distributed simulation keeps the determinism of non-distributed simulations, and maintains global time across all processes. Simulations can be distributed at link boundaries, such as Ethernet and serial port connections.
Simics uses a run-time code generator to achieve high performance, often better than 10x compute slowdown.
Supported architectures: ARM, MIPS, PPC, RISC-V, SH4, SPARC-V8, x86.
The Simics VMP feature can improve the simulated performance by utilizing the hardware virtualization support found in modern Intel® processors.
Hypersimulation, also known as idle-loop-optimization, improves the performance of the simulation by doing fast forward of the virtual time when the target system is running code without side-effects. The system automatically identifies many hypersimulation opportunities of moderate complexity. For more complex opportunities, users can adapt the hypersimulation to match their own target code.
The amount of host memory used by Simics to cache simulated memory and disk images can be limited to avoid memory related performance problems. Excess data is swapped out to files in a user specified directory.
Simics can be throttled to make sure that virtual time does not run faster than real time, or faster than some fixed ratio compared to real time.
Simics implements at least one processor for each of the following instruction set architectures:
ARC, ARMv5, ARMv6, ARMv7, ARMv8, H8, i8051, M68K, MIPS32, MIPS64, NIOS II, NIOS V, PPC32, PPC64, RISC-V, SH4, SPARC-V8, X86, X86-64.
Target systems with multiple processors (SMP, AMP systems and multi-core processors) are supported.
The CPI (cycles per instruction) of a processor can be modified at run-time to get processor timing that is closer to real hardware for example. Both 0 and infinity are valid CPI values.
Simics includes a simple parameterized cache which can be configured to have parameters similar to a real cache in both single- and multi-processor systems. The parameters include size, associativity, number of levels, replacement policy and replacement algorithm. Simple miss penalties can be configured.
The instrumentation framework allows flexible extraction of run-time information from the system in an efficient way. The framework supports processor and device instrumentation, including tracing. It provides generic commands for adding and controlling instrumentation in the simulation. Several example tools and filters are provided with source code as examples.
It is possible to get callbacks on many events in a processor model such as instruction fetches and execution, data accesses, exceptions and interrupts. Data in transactions and default instruction semantics can be overridden.
It is possible to get callbacks on device register accesses, where data can be overridden. Instrumentation works automatically for devices written in DML or SystemC.
Simics can generate information about register coverage, i.e. which registers in a system have been read/written during a session. This can for example be used to verify that expected parts of a system have been covered by tests.
The software on the simulated system can communicate with the simulator by using magic instructions; i.e., instructions that are treated as NOPs on real hardware, but have a special, user-defined, meaning in Simics. The Simics Agent, described separately, provides a more high level way of communication between host and target.
Communication links in Simics that work with multithreading and distribution. Links provide the only supported target communication between simulated machines that run in different host threads or on different host machines.
See Hardware and Software Requirements for supported compilers.
Users can develop their own models of devices by writing DML, Python, SystemC, C or C++.
The device modeling tool DML simplifies the task of implementing simulation models at the right level of abstraction and makes it easier to develop models that support standard features such as inspection, checkpointing and snapshots.
The SystemC library enables a SystemC device to be integrated into a Simics simulation. This is done by compiling the SystemC kernel into a Simics module, together with the SystemC simulation models.
The user will have to write translators between the SystemC and Simics interfaces.
Limitation: For checkpointing to work, the SystemC model has to be adapted to use the Simics checkpoint mechanism. Also, it may not use threads or have some other implicit state.
The System Panel Build Kit enables the construction of System Panels. A System Panel is a graphical interface for controlling and inspecting a specific simulated machine.
There is example code in DML and Python included for several common device classes such as DMA, I2C, PCI, interrupt, serial devices and timers.
Simics extensions may be written using threads in C, C++ or Python. Only a few thread safe functions in the Simics API are then available. The rest of the API can be accessed by synchronizing to the Simics core, which is done using the thread safe functions.
The Simics API allows extensions to evaluate Python code in the global Python interpreter environment and to get a return value back.
User defined Simics interfaces can be called from Python code.
Users can add their own commands to the command line interface. Commands can be added dynamically at any time.
Using the instrumentation framework, a user may override the semantics of existing instructions or define new ones.
Users can plug in their own processor models in Simics using the Simics Processor API.
The simulator can be extended by modules written in Python, C or C++.
There is a Simics shared object (DLL/.so) that can be linked with other binaries. This can be used to integrate Simics into another simulator or application.
The time synchronization library, as its name implies, provides synchronization of the virtual time in Simics with the virtual time in an external simulator. It also provides a deterministic way to exchange information between them, such as network traffic.
There is an interface for adding user-written hypersimulation patterns (idle loop detectors) to the generic hypersimulation framework.