How Simics Gets Started (with video)

????Having 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 a programmatic 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

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.