How Simics Gets Started (with video)

By Jakob Engblom

?Engblom_lgHaving worked with Simics for more than a decade, it is easy to get blind to the obvious. To me, starting a Simics simulation is a trivial thing that I do many times per day. However, to a newcomer to the product, it is not so obvious, and it might even seem a bit daunting. It is not daunting, and it is not difficult, as shown in this video on YouTube.

As can be seen in the video, we start Simics sessions by invoking a target setup script or opening a checkpoint. This can be done from Eclipse, from a command-line, or from the old Simics stand-alone GUI. Whether on Windows or Linux host, the same options are available. No matter how you do it, the end result is the same. The same Simics engine is used in all cases, interpreting the startup script in the same way.

Starting simics 0

If we look behind the top level of Simics start scripts demonstrated in the video, what we find is aprogrammatic model for system creation and configuration. Simics setup is done using code and scripts, and not using static configuration files.

There are actually three levels of programming in a Simics setup. At the basic level, we have device models, which implement the functionality of the simulation. These are grouped into Simics components (which are also discussed in my previous blog post on inspecting and configuring a Simics simulation), like shown in the picture below:

Starting simics 1

The components are little Python programs that create their contents using arbitrary control flow, which means that it is very easy to build components that can vary the number of cores in a setup (for example, our QSP boards can be configured with 1 to 128 cores using the exact same component, just providing a different parameter for the number of cores, and the component code creates the cores and wires them up to the interrupt controller and memory using a simple loop). If a component was a static configuration, this would be incredibly hard to do.

Components also usually create their subordinate components. In the example as shown above, creating the “System” component would generate all its subordinate components. However, a more common model is that the top level of a simulation is a collection of separate components, representing separate physical entities, looking something like this:

Starting simics 2

While it is possible to manually construct a system by creating components by hand (as shown in another YouTube movie), this is both pretty tiresome and not a good way to create flexible and reusable setups. For this reason, all Simics sessions are in practice started from Simics scripts that contain script commands that create the components and often connect them to each other (in the peer-to-peer non-hierarchical fashion of Ethernet networks).

The Simics scripts also perform another crucial task. They add the software to the target machines, by inserting contents into boot flash, putting images into disks, or just pushing a bootable binary into target RAM. Along with the software, there are often script snippets that do things like type configuration and boot commands on boot prompts, change the boot command line of Linux, and do similar tasks. Often, many different startup scripts use essentially the same hardware, but with different software loads.

Scripts can call other scripts, and this is often used to setup configurations that contain collections of existing setups. For example, the setup shown above would most likely be created in this way, using a master script that calls into the scripts that create Board 1, Board 2, and the Ethernet between them. It would also connect the Ethernet ports of the boards to the Ethernet link to make sure they can communicate.

Starting simics 3

This programmatic model of configuration has enormous expressive power, in particular since the scripts can also take parameters and contain loops and conditional statements. For example, this code creates an arbitrary number of machines, with unique hardware Ethernet MACs and software IP addresses (automatically configured from the startup scripts for the individual boards):

local $mac = (split-string -type ethernet $mac_address)
local $ip  = (split-string -type ipv4 $ip_address)
foreach $count in (range $machine_count) {
$host_name = ("%s-%d" % [$host_name_base, $id])
# Compute MAC addresses, numbered continuously from 86:41:00
$mac_address = "%02x:%02x:%02x:%02x:%02x:%02x" % $mac
$mac[5] += 1
$mac_address1 = "%02x:%02x:%02x:%02x:%02x:%02x" % $mac
$mac[5] += 1
$mac_address2 = "%02x:%02x:%02x:%02x:%02x:%02x" % $mac
$mac[5] += 1
$mac_address3 = "%02x:%02x:%02x:%02x:%02x:%02x" % $mac
$mac[5] += 1
# IP address increase by just one
$ip_address = "%d.%d.%d.%d" % $ip
$ip[3] += 1
# Call the board setup file to create a board with the parameters
run-command-file -local "%script%/mpc8641-simple-linux-2.6.23-common.simics"
$id += 1

So we can see that the simple act of calling a Simics script to start a simulation can unleash a virtual avalanche of automatic smart activities behind the scenes.

A checkpoint will contain the state of the system, as created by the startup scripts and further evolved by the system execution and user interaction. There are no Simics scripts in checkpoints, only the configuration components and all the device models they created. The components are inactive at this point, since they only run code during the system setup process. However, they still provide the hierarchical namespace used to navigate a Simics simulation, as clearly seen in the System Editor.

For additional information from Wind River, visit us on Facebook.