Getting Started With Simics
Getting Started With Simics
Simics
Revision 3094
Date 2011-01-19
© 2006–2011 Virtutech AB
Drottningholmsvägen 22, SE-112 42 Stockholm, Sweden
Trademarks
Virtutech, the Virtutech logo, Simics, Hindsight, and Virtualized Systems Development are
trademarks or registered trademarks of Virtutech AB or Virtutech, Inc. in the United States
and/or other countries.
The contents herein are Documentation which are a subset of Licensed Software pursuant to
the terms of the Virtutech Simics Software License Agreement (the “Agreement”), and are
being distributed under the Agreement, and use of this Documentation is subject to the terms
the Agreement.
This Publication is provided “as is” without warranty of any kind, either express or implied,
including, but not limited to, the implied warranties of merchantability, fitness for a particular
purpose, or non-infringement.
The proprietary information contained within this Publication must not be disclosed to others
without the written consent of Virtutech.
Contents
1 Introduction 5
1.1 Who Should Read This Document? . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Tutorial 16
4.1 Launch Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Reverse Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5 Getting Files into a Simulated System . . . . . . . . . . . . . . . . . . . . . . . 24
4.6 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8 Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6 Next Steps 72
Index 73
Introduction
This document provides users new to Virtutech Simics a quick introduction on how to effec-
tively use Simics. It describes the concepts and benefits of Virtualized Systems Development
when used to develop software, and the products in the Simics family. It also provides a
tutorial and links to other Simics documents that will help you to become effective with
Virtutech Simics.
1.2 Conventions
Let us take a quick look at the conventions used throughout the Simics documentation.
Scripts, screen dumps and code fragments are presented in a monospace font. In screen
dumps, user input is always presented in bold font, as in:
Sometimes, artificial line breaks may be introduced to prevent the text from being too
wide. When such a break occurs, it is indicated by a small arrow pointing down, showing
that the interrupted text continues on the next line:
This is an artificial
line break that should not be there.
The directory where Simics Base package or any add-on package is installed is referred to
as [simics], for example when mentioning the [simics]/README file. In the same way,
the shortcut [workspace] is used to point at the user’s workspace directory.
Virtualized Systems Development (VSD) is product development without the use of, or
need of, the target hardware platform that the software will eventually run on. For example,
if the product’s software is being developed for a target system that contains a PowerPC
processor, an Ethernet controller, RapidIO, a UART and other peripherals, each developer
of the software team would typically need this target hardware configuration in order to
debug and test their software (see Figure 2.1). When target hardware is in short supply, or
not available, this obviously becomes a bottleneck for the software development team.
With Virtualized Systems Development, the target hardware is virtualized (i.e., simu-
lated) and runs on each developer’s development workstation. To the target software, the
virtualized target hardware behaves exactly the same as the physical target hardware (see
Figure 2.2). Virtualized System Development Platform Target application code, the real-time
operating system, drivers, firmware, all can be debugged, tested, and executed using the vir-
tualized target hardware instead of the physical target hardware. Furthermore, a virtualized
• behavioral simulation of all devices in the target hardware that the target software
interacts with;
• connections between, and among, simulated targets and the real-world (e.g., networks
like Ethernet, MIL-STD-1553, ARINC 429, SpaceWire, FireWire, USB, ATM, and other
mechanisms like disk images, memory images, etc.); and
• the ability to use the same tools (e.g., compilers, linkers, debuggers, IDEs, and RTOSs)
and processes that the software developer would use with the physical hardware.
Furthermore, to be truly useful for software development and testing of the entire target
software stack, a virtualized systems development platform must be fast enough to execute
the target software. This is what differentiates a virtualized systems development platform
from simulation tools provided by the electronic design automation (EDA) industry. These
tools, while extremely accurate from a hardware implementation perspective, often are not
fast enough or complete enough to run the entire target software stack.
to fix. They may be difficult to pinpoint because they are not deterministic (they do not
exhibit the same behavior each time) or are sporadic. In addition, it may be difficult to
determine if the bug is due to a real software problem or is caused by an underlying
hardware problem. Using virtualized systems development platform features such as
advanced breakpoints/watchpoints and reverse execution can significantly reduce the
time it takes to find these bugs. Furthermore, once the bug is found, a snapshot of the
execution leading up to the bug can be taken so that the bug can be easily reproduced,
and thus fixed, by another person on the development team.
Debug Application SW
Agent RTOS
Firmware
Debugger
Ethernet or
Serial
Connection
VSD Platform
sufficient memory for a target debug agent or the user does not want the application software
to be affected by the presence of a debug agent.
During these times, the software developer either relies on other forms of debugging
(such as a hardware trace or probe), or uses a special debugger that attaches to a JTAG port
on the physical target.
The VSD platform contains an API that allows debuggers to communicate directly with it
eliminating the need for a Target Debug Agent and JTAG.
Application SW
RTOS
Firmware
Debugger
VSD
API
Direct
Connection VSD Platform
• Defining and validating the hardware/software interfaces early in the process before
the hardware goes to prototype.
• Developing, debugging, and testing low-level software on the virtual target while the
hardware prototypes are being built.
• Having low-level software, RTOS, firmware, drivers working before prototype hard-
ware is available so that when it becomes available, only a few days are needed to bring
up the prototype hardware.
• Having the high-level application developers use the same set of tools and processes
that the low-level software developers use to avoid incompatibilities and inconsisten-
cies that are usually discovered during integration.
• Integrating the high-level software with the low-level software before the entire physical
system is available or working.
• Creating and running system integration tests before the entire physical system is
available or working.
Significant improvements occur when the entire product development team incorporates
VSD into their process. Cost savings occur because multiple iterations of prototype hardware
can be reduced or eliminated. Time to market and risk reductions occur because software
and hardware can be developed simultaneously. In addition, the ability to try out virtual
hardware changes on the software without need for physical hardware prototypes allows for
much quicker feedback and supports true iterative development.
The Simics product family is made up of multiple products and optional add-on products.
This section defines what these products are and how they interact with each other. Please
contact Virtutech directly for the licensing terms of each product.
boards and many processor, Simics Accelerator can dramatically enhance the simulation
speed and scalability.
The speedup for any particular target system setup will vary with the capacity of the host
machine, as well as the properties of the target system hardware and software.
Tutorial
This tutorial is a step-by-step guide describing how to perform some common tasks with
Simics Hindsight. The guide is based on a simplistic target computer similar to Freescale’s
MPC8641 HPCN platform. Not all devices on the HPCN platform is modeled, therefore it is
named MPC8641-Simple. The MPC8641-Simple is a simulated Power Architecture MPC8641D
(with two e600 cores) board running a very small Linux installation.
In order to follow this tutorial, you need to install the Firststeps add-on package, which
contains the MPC8641-Simple board. A detailed explanation is provided in the Simics Installa-
tion Guide.
Note: This tutorial requires version 4.2.3 or later of the Firststeps package. If you get license
errors when trying to follow it, please ask your Virtutech representative for a new license, or
post a request on the Simics forum.
• On Windows, you launch Simics via the Start menu, in the Virtutech Folder.
Since you start Simics for the first time, a dialog box will pop up (figure 4.1), asking you
where to create a workspace. As a Simics installation can be shared among many users, it
should preferably be kept read-only. Workspaces are personal areas where Simics will keep
your own settings and where you can store all your working files. So pick a directory and let
Simics make a workspace out of it.
Once the workspace is created Simics will start. If this is the first time you run Simics,
you will be asked to register to be able to participate on the Simics support forum. Then
the Simics Control window opens (figure 4.2). The Simics Control window contains the icon
toolbar and all the menus that control Simics, as well as a summary of the current simulation
session. From its menus you can open additional windows. For this tutorial you need the
Simics Command Line. Select Tools → Command Line Window to open it.
The Command Line window allows you to interact with Simics. Simics will print there
warnings and error messages, and you as a user can enter commands to inspect and modify
the simulation. Anything that can be done via the menus of the Simics Control window can
also be done in CLI. Several of the features demonstrated in this guide makes use of CLI, as
you will see later on.
Create a new session with the MPC8641 firststeps target machine by clicking New
session from script . Open the mpc8641-simple directory and choose the file mpc8641d-
simple-linux-firststeps.simics. After a few seconds, the Simics Control window
should show you a summary of the simulated system you have just loaded, and a new
window should have popped up, called Serial Console on mpc8641d_simple.soc.uart[0] (see
figure 4.4).
This new window is part of the simulation: it is connected to the serial port of the
simulated MPC8641D-Simple board. All output from the simulated machine will be displayed
here. It is also here that you can interact with the simulated software, as opposed to the
Simics CLI window, which is used to control the simulation itself.
So in our example:
[...]
simics> continue
... the simulation is running ...
running> stop
[cpu0] v:0x07fd395c p:0x007fd395c xor r3, r11, r9
... the simulation is now stopped ...
simics>
If you let the simulation run for a while, you will see target system printing out the boot
process messages in the serial console. The simulation can be stopped at any time by entering
the stop command or clicking on Stop in the toolbar. When stopping, the simulation will
finish the current executing instruction to leave everything in a consistent state.
After some time, Linux will be up and running and you will obtain a command line
prompt in the serial console.
You can now try typing a few commands on the prompt:
/ # cat /proc/cpuinfo
processor : 0
cpu : 7448, altivec supported
revision : 0.0 (pvr 8004 0000)
bogomips : 1581.05
chipset :
processor : 1
cpu : 7448, altivec supported
revision : 0.0 (pvr 8004 0000)
bogomips : 1581.05
chipset :
Note: If the serial console does not respond, make sure that the simulation is actually
running, for example by clicking Run Forward.
4.3 Checkpointing
In order to avoid booting Firststeps every time we need it, we use the facility known as
configuration checkpointing or simply checkpointing. This enables Simics to save the entire state
of the simulation to disk. The files are saved in a portable format and can be loaded at a later
time.
To write a checkpoint:
running> stop
simics>
2. Click on Save Checkpoint. Press the Up until you reach the workspace, name the
checkpoint after_boot.ckpt and press Save. The complete state is now saved.
1. Select File → New Empty Session and confirm that this is indeed what you want to
do.
2. Click on Open Checkpoint and open the after_boot.ckpt file. After a few sec-
onds, the entire simulation is restored, including the serial console contents. Remember
to resume the simulation (by entering continue or clicking on Run Forward) before
typing more commands at the console.
You can read more about configuration and checkpointing in Advanced Features of Simics.
simics> enable-real-time-mode
simics>
This will cause the virtual time to never progress faster than the real time and also reduces
how much host processor Simics use. See help enable-real-time-mode for further informa-
tion on this. You can read more about performance in Simulation Performance chapter in
Advanced Features of Simics.
To enable reverse execution, you just need to click on Enable/Disable Reverse Execu-
tion. In reality, what this button does is to create a time bookmark called “start”, which in some
ways is similar to a checkpoint. The reverse execution engine keeps such bookmarks and
some additional information to jump from one bookmark to another and simulate backward
in time.
In CLI, reverse execution is enabled by creating a time bookmark with the set-bookmark
command:
/ # rm /bin/ls
/ # ls /
-sh: ls: not found
The program ls has been removed. You can no longer print out the contents of a directory.
Let us use reverse execution to recover ls.
To prove to ourselves that reversing actually works, let us take a look at how much virtual
time has passed so far. For this purpose, we can use the ptime command:
simics> stop
simics> ptime
processor steps cycles time [s]
mpc8641d_simple.soc.cpu[0] 8123456213 8123456213 10.154
simics>
As shown above, we have now simulated about 6 second back in the past.
Another way is to actually run the simulation backwards. You can click on Run
Reverse and you will quickly find yourself back to the moment where you enabled reverse
execution (i.e., the first time bookmark). This will be slower than skip-to, but on its way back
toward the past, it will do all sort of useful things like triggering breakpoints, and this will
prove very useful when debugging.
In any case, the system is now in the state it was before the file was erased. Lets run
forward again.
simics> c
When you type something in the terminal, you will notice that it does not respond any
longer! But you will see the same commands as before being replayed. This behavior is
intentional, and keeps the deterministic property of the simulation, which is invaluable when
debugging. Keystrokes, network traffic and any other input is replayed until the last known
time is reached. In our example, this is not what we want. To erase all knowledge about the
future, run the clear-recorder command.
simics> stop
simics> skip-to bookmark = start
simics> clear-recorder
simics> c
/ # ls /
bin etc host linuxrc proc sys
dev home lib lost+found sbin var
/ #
The ls command is back! You can read more about reverse execution in Using Simics
Hindsight for Software Development.
/ # mount /host
[simicsfs] mounted
/ # ls /host
AUTOEXEC.BAT CONFIG.SYS
Documents and Settings IO.SYS
ntldr MSDOS.SYS
pagefile.sys NTDETECT.COM
Program Files RECYCLER
System Volume Information WINDOWS
[...]
/ #
The exact output of the last command depends on your host system. The output in the
example above is from a Windows machine.
In the next section we will explore some of the available debugging features. For that
purpose we need to transfer the program we are to debug to our MPC8641-Simple target
machine. The file is located in the Firststeps add-on package.
Note: The example above is done on a Windows host and corresponds to the stan-
dard installation directory for the Firststeps add-on package. On Unix, you would
try to look in /host/opt/virtutech/simics-4.2/simics-firststeps-4.2.0/
targets/mpc8641-simple/images/
The file debug_example is now in the target system. At this point, you probably want
to stop SimicsFS and save a checkpoint.
/ # umount /host
You can read more about SimicsFS and other ways to transfer files in Using Simics
Hindsight for Software Development and Advanced Features of Simics.
4.6 Debugging
This section demonstrates some source-level debugging facilities that Simics provides. The
Firststeps add-on package contains an example code snippet called debug_example.c,
located in the targets, mpc8641-simple directory. We recommend opening the file
debug_example.c in an editor of your choice to follow the debugging example more easily.
This file contains the code that we are going to debug. The program is supposed to print
some information about the users on a system.
In the previous section we copied the executable into the simulated system by using
SimicsFS. Now, run that program in the serial console:
/ # ./debug_example
[...]
Got segmentation fault!
/ #
This output indicates that our program crashed. Let us use Simics features to debug it.
Simics supports symbolic debugging and OS awareness which allows you to debug processes
running on Linux. To set this up just enter the following command:
This will set up Simics to track the next process on the target which runs a program called
debug_example, and allow symbolic debugging of that process.
To help debugging your programs, Simics can recognize magic instructions, that is, instruc-
tions that have no side-effects on a real machine, but can be programmed to do things when
run inside Simics, such as stopping the simulation. The debug_example code contains such
an instruction at the beginning of the main() function. Type the following to make magic
instructions stop the simulation:
simics> enable-magic-breakpoint
simics> c
Now, make sure that reverse execution is enabled and re-run debug_example:
/ # ./debug_example
Simics will stop as soon as the magic instruction is executed. The CLI window should
display the message magic breakpoint. Click on Debug → Disassembly to open up a window
with the instructions the processor is currently running. The magic breakpoint instruction
should be marked.
You can also view the current source code by clicking Debug → Source View. Since the
debug_example binary was compiled in a directory that either does not exist at all on your
host system, or that does not contain the source code debug_example.c, Simics will not be
able to find the source code without a little help: select the source file by clicking Find. . . and
browse to debug_example.c. You can also use a more dynamic approach where part of
the path in the debug information encoded in the binary is replaced with a path you specify:
The command above basically says: whenever the path /tmp is found in the debug infor-
mation, replace it with C:\\Program Files\\Virtutech\\Simics 4.2\\Firststeps
4.2.0\\targets\\mpc8641-simple. You can get more information about the hsymtablei.source-
path command using help:
Note: These source code gymnastics are only necessary because debug_example was not
compiled on your machine. When you compile your own programs, everything will work
right out of the box.
Now that we have pointed Simics to the source code, the Source Code window should
contain the source code of debug_example. The current line should be line 73, MAGIC_
BREAKPOINT, indicated by a small arrow next to the line number (figure 4.7).
Let us find the cause of the segmentation fault. Place a breakpoint on the sigsegv_
handler() function. The sigsegv_handler() function is called when the program receives a
segmentation fault and will allow the program to exit gracefully.
Resume the simulation. It will stop at the signal handler, and by running the stack-trace
command, you can see the chain of function calls leading up to this point. This list gives you
useful hints about where the crash occurred.
simics> c
Code breakpoint 1 reached.
simics> stack-trace
#0 0x10000520 in sigsegv_handler (sig=0)
at [...]\targets\mpc8641-simple\debug_example.c:35
#1 0x7fd9a338 in ?? ()
#2 0xfef4514 in ?? ()
#3 0xfefcebc in ?? ()
The stack-trace is also accessible via Debug → Stack trace (figure 4.8).
Figure 4.8: Stack trace when the segmentation fault was caught
Simics prints a ? when no symbol could be found for a given address. This can either be
a bogus address or a function inside the standard library, for which no symbols have been
loaded. The Source Code window has been updated and the current line now points to the
sigsegv_handler() function (figure 4.9).
A few frames down you will find the main() function, which caused the crash. Let us
run the simulation backward into that function. The command reverse-step-line will run
backwards until the previous known source line is reached.
simics> reverse-step-line
[mpc8641d_simple.soc.cpu[0]] v:0x10000578 p:0x02ff81578 bl 0x10010c44
main (argc=1, argv=0x7ffffe44)
at [...]\targets\mpc8641-simple\debug_example.c:82
82 printf("Type: %s\n", user.type);
Figure 4.9: Source view when the segmentation fault was caught
This line caused the crash (see also figure 4.10). Let us examine what user.type contains:
As you can see, the type member points to an unreadable address, which caused the
crash. Where does that value come from? What we want to find is where the last write to
this pointer occurred. Let us set a write-access breakpoint on the memory occupied by the
pointer and then run backward (using reverse) until the breakpoint is reached:
simics> stack-trace
#0 0xff26ea4 in ?? ()
#1 0x100005d8 in read_developer (p=0x7fd9ac30, f=0x10011008)
at [...]\targets\mpc8641-simple\debug_example.c:60
#2 0x10000674 in main (argc=1, argv=0x7fcbceb4)
at [...]\targets\mpc8641-simple\debug_example.c:80
#3 0xfecc97c in ?? ()
#4 0xfecca8c in ?? ()
#5 0x0 in ?? ()
simics>
A call from read_developer() at line 60, has caused the pointer to be corrupted. Switch to
that frame and display the code being run.
simics> frame 1
#1 0x100005d8 in read_developer (p=0x7fd9ac30, f=0x10011008)
at [...]\targets\mpc8641-simple\debug_example.c:60
simics> list read_developer 15
48 {
49 char line[100], *colon;
50
51 if (fgets(line, 100, f) == NULL)
We can also use the Stack Trace window to select the frame; doing so will update the
Source Code window as well (figure 4.11).
On line 60, while the name field was filled in using strcpy(), our failing pointer was
accidentally overwritten (remember that the breakpoint was placed on the type member). If
you issue the command psym line, Simics will print out the string copied: "shutdown".
A look into the declaration of struct person shows that the name field is only 8 bytes
long, and hence has no space for the trailing null byte of shutdown. Check the contents of p
after and before the actual write to verify it is overwritten:
To clean up after our debug session, we must remove the breakpoints that we have set.
They are identified with a number and can be shown using list-breakpoints.
simics> delete 1
simics> delete 6
simics> disable-magic-breakpoint
simics>
You can read more about debugging in Using Simics Hindsight for Software Development.
4.7 Tracing
Tracing is a way to observe what is going on during the simulation. This section describes
how to trace memory accesses, I/O accesses, control register writes, and exceptions in Simics.
The tracing facility provided by the trace module will display all memory accesses, both
instruction fetches and data accesses.
Launch the mpc8641d-simple-linux-firststeps.simics configuration, but do
not boot it yet. Start by creating a tracer:
simics> new-tracer
Trace object 'trace0' created. Enable tracing with 'trace0.start'.
simics>
simics> c 500
[mpc8641d_simple.soc.cpu[0]] v:0xfff03060 p:0x0fff03060 sync
simics> trace0.start
Tracing enabled. Writing text output to standard output.
simics> c 10
inst: [ 1] CPU 0 <v:0xfff03060> <p:0x0fff03060> 7c0004ac sync
inst: [ 2] CPU 0 <v:0xfff03064> <p:0x0fff03064> 4800074d bl 0xfff037b0
inst: [ 3] CPU 0 <v:0xfff037b0> <p:0x0fff037b0> 3c80ff70 lis r4,-144
inst: [ 4] CPU 0 <v:0xfff037b4> <p:0x0fff037b4> 60840000 ori r4,r4,0x0
inst: [ 5] CPU 0 <v:0xfff037b8> <p:0x0fff037b8> 3ca0f800 lis r5,-2048
• Lines beginning with inst: are executed instructions. Each line contains the address
(both virtual and physical) and the instruction itself, in both hexadecimal form and
mnemonic.
• Lines beginning with data: indicate that some instructions are performing memory
operations. Each line contains the operation address (again, both virtual and physical),
the type of operation (read or write), the size and the value.
It is also possible to only trace accesses to a certain device. This is done with the trace-io
command. In this example we are looking at the interaction with the UART device.
simics> trace0.stop
Tracing disabled
simics> trace-io mpc8641d_simple.soc.uart[0]
simics> c 72_500
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4501 SZ 1 0x0 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4503 SZ 1 0x83 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4500 SZ 1 0x8f (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4501 SZ 1 0x0 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4503 SZ 1 0x3 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4504 SZ 1 0x3 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4502 SZ 1 0x7 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Read from mpc8641d_simple.soc.cpu[0]: PA 0x4505 SZ 1 0x60 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4500 SZ 1 0xd (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Read from mpc8641d_simple.soc.cpu[0]: PA 0x4505 SZ 1 0x60 (BE)
[mpc8641d_simple.soc.uart[0] trace-io] Write from mpc8641d_simple.soc.cpu[0]: PA 0x4500 SZ 1 0xa (BE)
[mpc8641d_simple.soc.cpu[0]] v:0xfff11440 p:0x0fff11440 blr
simics>
Note: You can use underscores anywhere in numbers to make them more readable. The
underscores have no meaning and are ignored when the number is read.
We can single-step with the -r flag, to see what registers each instruction changes:
Output from the trace commands can be controlled with the log-setup command. For
example each log message can be prepended with a time-stamp, indicating the processor,
program counter and the step count when the event occurred.
Simics can also monitor exceptions. Here we will trace all system calls with a time-stamp:
Note: There are variants of trace-io, trace-cr and trace-exception that will stop the simula-
tion when the respective event occurs. These commands begin with break-.
4.8 Scripting
The Simics command line has some built-in scripting capabilities. When that is not enough,
Python can be used instead. Restart Simics with mpc8641d-simple-linux-firststeps.
simics to follow the examples in this section. We will use a trace object as our example:
simics> new-tracer
Trace object 'trace0' created. Enable tracing with 'trace0.start'.
simics>
There are two commands available for this object: htracei.start and htracei.stop. For
example, to start tracing:
simics> trace0.start
Tracing enabled. Writing text output to standard output.
simics>
It is also possible to access an object’s attributes using CLI. The state of an object is
contained in its attributes:
simics> trace0->classname
"base-trace-mem-hier"
simics> trace0->enabled
1
simics>
Variables in CLI are prefixed with $, and can hold a string, a number, or an object
reference. In the following example the variable my_tracer references our trace0 object (i.e., it
is not a copy of the trace object).
It is also possible to access the tracer from Python. All lines beginning with a @ are
evaluated as a Python statement.
The Simics API is directly accessible from Python. The script below counts the number of
instructions that are executed until the register msr is modified. It imitates the functionality
of break-cr msr.
This section provides a complete description of the Simics Hindsight Graphical User Interface
(GUI). On Windows, starting Simics through the Start menu will automatically bring up
the GUI. On Unix, this is achieved by running the simics-gui script, whether from a
workspace or directly from the Simics installation directory.
The first time the GUI is running, it will propose to create a workspace for storing your
working files. This is a good suggestion, but if you want to know more, you can refer to the
Workspace Management section in the Simics Installation Guide.
Simics Control
This is the control window: it provides all the menu entries and icons to control Simics.
It also describes the currently loaded simulation (see also section 5.2).
Many other windows are available via the menus, depending on your needs. They will be
described later in this chapter.
The Simics GUI is based on the concept of a simulation session. When Simics is started, no
session is active. Sessions are begun and ended using menu commands or toolbar buttons.
Note: In practice, each session corresponds to running Simics from the command line with
a given target configuration. However, it is possible to run several sessions in sequence
without quitting the Simics GUI.
When the simulation is running, the title of the control window will change to Simics
Control: Running (see figure 5.2). The status bar at the bottom of the window shows the
virtual time elapsed since the start of the simulation. It will also provide information on the
current execution status when running with reverse execution enabled.
5.2.1 Toolbar
The toolbar in the Simics Control window offers quick access to the most commonly used
commands. The following icons are available:
Open Checkpoint. . .
Opens a previously saved checkpoint in Simics. You will be asked to provide a
checkpoint file to open. Note that this will start a new session and automatically close
the previous session.
This is equivalent to the File → Open Checkpoint. . . menu entry. You can also read
an existing checkpoint using the read-configuration command at the prompt, but you
must close the existing session first.
Save Checkpoint. . .
Saves the current simulation state in a checkpoint file. You will be asked to provide a
name for the checkpoint to save. You can later open this checkpoint to restore the state
of the simulation using the Open Checkpoint. . . button.
This is equivalent to the File → Save Checkpoint. . . menu entry. You can also save a
checkpoint by using the write-configuration command.
Run Reverse
Runs the simulation backward in simulated time. This button is only active when
reverse execution is enabled for the current simulation (see below).
This is equivalent to the Run → Run Reverse menu entry. You can also run backward
using the rev command at the prompt.
Stop
Stops the simulation at the current virtual time.
This is equivalent to the Run → Stop menu entry. You can also stop the simulation by
entering the stop command at the prompt.
Run Forward
Runs the simulation forward.
This is equivalent to the Run → Run Forward menu entry. You can also run the
simulation forward by using the continue or c command at the prompt.
This is equivalent to the Run → Reverse Execution Enabled switch. You can also start
the reverse execution mechanism using the set-bookmark command at the prompt. To
stop it, use the command delete-bookmark -all.
name for the checkpoint to save. You can later open this checkpoint to restore the state
of the simulation using the Open Checkpoint. . . menu entry. This is equivalent to the
Save Checkpoint toolbar icon.
File → Exit
Terminates the current session and quit Simics (Notice on Unix the keyboard shortcut
is Ctrl+Q).
Debug → Disassembly
Shows the Disassembly window, which presents the CPU execution in assembly instruc-
tions. This window is described in section 5.8.
Debug → Stack Trace
Shows the Stack Trace window, which shows the stack trace of the currently running
process. This window is described in section 5.17.
Debug → Source View
Shows the Source View window, which follows the source code of the current process,
if enough information is available. This window is described in section 5.16.
Debug → CPU Registers
Shows the CPU Registers window, which presents the contents of various CPU registers.
This window is described in section 5.5.
Debug → Device Registers
Shows the Device Registers window, which presents the contents of various device
registers. This window is described in section 5.6.
Debug → Memory Contents
Shows the Memory Contents window, which presents the contents of physical and
logical memory spaces. This window is described in section 5.7.
Help → Contents
Opens the Help Browser which contains all the Simics on-line help (including all Simics
manuals). This window is described in section 5.10.
Help → License
Displays the Simics Software License Agreement.
Help → About
Describes the current version of Simics and all the configured add-on packages.
The Console window shows the output of the simulated machine. It can be graphical, as
shown in figure 5.11, or text-based, as shown in figure 5.1 . Note that the graphics console
can also emulate a text console, which is the case when booting a simulated PC. Usually the
graphics or the text console object is called con0, when you want to use commands.
Note: If the console is attached via a simulated serial line, as is the case for the simulated
Sarek and Donut machines, the window can be resized using the following sequence of
commands:
simics> con0.close
Closing console window.
simics> con0->width = 128
simics> con0->height = 60
simics> con0.open
Opening console window.
To make the simulated machine understand that the console has changed its size, you would
use a command like stty rows 60 cols 128 (once again, this example is for simulated
Solaris).
• On Unix, special X11 key combinations usually continue to work though so watch out,
Ctrl-Alt-Backspace might still kill your X server.
• On Windows, some key combinations that have special global effects, (such as Ctrl-
Escape to bring up the Start menu and Alt-Tab to switch programs) will retain their
usual effect and are not grabbed by the console window.
To release the mouse, just press Shift and right click again. Note that regular keystrokes
will be sent to the simulated machine whenever the console window is in focus, even when
the mouse is not captured.
If you want to change the keyboard/mouse combination to capture the mouse, use the
command console.grab_setup. Use help console.grab_setup to find the available options
for this command. Usually the commands will be written as con0.grab_setup.
To avoid sending keystrokes and mouse movements to the simulated computer by ac-
cident, the command console.disable-input can be used. This will prevent the graphics
console from passing on any input events to the target. To enable input again use con-
sole.enable-input.
The graphics console window is not guaranteed to exactly match what would be seen on
a real display. For example, if the target system is running in 24-bit color depth and the host
display provides only 16-bit, the colors values will be scaled down and some information
will be lost.
In most cases the dimensions (in pixels) of the graphics console exactly matches those
of the simulated display, i.e., a simulated 640x480 display will pop up as a window with
dimensions of 640x480. This means that the aspect ratio of the simulated display sometimes
will be incorrect. For example, when simulating a 640x480 display on a 1280x1024 host
display, the simulated display will be a little bit shrunk in the vertical direction.
To capture the contents of the graphics console to a file, use the console.save-bmp com-
mand.
Note that there is a graphics device in the simulated machine which is a separate entity
from the graphics console; the graphics console displays what the graphics device has drawn.
The display of the graphics console is not updated for every access to the video card but at
regular target time intervals, so the graphics seen in the console might not always match what
is actually in the video memory of the simulated graphics card. To refresh the console display,
use the command graphics-device.redraw (which usually translates into vga0.redraw). The
refresh rate can also be set using the graphics-device.refresh-rate [rate] command, where
rate is measured in times per target second. Keep in mind that since the time measured is
target time, the real world refresh rate depends a great deal on what code is being executed
on the simulated machine.
control-a:
go to the beginning of the input prompt.
control-e:
go to the end of the input prompt.
control-k:
cut out the text on the right of the cursor.
control-y:
paste the contents of the clipboard at the cursor.
control-f:
move the cursor forward one character.
control-b:
move the cursor back one character.
control-n:
recall the next history entry.
control-p:
recall the previous history entry.
control-t:
switch the order of the two characters on each side of the cursor.
control-w:
delete a word to the left of the cursor.
control-d:
delete a character to the right of the cursor.
Using the prompt, you can type any command available in Simics, and you can even write
scripts via the custom command line scripting or Python. For more information, read the
Command Line Interface and Scripting chapters in Advanced Features of Simics.
Information
The class of the object will be indicated first, followed by the class description. The
rest of the information is object-specific. In our example, it describes the type of flash
memory configured (8-bits bus with no interleave, AMD command-set).
Status
The Status panel contains current information about the object state. In the case of
our flash memory, it simply shows that the flash memory is in read-array mode at this
point, which means that it behaves like normal memory for read operations.
Attributes
The Attributes panel contains a list of all attributes that constitute the state of the
object. Attributes represent both the static state (like configuration parameters) and the
dynamic state (like the current operation, etc.). Clicking on an attribute will show its
current value, its kind (Required, Optional, etc.), its format and its documentation in
the bottom fields.
The Configuration Browser is also linked to the Object Browser (see section 5.11). By double-
clicking a component you open it in the Object Browser.
A Statistics Plot window (figure 5.24) lets you plot statistics collected by Simics. Specifi-
cally, some Simics objects publish data on how a scalar value (such as the simulation speed)
changes over time, and the plot window displays the changing value graphically.
In the Sources menu, you are presented with a selection of the available statistics sources—
Simics objects that publish statistics. The sysmon data source is always available, and
provides statistics about Simics itself, such as host CPU usage or simulation speed (shown in
the screen shot). Other data sources include g-cache, which publishes cache statistics such
as read misses, write misses, etc.—but note that most configurations do not come equipped
with caches by default. You can add cache g-cache based caches yourself, but such models
should only be added when detailed cache and timing information is needed.
You may open any number of plot windows. Each plot window can plot multiple data
sources at once, as long as they have the same y-axis units. If you select a source that is
incompatible with one you have already selected, the new source will replace the old.
The Memory Mappings Browser window (figure 5.25) shows you the memory spaces in
your configuration with the devices mapped into them. The window is divided into two
major parts. The left part is a tree which shows all the memory spaces in the system and how
they are connected to each other and the right part a table which shows the devices mapped
into the memory space. Select a memory space in the tree to the left to inspect it in the table
to the right.
In the tree control with the memory spaces the roots of the trees are the memory spaces
which are physical memories of processors in the system, memory spaces not mapped into
any other memory spaces and finally, just to make sure all memory spaces are shown, all
memory spaces not reachable from any of the first two sets. There is no division between
the three categories of roots, but they are sorted. First all the physical memories are shown,
then unmapped memory spaces and finally the rest. Each memory space is present as a child
of every memory space it is mapped into. If you have cycles between the memory spaces
the cycle will be broken the second time the same memory space is present in a branch from
the root. This node in the tree will not have any children, but you can still see all the devices
mapped into it in the right part of the window.
The table with devices mapped into the memory space lists all the banks mapped into
the memory space. A bank in this case can be either a device, a port of a device or a function
of a device. Each line contains the start address of the bank, the name of the bank, the size of
the window, the offset in the bank where this window is placed and finally, if the mapping is
a translation mapping, the target of the translation. Below the table there is a button which
opens a memory contents viewer for the memory space. See section 5.7 for documentation
about the viewer it opens.
Appearance Panel
The Appearance (figure 5.26) panel let you define how input and output will be handled:
• On Windows, you can opt for standard Windows shortcuts, or Unix Readline
shortcuts (i.e., Emacs-like).
• On Unix, you can choose between standard GTK shortcuts or the Readline short-
cuts.
Output Format
The output format option box lets you decide how Simics should show numbers like
addresses or CPU registers in the Command Line window. You can choose in which base
numbers will be displayed by default, and how numbers in a specific base should be
printed out, inserting some “_” (underscores) to increase their readability. Note that
you can always type “_” inside numbers if you wish to, they will be ignored by the
command line regardless of these settings.
Progress Counter
This option controls what is shown in the status bar of the Simics Control window.
Virtual time is common to the whole simulation, and is counted in seconds since the
simulation was set up. Instruction counter and virtual load on the other hand, applies
to the first CPU created in the simulation. The instruction counter shows the number
of instructions executed by the CPU since the simulation was set up, while the virtual
load shows how busy the CPU is at this point of time.
Startup Panel
The Startup panel (figure 5.27) lets you control how Simics should behave when started:
Startup Options
Execution Mode controls the type of CPU models that will be created when starting a
new session. Stall CPUs are slower models that have interesting capabilities in terms
of improved timing and instruction or data profiling. You can find more information
on these in Advanced Features of Simics and—in the Model Builder package—Advanced
Memory and Timing in Simics.
Enable reverse execution on startup controls whether reverse execution is enabled by
default or not when starting a new session.
Enable multithreading on startup controls whether multithreading is enabled by de-
fault or not when starting a new session.
GUI
This box controls two aspects of how Simics handles its GUI. The first controls whether
you can open windows when running Simics in command line mode and the second
which windows Simics should open at start up.
Advanced Panel
The Advanced panel (figure 5.28) provides control over more advanced features:
License File
By default, Simics looks for a license file in its own installation directory, under the
licenses directory. You can also specify a license file by providing it here.
Miscellaneous
Log commands to file controls whether Simics will create a log file for all commands
entered in the command line window. This log file is available in ˜/.simics/4.2/
log on Unix and in Application Data\Virtutech\Simics\4.2\log in your
personal folder on Windows.
Auto-start simulation will tell Simics to start a simulation directly after loading it,
instead of waiting for you to press the Run Forward button.
The Swap directory will be used by Simics when running simulations requiring a lot
of memory. By default, Simics will not use swapping, but if you ask it to do so, it will
store temporary files in the directory indicated here. See Advanced Features of Simics for
more information on memory usage and swapping.
The Source View window is shown in figure 5.29. When Simics is stopped, it shows the
source code surrounding the current instruction. An arrow in the left margin indicates the
source line containing the current instruction.
In order for this feature to work, the current context of the current processor (shown in
Context) must have access to debug symbols for the running program. Using Simics Hindsight
for Software Development explains how to set this up.
Next Steps
This Getting Started with Simics guide has provided an introduction and overview of the
Simics platform and Virtualized Systems Development. To become more familiar with the
features and capabilities of Simics, you should review the additional documentation that is
provided.
Software developers who want to learn about the software debugging capabilities pro-
vided with the Simics platform should read the Using Simics Hindsight for Software Development
manual, and particularly the chapter regarding debugging with Simics.
Because Simics can be used as a back-end to many existing software debuggers, you
should review the appropriate chapters in the Using Simics Hindsight for Software Development
to understand how to use Simics with your particular software debugger.
If you want to learn more about Simics simulation models or want to create or modify
your own model, then you should review the Modeling Your System in Simics manual, and
particularly the tutorial provided in this manual. Note that Modeling Your System in Simics is
only available to those who purchased the Simics Model Builder product.
F L
File menu, 42 License, 48
Append from Checkpoint, 43 license, 68
Append from Script, 43 License File, 68
Change Workspace, 43 list-breakpoints, 33
Create Workspace, 43 Load Persistent State, 43
Exit, 43 log, 68
Load Persistent State, 43
New Empty Session, 42 M
New Session from Script, 42 magic breakpoint, 26
Open Checkpoint, 42 magic instruction, 26
previous files, 43 Memory Contents, 45, 54
Quit, 43 Memory Mappings Browser, 46, 64
Run Python File, 43 memory usage, 68
Save Checkpoint, 42 Minimize All Consoles, 46
Save Persistent State, 43 Miscellaneous, 68
first-steps, 16 Model Builder, 14
frame, 31 mouse, 49
Multithreading, 13
G multithreading, 68
Getting Started, 47 enable/disable, 44
Go to Address, 57
Graphics Console, 49 N
GUI, 68 New Empty Session, 42
New Session From Script, 40
H New Session from Script, 42
Hap Browser, 46, 57 New Statistics Plot, 46
haps, 57 new-tracer, 33
Help, 57 Next, 57
index, 57
search, 57 O
help, 26 object, 57
Phone +1 408-392-9150
Fax +1 408-608-0430
http://www.virtutech.com