What is Simics?

Original author: Jakob Engblom
  • Transfer
Simics is a full-platform simulator used to run unmodified executable files of the target platform. It was originally developed by the Swedish Institute of Informatics, from which Virtutech was allocated in 1998 for the commercial development of a simulator. Virtutech was acquired by Intel in 2010 and is now sold by Simics, a subsidiary of Wind River Systems.
Simics can simulate systems with the architecture Alpha, x86-64, IA-64, ARM, MIPS (32-bit and 64-bit), MSP430, PowerPC (32-bit and 64-bit), POWER, SPARC-V8 and x86. A variety of simulated systems have run many operating systems, including MS-DOS, Windows, VxWorks, OSE, Solaris, FreeBSD, Linux, QNX, and RTEMS. Porting of the NetBSD operating system to AMD64 processors was initially carried out using the Simics simulator until these processors were publicly available. Often, Simics is used as a virtual platform for developing software for a particular type of embedded hardware. One of the unique features of the simulator is the ability to play the simulation in the opposite direction.
The current version of the simulator is 5.0, it is available for Windows and Linux operating systems.

You may already know that Wind River acquired Simics, a product previously sold by Virtutech. My colleagues Michel Genard and Bill Graham recently wrote about this.

Simics can greatly affect the product development process, time to market for a product and its quality. In addition to the good features provided by the Simics simulator to improve the development process, the simulator is interesting in itself from a technical point of view. Since I am a marketing manager who has the ability to compile the product, I want to talk a little about how Simics looks from the inside. In my opinion, having an idea of ​​how the tools work is very useful for an engineer considering the possibility of using them or already applying them.

Simics is a simulator - a software solution that simulates hardware. Such a simulator is often called a virtual platform, as it provides a virtual hardware platform for running the software on it. It should be noted that Simics virtualizes embedded hardware in a different way than hypervisors such as Wind River Hypervisor.

The hypervisor expects the operating system running in it to support a specific virtual machine architecture, while the Simics virtual platform simulates specific hardware. Simics is a tool that allows you to develop software without the availability of appropriate hardware, while the hypervisor is a way to control the hardware during its operation. You can easily launch the hypervisor and the operating systems that it runs in the Simics simulator. Wind River Hypervisor has even been developed using the Simics simulator .

The hardware that can be simulated using the Simics simulator ranges from basic embedded platforms with a single processor or system on a chip, right down to servers and failover clusters assembled in racks. The virtual platform is sufficiently complete and accurate to make the target software work the way it works on real hardware, and fast enough to use it for ordinary software development work. When I say the target word, I mean equipment whose work is simulated.

From the point of view of the target software, Simics looks like a real platform. Simics is able to run the same executable files as the physical target system, and execute them in the same way as they would be executed on a real machine. The software stack executed in the simulator includes everything from boot code to hypervisors, operating systems and user applications. The target code is able to be executed on the simulator without changes (although additional opportunities for modifying the code are available and are used when they are needed).

Simics is a regular application. It does not require special equipment, motherboards with FPGA or special emulators. Simics can work on any PC, anywhere, anytime (at least if the PC uses Windows or Linux). You can send a virtual platform implemented using the Simics simulator, literally in an email. Thus, you can replace the hardware boards for development teams located at a great distance from each other, in a magical way.

screenshot of simics windows

Inside Simics Simulation


So what does Simics contain inside, and how is everything implemented there? One of the significant parts of Simics simulation is the simulation of the target equipment. It includes models of processor cores, buses and other connections, models of storage devices, peripherals and network models.

The key core of the simulator is a system of modeling a set of commands [orig. ISS], which can simulate ARM, DSP, MIPS, Power architecture, SPARC, x86 / IA and other processors. However, the processor model alone will not allow the operating system to run on it. For this reason, Simics virtual platforms also include models of memory management units (MMUs), as well as storage and other devices that are accessible to the processor.

simulator circuit with simulator objects and software running inside the simulator

Let's look at how the processor performs the basic operation: memory access. When the processor makes a request to read or write memory, the address is transmitted first of all by the memory control unit issuing the physical address. The physical address is used to create the transaction in the Simics simulator.

Next, the transaction passes through a memory card, which determines where the transaction will ultimately be sent. If the transaction falls into memory, then the contents of the memory are read or modified.

If a transaction enters a peripheral device, then a model of this device is called to process it. Next, the device model performs the necessary actions. It can start a timer, send interrupts to another processor in the system, change the configuration of devices, perform a reboot, send a packet over the network, set the signal to a high value on the output, or do something else. If the transaction does not find the destination, then the simulated processor may generate an exception related to an error on the bus.

