Intel® Simics® Simulator

ID 660198
Updated 9/8/2023
Version Latest
Public

author-image

By

About the Intel Simics Simulator Public Release

The Intel® 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 Sweden.1 The Intel 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. Virtutech was acquired by Intel in 2010, with commercial sales handled by Wind River*,3 which was an Intel subsidiary at the time.

From the start,4 virtual platforms running in the Intel 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 Intel Simics simulator and virtual platforms for pre-silicon software enabling and development, computer and system architecture, hardware validation, ecosystem enablement, and more. The simulator framework has proven to be capable of modeling the most complex hardware platforms in existence, including the many firmware-driven engines embedded inside modern systems-on-chips (SoCs). Virtual platforms can integrate and interact with 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 functional Intel 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.

High-Performance Simulation

One of the original core goals of the Intel 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 simulator implements many technologies intended to increase the speed of the simulation. It 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 an Intel Simics Virtual Platform run at 1 GIPS.7 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 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 an Intel 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 provides simple serial semantics to all calls into a model (except the simulated processors cores) 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 Intel 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 on Intel simulation hosts, the virtual platforms correspond to specific processors and chipsets, typically future platforms in development and not available in hardware.

The Intel 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 Intel 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 Intel Simics Virtual Platform can contain any number of processors of any type. Every individual 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 and how they are mixed and connected. 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 typically contain tens of thousands of simulation objects created from thousands of different classes. To manage this, the Intel 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 Intel Simics simulation framework is fundamentally dynamic. It is possible to create objects in the simulation and load new model types into the simulator at any time. The simulator 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.

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 Intel Simics simulation objects; typically a module encompasses a model of a hardware subsystem like a network card, processor core, or chipset. Modules are packaged and delivered in Intel 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 Intel 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 module can be built using any language and any compiler, as long as it can produce a standard dynamic library for the host and link to an API in C. Standard language support includes C, C++, Python*, the Intel Device Modeling Language, and SystemC. An interesting special case is to embed existing simulators inside modules and use the Intel 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 and the simulator.

The Intel Simics simulator application programming interface (API) is available to all users and can be called interactively from the command-line interface using inline Python.

Additional Resources

Intel Integrated Simulation Infrastructure with Modeling

Intel Simics Simulator Public Release

Intel Simics Simulator for Intel FPGAs

References

1Research Institute of Sweden

2Virtutech (Wikipedia article)

3Wind River*

4The Early Days of Intel Simics – An Interview with Bengt Werner

5Shifting Left—Building Systems & Software Before Hardware Lands

6Running “Large” Software on Intel Simics Virtual Platforms, Then and Now

71000 Machines in a Simulation

8Additional Notes about Temporal Decoupling

9The More the Merrier – Building Virtual Platforms for Integration