Simics 5 is Here - More Parallel than Ever

The next major release of Simics is here. Simics 5. Not Simics 5.0, but Simics 5. Counting decimals was getting a bit old, we computer science guys prefer our numbers as integers, not floating point.  Regardless of the numbering, we have some great news in this new release. Chief among them is the new Multicore Accelerator feature that makes this release the most parallel in Simics history, but we have plenty of other news as well, addressing better access, more automation, and more collaboration.

Multicore Accelerator

Simics 5 introduces multicore accelerator, where Simics can use a multicore host to simulate a tightly-coupled multicore or multiprocessor target. Since the launch of Simics 4.0 in 2008, Simics has been able to simulate multiple discrete target machines or racks on multiple host cores, we call this functionality multimachine accelerator, and it is still a part of the Simics performance technology suite. Simics 5 takes this to the logical next step of splitting apart the boards and SoCs for parallel execution –multicore accelerator.

We will get back to multicore accelerator in more detail in a future blog post, but suffice to say that it seems to scale well for computationally-intense workloads, and it provides useful speed-ups for other types of workloads such OS boots as well.

In addition to multicore accelerator, we have also improved the performance of Simics OS awareness. While preserving existing functionality, the performance of the Simics Analyzer functionality powered by OS awareness will improve, in particular for systems with many processes and many task switches.

Increased performance is always important to Simics users, since it determines what  kinds of software loads can be usefully run in simulation within the time frames given by interactive usage, automatic testing, or continuous integration turn-around times.

Checkpoint Server – Improving Collaboration

The checkpoint server is a new collaboration tool that helps users exchange Simics checkpoints in a simple, fool-proof, and efficient way. Up until now, users had to collect the files necessary to run a checkpoint by themselves, and share it over a network file share or other mechanism. Using the checkpoint server makes collaboration much easier, as sharing a checkpoint is as simple as sending the URL of the checkpoint on the server to the recipient.

Here is an example of how it can work:

The checkpoint server and client take care of getting the checkpoint (R in the illustration above) and all its prerequisite checkpoints and disk images to the recipient machine. If some previous checkpoint or disk image that is needed is already in place on the receiving end, it is not downloaded again. Thus, only the minimum amount of data is transferred and stored, speeding up the process. This mechanism exploits the inherently incremental nature of Simics checkpoints – P and R in the illustration only store the difference between themselves and the previous state. This radically reduces the amount of data that needs to be stored and transferred.

Another benefit of the checkpoint server is that a Simics checkpoint stored on a server has a unique ID and a URL. This means that it is possible to refer to the checkpoint from bug tracking systems, send them in emails, etc. It really enables collaboration and the feedback loop I showed in an earlier blog post about continuous integration.

Fault Injection – Automating Tough Test Cases

Fault injection is a very powerful capability of Simics and simulation platforms in general (see some previous blog posts for more on fault injection and Simics: 1, 2, 3, 4).  Simics 5 introduces a new framework to make it easier to create fault injectors that support record, replay, repeatability, and reverse debugging, and that make it easier for users to discover and apply fault injectors to their systems.

The new fault injection framework standardizes how fault injectors are written, how to attach them to a system, and how to enable and disable the actual faults. Previously, faults were typically implemented in a mix of command-line scripts and Python, in an ad-hoc manner specific to each case. With the new framework, fault injectors should be more regular, and uniformly support features such as recording the faults injected for precise replay.

Script Parameters – Better Automation and User Interface

The Simics target system setup process has been improved with the addition of a way to explicitly declare the available customization parameters to Simics scripts. Up until now, you would set Simics command-line variables to customize the behavior of a script, without much help in finding the available parameters and their meaning. It worked like Unix shell scripts – a user or another script would set $x-style variables, and a script would read them and use the values. But there was no way to find the available variables without reading the source code for the script and all scripts that were invoked.

With the new system, parameters have names, documentation, and types that make it possible to type-check parameters for correctness before using them. The parameters can be queried and set both when starting Simics from the command-line, and from within Eclipse.

Here is a screenshot showing some of the parameters available for the QSP ARM system with VxWorks 7. Note the use of groups to reduce the clutter of parameters, and the type and documentation for the selected parameter shown.

Modeling Improvements – Collaboration between Workflows and Access to Models

Simics 5 debuts the new Simics SystemC library, which is an entirely new way of integrating SystemC models with Simics. The SystemC library makes it possible to run existing SystemC and SystemC TLM-2-compliant models in Simics, using the Simics command-line and Eclipse GUI to inspect and control the model. System models are typically built using Simics instruction-set simulators and board models, interfacing to SystemC models for particular hardware devices – including using cycle-accurate and AT-style SystemC models.

The SystemC library provides a set of ready-to-use “gaskets” that provide a way to expose SystemC interfaces to the Simics framework, without having to write any conversion code either on the Simics or SystemC side. Adapting a SystemC model to run inside of Simics is just a few lines of code related to registering the SystemC model with the Simics run-time system.

A common use case for Simics with SystemC is to use Simics to provide a fast model of a platform, while SystemC is used to write detailed timing models of some piece of hardware. The new SystemC library makes it easier to support this kind of simulator integration and mixed-level setups, making Simics models useful for tasks in hardware design and validation.

Simics 5 offers improved debugging of Simics and Simics models. Debugging a Simics process works in Eclipse as well as from the command-line. Using a customized version of gdb, there is debugger support for Simics DML, including inspecting the types and values of DML variables and setting breakpoints and stepping through DML source code.  As always, debugging Simics supports models and extensions written in C and C++. Python code debugging is supported using PyDev. The screenshot below shows an example of debugging a Simics DML model in Eclipse.

New Installer

Starting with Simics 5, Simics installation will use the Wind River installer used by all other Wind River products. This brings a new level of convenience to Simics installation – with the Wind River installer, all you need to do is to download a single installer file, and that will in turn download and install all other parts of the product.  Users no longer need to know the particular packages that they should download, nor install each package manually.

The Wind River installer fully supports offline installations as well, since we know that our customers often need to be able to download and install Simics into installations that are truly offline.

Eclipse GUI Improvements

Simics Eclipse has been updated to Eclipse 4.4, and Simics Eclipse now has a Log view that displays log messages from the simulated target system. This makes it easier to peruse the log messages that Simics emits during a run, and keeps the Simics command-line interface interaction cleaner, as can be seen in the screenshot below. It is also easier to read the logs when displayed in a structured table.

Summary

Simics 5 builds on the existing feature set of Simics, improving performance, making Simics easier to install and use, and adding collaboration and automation features. We have added features to make it easier to get value out of Simics, in particular for supporting Agile methods and continuous practices.