Simics Device Modeling (Video Demo)

To give a feeling for how modeling works in Simics, we have posted a video on Youtube that shows how a new device is added to an existing machine. In the video, the task is to add a new device to an existing machine and make the driver software for this device happy. To achieve this, we use the Modeling perspective in Simics Eclipse, along with automated unit tests, full-system tests, and user interactive tests. We write code in both Simics DML and Python.

The setup we are building looks like this:

We have an ARM-based QSP machine with two cores and a basic set of peripherals, and add a new device which is a controller for a simple user-facing panel. The panel itself has four colored LEDs that can be turned on and off from the device, and a button input that should cause the device to send an interrupt to the processors of the machine (via the interrupt controller). We also assume that there is a software stack in place that contains a driver for the device, and that the end goal is to make that software driver happy with our virtual platform. This situation is representative for much of real Simics usage and modeling.

In the video, we show how this device is built using the Simics Eclipse GUI, via the stages laid out in the Simics modeling white paper:

• At the beginning, we have the QSP machine along with the user-facing panel.
• Set up a skeleton of the programming register map of the device (using DML)
• Add the device to the machine setup (system memory map)
• Test run with software (ending in a failure since there is no functionality)
• Set up unit tests to describe the functionality of the device (test-driven development, essentially)
• Fill in most of the functionality (we do a fast forward here, just like in a cooking show where you cut from putting a cake in the oven to it being done)
• Rerun unit tests and retest with software to show the device is still slightly incomplete
• Fill in the last piece of functionality
• Rerun unit tests and software test, showing that the device now works as it should

In action, the test run looks like this:

In practice, most Simics modeling is done in a way similar to this video, by adding things to an existing machine. With Simics, it is almost always the case that modeling can start from some existing running system (starting from a QSP quick-start platform like we do in the video or any other existing model). Even when starting from scratch, we quickly build a bare-bones basic running system so that we have something that runs, and then iteratively add new devices to it over time. Simics system modeling is an agile, iterative, and test-driven activity.

When software is not yet available for a new device, the unit tests become the primary driver of the development effort. The tests essentially define the correct behavior of the device. In practice, software drivers will be developed using the device model as their basis, and later the drivers will be used to test the hardware when it arrives in silicon.

For more on modeling with Simics, see the Simics modeling whitepaper.

Device modeling is also a key part of experimenting with target setups in Simics.