If you look at Simics as a program, then everything described above looks like a chain of function calls between the objects that make up the simulated model. In Simics, everything is represented by objects that use function calls to forward both transactions related to modeling the target platform (for example, memory access) and messages for the internal actions of the simulator (logging, tracing). In the community of hardware designers, this type of simulation is known as transaction-level simulations [http://en.wikipedia.org/wiki/Transaction-level_modeling]. The main feature of this modeling is the use of data movement in the form of transactions, and not the modeling of synchronization timers, outputs or other low-level things.

Unlike other virtual platforms, Simics can add objects to the simulation at any given time. You can also reconfigure objects on the fly and change their internal state.

This dynamic configuration makes it possible to simulate everything that can happen in a physical system, including operations such as adding and removing cards from the server rack or changing the configuration of network cables.

In order to support dynamic changes, all objects used in the simulator are created from classes that are loaded dynamically. Each model used in the simulator is defined in its .dll or .so file and can be loaded dynamically. The user does not need to recompile anything to create a new configuration, but only load the necessary modules into the simulator dynamically. Simics is very similar to the Java and .NET environments in terms of how objects are compiled, loaded, managed, and connected. This is not a static link, as in simple C and C ++ programs.

From a practical point of view, the approach used in the Simics simulator has the advantage that each simulation module can be compiled separately, which makes recompiling device models an inexpensive operation.

Simics simulator modules can be written in C, C ++, Python, or in the internal DML hardware modeling language [as well as using SystemC]. DML is a C code generator that automates the generation of template code needed to create a device model. Other programming languages ​​can also be used, provided that they can be linked with modules written in C.

To cope with the complexity of simulated hardware, Simics allows the creator of a virtual platform to use a special kind of object, called a component, to combine objects into logical groups. Components group devices, storage devices, connections, and processor cores together into logical modules corresponding to chips, systems on a chip, specialized integrated circuits, motherboards, mezzanines, server racks, and other hardware nodes. Components can be reused and nested arbitrarily, simulating any type of hierarchy of hardware nodes. Bypassing the component hierarchy, it is easy to understand the structure of a (virtual) hardware system.

What can be modeled?


In fact, Simics can simulate any system. Multiple processors, boards, networks, and heterogeneous computer architectures with multiple guest operating systems is not a problem. The largest configurations used by our customers included up to a thousand processors. The longest simulations lasted many months of guest time. The most heterogeneous simulations include dozens of processors of various types from different families. Multi-core, single-core, symmetric multiprocessing, heterogeneous systems, 8- or 64-bit, Simics was used to simulate all this.

Adding models of new guest systems can be done by Wind River, a Simics user, or third-party consultants. There is no magic here: every Simics user can expand the library of hardware models available in Simics with any components he needs. However, for this, in addition to the basic Simics product, you need to purchase the Model Builder product, which makes it possible to create new guest systems.

Input Output


To enter the simulated system, Simics provides the user with the ability to interact with the serial console and graphic displays of the simulated system. It is also possible to connect simulated serial ports and Ethernet networks with real physical networks. Typically, the input / output of the target system is automated and made reproducible using scripts and various traffic generators. If we consider software changes on the target machine as input, then loading the newly compiled executable files of the target system into simulated memory and onto disks is the most important input form that Simics performs on its own, without involving the target software. This far from complete describes all the possibilities; There are many other (usually application-specific) ways to interact with the simulated system.

For the user, Simics also provides many ways to interact with the simulator itself, including a scriptable command line interface; the ability to write scripts in Python; simple graphical interface; Eclipse-based GUI Connecting to debuggers such as Wind River Workbench using WDB and gdb-serial. These interfaces allow users to control the target system and debug the software running on it without making changes to the operation of the target software.

Extensibility


Everything in Simics is an object, including components responsible for user interaction, connections to debuggers, and even the command line interface itself. All objects in Simics can use the Simics application programming interface and other object interfaces to do anything. This commonality makes Simics very flexible and easily extensible to support new uses.

Any Simics user (with the corresponding products available to him) can expand the simulator functionality with his own modules, for example, modules for collecting traces, modules for making faults [orig. fault-injection], for connecting to her / his beloved little-known debugger, remote control modules, and even their own graphical interfaces.

Further reading


This blog article was only able to superficially describe what Simics can do and how it works. If you wish, you can familiarize yourself with the available technical descriptions of certain aspects of the work of Simics [the link in the original is broken, something can be read here and here , as well as in the issue of the Intel Technology Journal devoted to the Simics simulator and its use in Intel].

Also available is my ESC 2008 lesson on simulating embedded systems and which provides a deeper abstract introduction to the subject of simulation.

[Bonus: Interviews with Intel engineers using the Simics simulator.]

Also popular now: