Product Family Overview
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.
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 created using Simics Model Builder
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, reverse execution, 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 an Eclipse GUI plus a fully featured command line which
enables scripting of all Simics commands in CLI and Python. Simics
also includes the Simics Analyzer (see below) to support non-intrusive
platform level debug or standalone debuggers such as the GNU Debugger (GDB)
which connect to agents running on the virtual board to support application
debug.
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 Eclipse 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.
Simics Express is an alternate product in the family intended to support users
who do not need the full functionality or complexity of Simics. It
provides the core simulation engine and a minimal user interface. With Simics
Express, users can run the virtual target system. User-written models and
user-written extensions created using Simics Model Builder can run in Simics
Express without those products available or installed. Simics Express is fully
compatible with scripts and automation created in Simics with the
exception of features requiring user interaction. Additionally any output not
directed to a file may not be visible to the user. Simics Express provides no
inspection or debug capabilities, though Simics Express can be extended with
standalone debuggers such as the GNU Debugger (GDB) which connect to agents
running on the virtual board to support application debug.
Simics Express requires a Simics Model to provide the virtual board on which
target software runs. Simics Express does not include any Simics Models.
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 or Express 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 an Eclipse based graphical editor
and debugger for DML, and 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 or Express. 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.
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.
Simics Virtual Platforms model the functionality of a real or imagined hardware
and is 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”.
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.
A Simics Pre-Configured Virtual Platform (PCVP) is an add-on product to Simics
containing a model or models of Commercial Off The Shelf (COTS) IP that has been
pre-configured to support specific use cases. The most common use case is to
support application development on a specific Wind River run time on a specific
COTS board without requiring any additional engineering, configuration or
customization. Additional common use cases include supporting pre-silicon BIOS
development on Intel platforms and providing IP libraries for customers to
extend using Simics Model Builder. The COTS IP modeled is often a physical
target hardware system, but the model does not necessarily include all aspects
of the physical target hardware system, generally only those aspects necessary
to support the use case.
A Simics Platform (Model Library) is an add-on product to Simics that
provides either a bundle of PCVPs or a collection of device models that a user
can add to a Simics Virtual Platform using Simics Model Builder.
The standard limitations may apply to all model products.
-
Error states and diagnostic registers typically only return default values
corresponding to no error when read.
-
Performance counters will only return approximate values.
-
Hardware models are simplified for performance and complexity reasons, as
long as target software in the Delivery Criteria can run unmodified on the
model.
-
Only listed components or models will be implemented. Listed components or
models can have limited functionality as long as the Delivery Criteria are
fulfilled.
-
The default in-order execution model in Simics allows one instruction or
exception to be simulated each simulated clock tick. This means that the
simulated processors implicitly have a “firm” consistency model. Unless
otherwise specified, the in-order execution model is the only execution
model supported.
-
Simics is timing approximate; while Simics maintains a conceptual model
of execution time, it will vary from the execution time of the same
software running on a particular instance of physical hardware.
-
Processor and device models simulate the architecturally defined behavior,
usually defined in a Programmers Reference Manual. The Simics implementation
of processor and device models may differ from hardware implementations but
will comply with the architecture unless otherwise specified.
-
For unusual cases, floating point calculations may have rounding errors,
causing low order bits to differ from what is defined by architecture.
-
While error status registers are available in the simulation model, they
typically have read-write semantics without any side effects. This
means they are not set the simulation model and setting the registers will
not cause any other effects in the model (such as triggering an interrupt
or setting other registers).
-
Deviations from product specification will be noted in the release notes.
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.
- Supported Host Platforms (updated in Simics 6)
- Simics supports the following 64-bit operating system. New versions of
operating systems are usually backward compatible and also work with Simics.
- Linux SLES 12 (GLIBC 2.22, GTK 2.24)
- Windows 10, Windows Server 2016
- 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 in C/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 Compatibility between Major Releases
- 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.
- ABI Compatibility within a Major Release
- Minor releases (where only the third digit in the version number changes)
remain binary compatibility with previous ones, eliminating the need to
recompile modules when upgrading.
- 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. Eclipse is also distributed
as a separate package. Simics Model Builder is bundled with Simics
Base. 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.
- Multi-user Install
- Simics can be installed read-only in a global location in the file-system.
Each user then creates one or more projects where user specific
files, such as modules, scripts and checkpoint data, are saved. A project can
easily be upgraded to use a new Simics version or changed back to use an
older one.
- 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 is a checkpoint; session data such as
simulator preferences and statistics is not. Reverse execution state is not
saved. 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.
- Reverse Execution
- Simics has the ability to reverse time and run the simulation backwards.
The simulation can also run forward again with recorded input, thus
recreating the exact same simulation. Replaying can be turned off thus
allowing alternate future simulation. It is even possible to reverse a
network of machines. The simulation can either jump to a point in time or run
there, thus triggering breakpoints on the way.
- 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 the simulation at any time, and there is support for
removing objects in many device classes.
- 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 (updated in Simics 6)
- 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.
- Scripting Languages
- Simics has a built-in Python interpreter that can be used for both
simple and more advanced scripting, with access to the full Simics
API. In Simics 6, the Python interpreter is Python 3.7.
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:
BOOTP, DHCP, DHCPv6, DNS, FTP, NFS, 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.
Examples: ARINC 429, ATAPI, DDR, Ethernet, Fibre Channel, Flash, GBIC,
I2C, I3C, IDE, IEEE-802.15.4, IEEE-1394, IPv4, IPv6, ISA, MII, GMII,
MIL-STD-1553, MMC, PCI, PCI-X, PCI Express, PCMCIA, PS/2, RapidIO, RS-232,
SATA, SCSI, SystemC, TLM, USB, VGA, and VLAN.
- Host Multithreading (updated in Simics 6)
- Simics can utilize more that 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.
- 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-2,
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.
- Execution Trace
- All instructions executed on the simulated processors can be traced by a
Simics extension. An example extension, the trace module, is included that
traces instructions as well as data accesses, and either prints them to the
simulator console or to a binary file for off-line processing.
- 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. 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 has 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.
- 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. The timing-model is called before the access is performed
and the snoop-device after. The timing-model may stall or terminate the
access, while the snoop-device may change the value.
- 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.
- Hap/Trigger Breakpoints
- Breakpoints can be set on hap (see Simulation and Simulator Triggers)
occurrences, for example log output.
- 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.
- Reverse Execution Breakpoints
- Breakpoints in Simics work both when running forward and when running the
simulation in reverse.
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.
- RapidIO
- A RapidIO link.
- 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.
- 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 (new in Simics 6)
- 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
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.
- GDB Remote
- Simics supports the GDB remote protocol. Multiple GDB debuggers can be
connected to Simics simultaneously, one to each target. The reverse execution
extensions to the protocol are supported. GDB versions 6.8 and up are
supported, although new GDB versions may introduce incompatibilities.
- Telnet Frontend
- It is possible to connect to a running Simics using a standard telnet
client for access to the command line.
- Simulation and Simulator Triggers
- Simics defines haps as pre-defined conditions in the simulation that
trigger the callback of one or more user-installed function. Users may also
add new haps to the simulation. Haps 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.
- 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.
- Symbolic Debugging
- Simics has built-in support for source code debugging of programs written
in C/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 exist 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.
- Supported Module Build Compilers
- To write user modules in DML, Simics requires a C compiler, the GNU make
utility and the GNU binutils package. On Windows hosts, the
MinGW environment is required. Since code provided with Simics
is written in C99, modifications may be needed when using a non-C99 compliant
compiler.
Supported compilers:
- All platforms: GCC 6.3 and newer
- Windows: Microsoft Visual Studio 2015
Newer versions of Visual Studio typically work, but may not be
fully tested with Simics. Recommended to use GCC 12 or newer.
The Simics SystemC library has its own compiler requirements. See the
SystemC Library Programming Guide for details.
- User Developed Devices
- Users can develop their own models of devices by writing DML, Python,
SystemC or plain C/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
reverse execution.
- 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. Reverse execution of SystemC
models is not supported.
- 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, both in C/C++ and in
Python. There is a global simulator lock that is used to synchronize access
to the Simics core, and a few thread safe functions in the API.
- Access to Python From C/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 (updated in Simics 6)
- 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 or C/C++.
- Simics as a Library
- There is a Simics shared object (DLL/.so) that can be linked with another
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.