1 Simics Products

The Simics product family is made up of multiple products and optional add-on products. For clarity the products are grouped into tools products and model products. This section defines what these products are and how they interact with each other. Please contact your Simics provider for the licensing terms of each product.

Features presented in this document may not always be supported for all architectures, for all target software and on all hosts.

1.1 Simics Tool Products

1.1.1 Simics

Simics is the primary product in the family. It provides the core simulation engine and user interface. With Simics, users can set up, run, control and inspect the virtual target system. User-written models and user-written extensions and fault injectors can run in Simics without those products available or installed.

The primary functions of Simics are the simulator itself with hardware-level inspection capabilities, the ability to save and restore checkpoints, record-replay functionality, snapshots, breakpoints, scripting, host connections (aka real networking), and simulation performance monitoring. Checkpoints contain the complete state of the system, thus when you save a checkpoint you are saving the entire state of the system, including the processors, devices, and all the software. When you restore a checkpoint, you begin executing from the exact place where you stopped executing when you saved that checkpoint.

Simics offers a fully featured command line which enables scripting of all Simics commands in CLI and Python. Simics also supports non-intrusive platform level debug or standalone debuggers such as the Intel* System Debugger, and the GNU Debugger (GDB) which connect to agents running on the virtual board to support application debug.

1.1.2 Simics Analyzer

Simics Analyzer is a part of the Simics product which provides analysis and debugging capabilities for software applications for large distributed and heterogeneous systems as well as less complex systems. Information is primarily accessed via GUI views, as well as being accessible from the Simics command-line. The primary functionalities of Analyzer are Source Code Debugger, OS Awareness, Full System Process List, System Execution Time Line, and Code Coverage. More details can be found in the Feature List document. Simics Analyzer is a system-level debugger that provides debug across all targets in a Simics session. Simics Analyzer can debug heterogeneous systems from a single debug view, including different target architectures and operating systems.

While Simics provides a hardware-centric view of the system, Simics Analyzer extends this to a software-centric view. At its most basic Simics Analyzer extends the assembly level debug of Simics with stack frames and local variables. On supported architectures (ARM, Intel, PPC, and MIPS) this can be extended to source level debug for single context systems such as boot code and OS kernels. Source level debug can be extended to multi-context systems through the use of OS awareness. OS awareness, which must be enabled for each combination of Operating System and CPU type, is provided for most Wind River Operating Systems and Linux with many Simics Model Products, see the associated Target Guide for supported combinations. Users can enable OS awareness for additional Operating Systems using Simics Model Builder. Simics Analyzer requires no instrumentation or other changes to the target code.

1.1.3 Simics Model Builder

Simics Model Builder is an add-on product in the Simics Family. Simics Model Builder allows users to create and modify the device models, virtual boards, and systems that Simics runs. Additionally it lets users adapt and extend Simics with new capabilities, allowing for customization, expanded use cases and integration into other tooling environments.

Simics Model Builder provides access to the Simics API documentation and frameworks needed to build device models, components, and system configurations in DML, C, C++, SystemC, Python, and any other language that can be compiled to a C-language API. The API includes frameworks for common types of devices such as PCI, I2C, and Ethernet. The Device Modeling Language (DML) allows device models to be created quickly and efficiently by providing appropriate constructs for common modeling tasks such as register banks, bit fields, and endianness. Additionally, Simics Model Builder includes a kit for creating target system panels.

Simics Model Builder includes a SystemC Library that provides the ability to use SystemC TLM models within Simics, and to build SystemC models into Simics modules that can be run in Simics. SystemC Library-based models support most Simics CLI and GUI inspection features in the same way as models written directly for Simics. The SystemC Library supports SystemC 2.3, TLM-2.0, and both AT and LT-style SystemC models.

1.1.3.1 SystemC Library Requirements

Simics supports running SystemC models, but because C++ does not have a standardized ABI, all SystemC Library modules as well as all SystemC models to be run inside Simics need to be compiled with exactly the same compiler, compiler version, and compiler flags. It works perfectly fine to include binary SystemC models as long as they are Accellera compliant and the compiler guidelines just outlined are followed.

Simics does not guarantee that the Simics SystemC Library API will not change between releases. Simics’ SystemC support is still being gradually improved and a completely frozen API would limit what improvements can be made. A lot of effort will, however, be made to avoid changing the API. If a change is needed, the end-user effort will be minimized.

1.2 Simics Model Products

Simics Virtual Platforms model the functionality of real or imagined hardware and are required for useful operation of a Simics Tools product. A Simics Virtual Platform can be as simple or complex as the physical target system is. It can contain anything from a simple CPU and RAM, to a complex single board computer containing a multi-core processor, to a personal computer with graphics, disk drives, and mouse, or even to a complex network of computers and systems. Simics Virtual Platforms can connect to other Simics Virtual Platforms or to the real world via networks like Ethernet.

Simics Virtual Platforms are comprised of a combination of model Components, Processor/SoCs models, and device models. Simics Virtual Platforms may not model all possible functionality of the hardware as models are frequently written to support the needs of a specific Operating System or set of Operating Systems. Simics Virtual Platforms are often referred to as “targets”.

1.2.1 Simics Quick-Start Platform

A Simics Quick-Start Platform or QSP includes a model of a generic machine with a real core. The point of the QSP is to enable basic simulation of code that is Architecture and OS dependent, but BSP independent. The set of devices provides what an OS requires to execute: interrupt controller, system controller, timers, memory, serial connection, Ethernet, real-time clock, disk and flash. The devices are PC compatible with x86 QSP. The QSPs include board support packages (BSP) that enable operating systems to run on the QSP.

1.2.2 Simics Platforms

A Simics Platform (Model Library) is an add-on product to Simics that provides a collection of device models that a user can add to a Simics Virtual Platform using Simics Model Builder.

3 Simics Feature List

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.

3.1 Product Characteristics

Deterministic Simulation

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.

Non-intrusive Inspection

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.

Well-defined API

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.

API and ABI Compatibility

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.

Modular Product Distribution

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.

3.2 Simics

3.2.1 General Features

Save and Restore of Checkpoints

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.

Snapshots

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.

Save and Restore of Persistent Data

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.

Dynamic Machine Configuration System

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.

High-Level Component Configuration System

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.

Hierarchical Configuration System

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.

Recording of Asynchronous Input

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.

Hybrid Simulation

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.

Integrated Python support

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.

Scripting Languages

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.

Quick-Start Platform for x86

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.

Network Services

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.

Computer Industry Standards

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.

3.2.2 Performance

Host Multithreading

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.

Distributed Simulation

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.

Run-time Code Generation

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.

Hardware-assisted Virtualization - VMP

The Simics VMP feature can improve the simulated performance by utilizing the hardware virtualization support found in modern Intel® processors.

Hypersimulation

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.

Restriction on Host Memory Consumption

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.

Real-time Mode

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.

3.2.3 Processor Features

Instruction Set Architectures

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.

Multi-processor and Multi-core Models

Target systems with multiple processors (SMP, AMP systems and multi-core processors) are supported.

Configurable Ratio Between Cycles and Instructions

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.

Generic Parameterized Cache

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.

Instrumentation Framework

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.

Processor Instrumentation

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.

Device Instrumentation

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.

Device Register Coverage

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.

Magic Instructions

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.

3.2.4 Memory Features

Generic Address Spaces: The memory-space abstraction in Simics supports a generic 64-bit address space where memory and devices can be mapped in. Objects can be mapped at multiple addresses and be mapped overlapping with different priorities. Several common byte-swapping operations are supported for mappings. Memory spaces can be mapped in other spaces, with optional address translation being performed between them.
Dynamic Memory Mapping: Both memory and devices can be mapped and unmapped in memory-spaces at any time during the simulation. This is typically used when simulating system chipsets and host bridges that allow target software to modify the memory and device layout in the physical memory space.
Catch Accesses to Unmapped Areas: Memory areas that are not mapped by any device or memory can either be handled as on real hardware or caught by the simulator producing a warning or triggering a user callback.
Memory Access Callbacks: User callbacks can be installed for each memory space and are called on memory accesses.

3.2.5 Breakpoint Features

Memory Access Breakpoints: Breakpoint can be set on reads, writes and execution from memory. Any number of breakpoints can be used and they can be of any size. Breakpoints usually have a very small impact on performance.
Time Breakpoints: Breakpoints can be set on cycle or step count for each processor and on time in seconds.
Instruction Breakpoints: Execution breakpoints can be set on instruction disassembly sub-strings and instruction bit patterns.
Processor Register Breakpoints: Read and write breakpoints can be set on processor register writes.
Processor Exception Breakpoints: The execution can be stopped when a processor takes a specific exception.
Device Access Breakpoints: Breakpoints can be set on accesses to memory and port mapped devices.
Notifier/Trigger Breakpoints: Breakpoints can be set on notifiers (see Simulation and Simulator Triggers) occurrences.
Console Output Breakpoints: It is possible to set breakpoints on console output. For text consoles, a string to break on is used. Graphical consoles have support for breaking on a rectangular bitmap area.

3.2.6 Communication Channels

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.

Ethernet: Generic models of an Ethernet cable, a switch and a hub.
I2C: A link for I2C communication.
I3C: A link for I3C communication.
Serial: A serial link that can be connected to UARTs and text consoles.
Signal: A link for single line signals.
Link Library: A link library is provided for creating new user defined link types, replacing the old generic message link.

3.2.7 Host Access

Exported Serial Line: A simulated serial port can be made visible to the host system where Simics is running. On Linux systems, this is implemented by connecting the simulated device to a pseudo terminal (pty). On Windows, a virtual COM port on the host is used.
Telnet to Serial Port: Simulated serial ports can be accessed using a standard telnet client from a real host.
VNC to Graphical Console: It is possible to connect to a simulated graphical console from a VNC client.
Host Serial Port: A simulated serial port can be connected to a real serial port on the host. On Windows hosts, additional third-party software is needed.
The Simics Agent: The Simics agent runs on the simulated target system and can be controlled from the Simics command line. It supports file transfers between the host and the target machine, without the need for any network connection.
Simics File System for Linux: The Simics file system is a kernel module for the simulated Linux operating system that gives the target machine access to the host file system.
ISO file as CD-ROM and DVD-ROM Medium: The simulated CD-ROM drive can use a standard ISO 9660 file as CD/DVD-ROM medium.
Host Hard Disk: Hard disks and disk partitions on the host can be used as part of a simulated hard disk. The disk can be used in either read-only or read-write mode.
Graphical Display: Output from simulated graphics devices are displayed in a separate window on the host, a graphical console.
Keyboard and Mouse: The keyboard and the mouse of the real host can be used to give input to the simulated keyboard and mouse.
System Panel: A System Panel is a graphical interface for controlling and inspecting a specific simulated machine. The panel can either be a concrete panel, which could represent the front of a computer with buttons and blinking LEDs; or it can be an abstract panel that can be, for example, used to inject network traffic or other data into a simulated system.
Port-forwarding/NAT: Port forwarding (incoming) and NAT (outgoing) allow the target systems to communicate with the real network using their own private IP addresses. Simics translates between external and internal IP addresses. Port-forwarding/NAT does not require administrator privileges to setup. Both UDP- and TCP-based protocols are supported, although a few higher-level protocols, such as FTP, may require special support. Common protocols that work are SSH, Telnet, TFTP, FTP and HTTP.
Ethernet Bridge: Simics can act as an Ethernet bridge between the real and simulated network, where the simulated machines appear to be on the real Ethernet network. Administrator privileges on the host are required for installation. The simulated machines have to be configured with IP addresses matching the real network.
Virtual Host Interface on the Simulated Network: Simics can create a virtual interface (TAP) on the real host that appears as a network device on the simulated network.

