The Simics® simulator has a long history in both industry and academia. Initially called a full-system simulator, it was created in the early 1990s as part of research into future multiprocessor architectures at the Swedish Institute of Computer Science (SICS*), which is now a part of RISE*, the Research Institute of Sweden1. The Simics simulator is built in the tradition of full-system simulators as used in academia and computer system builders (the word “virtual platform” was not in widespread use at the time), in particular the g88k simulator. The name “Simics” is a play on “Simulator from SICS”. The startup Virtutech2 was founded in 1998 to make the simulator into a commercial product. in 1998. Virtutech was acquired by Intel in 2010, with commercial sales handled by Wind River3, which was an Intel subsidiary at the time.
From the start4, virtual platforms running in the Simics simulator were used for two classic applications: computer architecture exploration and pre-silicon software development (or shift-left5). Over time, the use cases expanded to include general software testing and development, in particular in the area of firmware, operating systems, boot code, and embedded software where virtual platforms provide superior convenience compared to physical boards.
Today, Intel uses the Simics simulator and virtual platforms for pre-silicon software enabling and development, computer and system architecture, hardware validation, ecosystem enablement, and more. The Simics framework has proven to be capable of modeling the most complex hardware platforms available. Virtual platforms can integrate all types of external tools and other simulator models including cycle-accurate computer architecture simulators, debuggers, physical world simulations, big-box emulators, and more. The integration of performance, power, and thermal models with Simics models is one of the pillars of Intel® Integrated Simulation Infrastructure with Modeling (Intel® ISIM). The underlying simulation core and scheduler are fast and scalable, and can take advantage of multiple host cores to accelerate the simulation.
One of the original core goals of the Simics simulator was to run target system code quickly6 using a functional level of abstraction with simplified timing. Additionally, features that cost simulation speed, such as simulating architectural timing details and tracing the target system execution, should only be turned on dynamically when needed.
The current Simics simulator implements many technologies intended to increase the speed of the simulation. The simulator uses virtualization technology to accelerate the execution of Intel virtual platforms on Intel hosts. For other cases, processors use just-in-time (JIT) compilation to run target code. In 2004, an early version of the JIT technology let a Simics Virtual Platform run at 1 GIPS7. Temporal decoupling8 is applied by the simulator core to speed up the simulation.
Multicore hosts can be used to accelerate the simulation. If a target system features multiple networked boards, the Simics simulator can run them in parallel within a single simulation process. Multiple tightly-coupled processor cores can also be executed in parallel within a single simulation process, providing acceleration for multicore and multiprocessor target systems. The JIT compiler and other services will run on their own threads, improving the performance even for single-processor target systems.
In a Simics Virtual Platform, communication between models is typically handled using transaction-level modeling (TLM). Models that are not active processors are event- and transaction-driven. The core scheduler of the Simics simulator provides simple serial semantics to all calls into a model (except processors) even when running in parallel on multicore hosts, avoiding the need to handle threading in typical device model code.
Specific System Models
A key purpose of the Simics simulator is to provide virtual platforms for specific hardware systems. To enable use cases such as BIOS and Unified Extensible Firmware Interface (UEFI) bring-up and the development of operating system drivers, it is necessary to model the precise hardware device semantics and instruction sets of a particular machine. This behavior is different from general-purpose virtual machine systems that provide software with a virtual copy of the underlying hardware. Even when simulating Intel platforms, the virtual platforms correspond to specific processors and chipsets (even though it is flexible in its configuration).
The Simics simulator provides complete isolation between host and target—any target system can be simulated on any supported host, and the semantics of the target system are the same regardless of the host. This means that general-purpose servers, laptops, desktops, or cloud instances can be used to run specific virtual platforms allowing the execution of software stacks just as if the physical hardware was used.
The Simics simulator can model various types of target systems, including everything from cutting-edge systems used in pre-silicon software enablement to very old embedded hardware. The target systems can be small containing a single processor core or huge containing hundreds of networked machines with dozens of different processor types.
A single Simics® Virtual Platform can contain any number of processors of any type. Every model is contained in its own dynamically loaded library, and there is no limit to which models can be used in a particular simulation configuration. Over the years, hundreds of different processor variants have been modeled, including 8-bit microcontrollers, 32-bit embedded processors, 64-bit servers, and oddball digital-signal processors.
Setting up a large simulation configuration can be very complex; current platform models often contain tens of thousands of simulation objects created from thousands of different classes. To manage this, the Simics simulator uses a component system to encapsulate the creation and connection of subsystems. It provides a clear separation between the setup and configuration of a simulated system and the behavior at runtime.
Flexible and Dynamic Framework
The Simics simulation framework is fundamentally dynamic. It is possible to create objects in the simulation and load new model types from the disk at any time. The current configuration can be modified at any time, which allows for the simulation of events like adding boards to a network, inserting a USB disk in a port, unplugging a board from a backplane, or injecting faults. Simulation configuration options, such as the time quantum length for temporal decoupling, can be changed during a simulation.
Simics Virtual Platform models are distributed as binary modules. A module is a dynamically loaded library that can contain one or more classes from which to create Simics objects; typically a module encompasses a model of a hardware subsystem like a network card or processor core or chipset. The modules are packaged and delivered in Simics packages (the public release contains several packages). The simulator core manages the loading of modules from packages, including handling multiple versions of the same module found in different packages.
Module interfaces in the Simics simulator are specified using the host operating system C Application Binary Interface (ABI), which means they are stable and independent of language and compilers. A Simics simulator module can be built using any language and any compiler, as long as they can produce a standard dynamic library for the host and link to an API in C. Standard language support includes C, C++, Python*, the Simics® Device Modeling Language, and SystemC. An interesting special case is to embed existing simulators inside modules and use the Simics simulation framework as a general integration platform9 for multiple simulators from multiple sources.
For scripting, the command-line interface offers an easy-to-use environment for most operations. This includes run control, investigating and changing the configuration, debugging target software, loading and saving state, tracing and instrumentation. The command-line interface provides interactive help, tab completion on commands and their arguments, and can be extended with custom commands. Underlying the command-line interface is a built-in Python interpreter that can be used for more advanced scripting and implementing models, stubs, and tests. The breakpoint system built into the framework provides rich facilities for scripts to react to events and state changes in the simulated system as well as in the simulator.
The Simics application programming interface (API) is available to all users and can be called interactively from the command-line interface using inline Python.