What is Simics?

Simics is a full-platform simulator used to run unmodified target platform executables. Originally developed by the Swedish Informatics Institute, from which Virtutech was singled out in 1998 for the commercial development of a simulator. In 2010, Virtutech was acquired by Intel, and now Simics is sold by its subsidiary Wind River Systems.

Simics can simulate systems with the architecture of Alpha, x86-64, IA-64, ARM, MIPS (32 and 64 bits), MSP430, PowerPC (32 and 64 bits), 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. The porting of the NetBSD operating system to AMD64 processors was originally implemented using a Simics simulator prior to the public availability of these processors. Often, Simics is used as a virtual software development platform for a specific 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 5.0, it is available for operating systems Windows and Linux.



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



Simics can greatly influence the process of product development, the time to market 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 a product, I want to tell you a little about how Simics looks from the inside. In my opinion, having an idea of ​​how tools work is very useful for an engineer who is 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, since it provides a virtual hardware platform for software running 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 particular virtual machine architecture, while the Simics virtual platform simulates specific hardware. Simics is a tool that allows you to develop software without having the appropriate hardware, while the hypervisor is a way to control hardware during its operation. You can easily run the hypervisor and the operating systems running in it in the Simics simulator. Wind River Hypervisor has even been developed using a Simics simulator .



Hardware that can be simulated using a Simics simulator varies from basic embedded platforms with a single processor or system on a chip, right down to servers and fault-tolerant clusters assembled in racks. The virtual platform is sufficiently complete and accurate to make the target software work as it works on real hardware, and fast enough to use it for ordinary software development work. When I say the word target, I mean the 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 just as they would be on a real machine. The software stack, executed in the simulator, includes everything from the boot code to the hypervisors, operating systems and user applications. The target code is able to run on the simulator without changes (although additional opportunities for code modification are available and are used when they are needed).



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

Inside Simics Simulations

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



The key core of the simulator is the command set simulation systems [orig. ISS], which can model ARM, DSP, MIPS, Power architecture, SPARC, x86 / IA and other processors. However, the processor model itself will not allow an operating system to run on it. For this reason, Simics virtual platforms also include models of memory management units (MMU), as well as memory and other devices that are available to the processor.







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 first transmitted to the memory management unit that provides the physical address. The physical address is used to create a transaction in the Simics simulator.



Next, the transaction goes through the memory card, which determines where the transaction will be sent to. If a transaction enters memory, then the contents of the memory are read or modified.



If the transaction enters the peripheral device, then the 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 device configuration, reboot, send a packet over the network, set a high signal at the output, or do something else. If the transaction does not find the recipient, then the simulated processor can generate an exceptional situation associated with 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 the simulation of the target platform (for example, memory accesses) and messages for the internal actions of the simulator (logging, tracing). In the hardware design community, this type of simulation is known as transactional modeling [http://en.wikipedia.org/wiki/Transaction-level_modeling]. The main feature of this simulation is the use of data movement in the form of transactions, and not the simulation of synchronization timers, conclusions, or other low-level things.



Unlike other virtual platforms, Simics can add objects to the simulation at any 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 dynamically load the necessary modules into the simulator. Simics is very similar to the Java and .NET environment in terms of how objects are compiled, loaded, managed, and connected. This is not static linking, 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 a low-cost operation.



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



To cope with the complexity of the 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, memory devices, connections, and processor cores together into logic 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 hierarchy of components, it is easy to understand the structure of the (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 are not a problem. The largest configurations used by our customers included up to thousands of processors. The longest simulations lasted for many months of guest time. The most heterogeneous simulations include dozens of processors of different 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 Simics base product, you must purchase the Model Builder product, which allows you 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. Usually, the I / O of the target system is automated and reproducible with the help of scripts and various traffic generators. If we consider software changes on the target machine as input, then loading the newly assembled executable files of the target system into the simulated memory and onto the disks is the most important input form that Simics performs itself, without involving the target software. This is far from complete describing 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 scripted command line interface; the ability to write scripts in Python; simple graphical interface; Eclipse-based GUI; connections to debuggers such as Wind River Workbench using WDB and gdb serial protocols. These interfaces allow users to control the target system and debug the software running on it without making changes to the work of the target software.

Extensibility

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



Any Simics user (with the relevant products available to him) can extend the functionality of the simulator with their own modules, for example, modules for collecting tracks, modules for introducing malfunctions [original. fault-injection], to connect with her / his favorite little-known debugger, remote control modules, and even their own graphical interfaces.

Further reading

This blog post could only 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 Simics work [link is original non-working, some can be read here and here , as well as in the issue of the Intel Technology Journal, dedicated to the Simics simulator and its use in Intel].



Also available is my ESC 2008 lesson , dedicated to the simulation of embedded systems and which gives a deeper abstract introduction to the subject of simulation.



[Bonus: interviews with Intel engineers using Simics.]