Jakob Engblom: Simics 4.6 Initial Impressions

Simics 4.6 is now out, and I would like to share some of my initial impressions of the new Simics version.

The most visible new feature is probably the Simics source code debugger in Eclipse. Source code debug might seem a yawn, but the way it has been integrated with Simics provides some new and unique abilities that at least I have never seen before in a debugger. Most importantly, the debugger works on the system level with a single debug connection.

An example is shown in the screenshot below, where we have two machines in the same Simics simulation - "Tuna" is a dual-core Power Architecture P2020 running VxWorks, and "Herring" is a dual-core Intel Architecture Pentium 4 running Wind River Linux.

OS awareness shows the active processes, tasks, and threads, and you can see which threads are active on which processors. This is very convenient for multicore multithread debugging. You can debug both from the hardware view and the software view of the system.

Obviously, reverse execution is fully supported. We even highlight the last few instructions so the direction of execution is clear:

The debugger also allows the Simics backend to take control over the execution. This means that you can set breakpoints and write and run arbitrary scripts on the Simics command-line, and then have the debugger update its view whenever and wherever Simics stops the execution. All the existing advanced breakpoint features in Simics can be used, and the source code debugger just makes it easier to understand what is going on in the target software. This gives us a debugger that combines the power of a virtual platform command-line debugger with the convienience and overview of an Eclipse visual debugger.

There is another small but very useful improvement to the Simics user interface. When you use Simics checkpoints (see for example blog and blog), you can now add text annotations to the checkpoint. This makes it so much easier for a user to understand what a checkpoint contains and why it was created. The checkpoint is also automatically annotated with who created it, when, and on which machine. Some of this metadata has been present in Simics checkpoints for the past few versions, but not exposed to users until now. In the screenshot below, you can see an example from one my demonstrations. It shows a checkpoint that captures an intermittent bug, and which was created a few years ago on an old machine I no longer use, and in Simics 4.2. It opens nicely in 4.6, and the bug behavior is exactly the same.

Without checkpoint annotations, you would have to provide this information in some README file or in an email, and it could easily lose its association with the checkpoint. With checkpoint annotations, Simics checkpoints become much easier to communicate between people and between teams. Checkpoints can also be handled by workflow system and checked into source code repositories with the metadata integrated and available for inspection.

Yet another user interface addition is the new system panel build kit, which lets you build models of typical board front panels as part of your Simics hardware models. It can also be used to build arbitrary dashboards to display information about a target, based on custom scripts and trace modules. The screenshot below shows a simple panel for a board with 10 LEDs, a configuration switch, and a reset button. We also see the software animating the LEDs running in the debug view, as the tLedAnimate task in VxWorks.

Apart from these highly visible additions, just like with every release of Simics, Simics 4.6 contains many small fixes and improvements. We are constantly trying to remove little annoyances and make the tool easier and more logical to use.

One example that I like particularly is the introduction of a general way to describe OS awareness nodes in Simics scripts. You can now specify that you want to track a certain thread by its OS process ID or by the name of the binary. You can ask OS awareness to return all tracked software units in a system that match a certain criteria (like "all threads inside the process called rule30 inside an OS called vxworks"). Previously, users had to manually scan the process lists to find what they needed, now they can essentially use Simics to do "find" over the entire simulation. For setups involving a hypervisor, multiple guest operating systems, and hundreds or thousands of active processes, this is a huge usability benefit. It also makes automating things with OS awareness much easier.

There are many other new and improved things in Simics 4.6, but I have to stop somewhere. However, there is one final thing that I have to include. Simics now supports Windows 64-bit hosts. This is very beneficial to Simics users on Windows, as the better register model on 64-bit x86 provides an immediate speedup for the simulator. It also makes it practical to run much larger simulations on Windows host, thanks to removing the 32-bit addressing limit.