3.2.8 Remote Interfaces

GDB Remote: Simics supports the GDB remote protocol. Multiple GDB debuggers can be connected to Simics simultaneously, one to each target.
Telnet Frontend: It is possible to connect to a running Simics using a standard telnet client for access to the command line.

3.2.9 Miscellaneous Features

Simulation and Simulator Triggers: Simics defines notifiers as pre-defined conditions in the simulation that trigger the callback of one or more user-installed function. Users may also add new notifiers to the simulation. Notifiers are either simulation or simulator specific. Examples of the first kind are processor interrupt, control register write and magic instruction. Examples of the second kind are configuration object created, simulation stopped and preferences changed.
Time Server: The virtual time can be distributed to externally running tools, allowing them to run with the same virtual time as the simulated session. This is useful for timing sensitive tests, for example, when the real and simulated time differs.
Loading Binary Files into Simulated Memory: Simics can load binary files, including executables, directly into the simulated memory, without the need for any initial loader software. The formats supported are raw binary files, ELF, Motorola S-Record, PE32 and PE32+, Intel .obj and Intel HEX.
Compressed Disk Images: Disk images for simulated systems can be stored in a compressed random access format, called CRAFF, to save disk space on the host. The compression is transparent to the target system. The standard VHDX format is also supported.
Load and Store of Memory and Disk to Host File: Parts of, or complete, memory and disk images in Simics can be saved to a file on the host file system.
Ethernet Frame Injection: Frames on the simulated Ethernet link can be inserted, removed and modified by the user. It is possible to inject a stream of frames using the PCAP format.

3.3 Simics Analyzer

3.3.1 General Features

Symbolic Debugging: Simics has built-in support for source code debugging of programs written in C or C++. The formats supported are ELF with DWARF debug information and PE32 with PDB debug information. Formats such as COFF and STABS are not supported. The debugger works with ARM, PPC, X86, MIPS and ARC targets.
OS Aware Process Tracking: Simics can detect when processes start and exit on the simulated machine, and keep track of what process that is currently active. Process tracking is useful for single process debugging, or when collecting statistics on a per process basis. Since knowledge about the target OS is needed, the process tracker has to be extended to support new operating systems. There is also a simple process tracker that only differentiates between user and supervisor mode that can be used if the OS is not supported. See Analyzer User’s Guide for list of supported systems, including Linux, UEFI and VxWorks.
Code Coverage: Simics supports collecting code coverage (statement and branch coverage) on C, C++ and assembler source code for software running on the simulated target without any need to instrument the binary code.

3.4 Simics Model Builder

See Hardware and Software Requirements for supported compilers.

User Developed Devices

Users can develop their own models of devices by writing DML, Python, SystemC, C or C++.

DML

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.

SystemC Library

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.

System Panel Build Kit

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.

Example Code

There is example code in DML and Python included for several common device classes such as DMA, I2C, PCI, interrupt, serial devices and timers.

Multithreaded User Extensions

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.

Access to Python From C and C++

The Simics API allows extensions to evaluate Python code in the global Python interpreter environment and to get a return value back.

Access to C Functions from Python

User defined Simics interfaces can be called from Python code.

User-defined Commands

Users can add their own commands to the command line interface. Commands can be added dynamically at any time.

User-defined Processor Instructions

Using the instrumentation framework, a user may override the semantics of existing instructions or define new ones.

User Developed Processors

Users can plug in their own processor models in Simics using the Simics Processor API.

User Developed Simulator Extensions

The simulator can be extended by modules written in Python, C or C++.

Simics as a Library

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.

Time Synchronization Library

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.

Hypersimulation Interface

There is an interface for adding user-written hypersimulation patterns (idle loop detectors) to the generic hypersimulation framework.

Product Family Overview