|
Simics is a full-system functional extensible
hardware simulator. The information on this web site assumes running
simics 3.0.x or greater.
- Full-system means that you can run the entire
system software package, i.e., the operating system, the application
software, on hardware platforms supported by simics.
- Functional means that you can execute most of the
software that runs on the target architecture, and it will function
correctly, i.e., it will compute PI, produce correct output, read and
write files, etc. However, a plain-vanilla simics will not simulate
microarchitectural details of the processor. So your instructions will
run with no delays or optimizations, allowing each instruction to
complete within one processor cycle. If you want to do interesting
simulations with Simics, you need to use simics extensions.
- Extensible means that you can extend simics to
simulate microarchitectural details of your target processor. For
example, you can add a multi-level cache hierarchy, a set of
interconnects, etc. You can even implement your own hardware counters.
Simics comes with its own set of modules allowing to simulate cache
hierarchies (including CMP caches), SMT, and a simple Niagara machine.
A popular set of extension modules GEMS was developed at
University of Wisconsin. GEMS allows simulation of chip multiprocessor
architectures and other cool things.
Getting
started:
- Initialize your Simics
workspace
- Creating your own modules
- Getting
help with Simics
- Apply for a personal academic license
Advanced Simics Topics:
- How to configure a CMP cache architecture
- How to simulate an SMT CPU
- Using existing
Simics configurations
- Copying files to a simulated machine (SimicsFS)
- Making your simulations fast
Initialize your Simics workspace
- Pick a host machine (or
several) where you will run your Simics simulations. Click here
for a list of CPU servers where
you can run simics.
- Register as a Simics forum user on the simics tech site.
- Create
and configure your own workspace
(Use the same steps to update an existing
workspace)
- Create
a directory for your simics workspace, such as ~/my-simics-workpace.
- If you will run Simics on a Linux/x86
host:(oak, cs-app1, cs-app2)
- From ~/my-simics-workspace
run "/cs/systems/Simics/Linux-x86/simics-3.0.26/bin/workspace-setup"
- From
~/my-simics-workspace run "/cs/systems/Simics/Linux-x86/simics-3.0.26/configure --with-host=x86-linux"
- If you will run Simics on a
Solaris/SPARC host(dinosaur, coolthreads)
- From ~/my-simics-workspace
run "/cs/systems/Simics/Solaris-SPARC/simics-3.0.26/bin/workspace-setup"
- From
~/my-simics-workspace
run "/cs/systems/Simics/Solaris-SPARC/simics-3.0.26/configure --with-host=v9-sol8-64"
- Run
simics, make sure everything works
- From
~/my-simics-workspace run "./simics
targets/ebony/ebony-linux-firststeps.simics".
Note: This will pop up an xterm window, so make
sure your DISPLAY variable is set appropriately. For example, if you log in from host1.cs.sfu.ca to
oak.fas.sfu.ca, and you run Simics on oak, on oak execute command "setenv DISPLAY host1.cs.sfu.ca:0.0"
if you use cshell, or "DISPLAY=host1.cs.sfu.ca:0.0;
export DISPLAY" if you are using bash.
Create your own modules
To make changes to Simics, you'd need to create
your own modules, similar to GEMS modules. Simics is a modular
simulator, and it comes with a set of default modules. To find out how
they are implemented, so you can model your modules after, them, check
out /cs/systems/Simics/Solaris-SPARC/simics-3.0.26/src/extensions. For example, a g-cache directory contains a code for a
cache module, sample-memhier - (you guessed) a sample memory hierarchy.
So if you'd like to modify existing simics modules you can copy the
source code into your work space and hack away! To find out how to add
a new module and compile it, refer to the simics
programming guide.
Getting Help with
Simics
The main
sources of help with Simics are:
- Simics
user guides. These include general guides, platform-specific
guides, a programming guide, etc.
- Simics
forum. This is a very important source. Simics documentation
is very spartan, so in many cases you will not be able to find what you
need in the user guides. In that case, post your question to the simics
forum. You will get an almost instantaneous response! Just remember,
the better you formulate your question, the better answer you will get.
Applying
for a Personal Academic License
- Apply
using a link at the simics
tech site.
- You will
be asked to provide the lmhostid of the machine where you will
run Simics.
Find out
the lmhostid by executing the FLEXLM lmutil software
on the host machine where you will run Simics.
- If you run on a Linux/x86 host:
Run "/cs/systems/Simics/Linux-x86/simics-3.0.26/x86-linux/sys/flexlm/bin/lmutil lhmostid "
- If you run on a Solaris/SPARC host
Run "/cs/systems/Simics/Solaris-SPARC/simics-3.0.26/v9-sol8-64/sys/flexlm/bin/lmutil lhmostid"
- For other hardware platforms, download lmutil here.
- If you want to run simics simulations on multiple hosts
you need to apply for multiple licenses. This is perfectly legal.
- Install your personal
license.
- Create a directory <my-simics-workspace>/licenses
- Copy the license file you received from Virtutech to that
directory
- Create
a file ~/.flexlmrc
- In
that file insert the following line: LM_LICENSE_FILE=<my-simics-workspace>/licenses . You
need to specify a full directory name, do not use "~/" to point to your
home directory.
How to Configure a CMP Cache Architecture
Refer to
the section Simics
User Guide >> Advanced Simics Usage >> Cache Simulation
>> A More Complex Cache System in the Simics User guide.
Another example can be found in this posting
on the Simics forum. You can also use
several pre-made scripts for a peanut
target (will work with existing
peanut configurations).
- Single Core:
1 CPU, 16K L1 D-cache, 16K L1 I-cache, 1MB L2 cache
Script location on local FS:
/cs/systems/Simics/Scripts/Caches/D_16K-I_16K-L2_1MB-MEM_200c.simics
- Dual-Core CMP: 2 CPUs, per-CPU 16K L1
D-cache, 16K L1 I-cache, shared 1MB L2 cache
Script location on local FS:
/cs/systems/Simics/Scripts/Caches/2_CMP-D_16K-I_16K-L2_1MB-MEM_200c.simics
- Quad-Core CMP: 4 CPUs, per-CPU 16K L1
D-cache, 16K L1 I-cache, shared 1MB L2 cache
Script
location on local FS:
/cs/systems/Simics/Scripts/Caches/4_CMP-D_16K-I_16K-L2_1MB-MEM_200c.simics
- Dual-SMP-Dual CMP: 4 CPUs, per-CPU 16K
L1 D-cache, 16K L1 I-cache, two shared 1MB L2 caches - each shared by
two CPUs
Script location on local FS:
/cs/systems/Simics/Scripts/Caches/2_SMP-2_CMP-D_16K-I_16K-L2_1MB-MEM_200c.simics
(Note: the above scripts depend on another common script located at /cs/systems/Simics/Scripts/Caches/common.simics)
To configure your simulated system to use on of these caches, run
simics like this:
./simics -stall -c
<configuration> <cache-script>
"stall" option is important for correct simulation of timing due to
cache access.
Alternatively, you can add the cache after you have started your target
system by typing at the simics command prompt:
simics> run-command-file
<cache-script>
How
to Simulate an SMT CPU
Try searching/posting in the
simics forum. A good way to start is by looking at this
post.
Using Existing
Simics Configurations
Simics simulates the actions
of hardware in software, so executing a program on Simics takes much
longer than on real hardware. To save time, you can use existing Simics
configurations, i.e., saved simulator state from which you can continue
the simulation. For example, you may boot the operating system and save
the resulting configuration, then you can use that configuration as a
starting points for running benchmarks on Simics. This way you won't
have to boot the operating system every time you run a new benchmark.
There are several simics
configurations that have been prepared for you by the course
instructor. To run simics with an existing configuration, use the
following command:
./simics -c <path to
configuration files>
Here is a list of available
configuration files for Niagara - all
with SimicsFS installed:
- Niagara 1 core, 1
thread/core:
/cs/systems/Simics/Configs/niagara-1s-config/root-shell.config
- Niagara 1 core, 2
threads/core:
/cs/systems/Simics/Configs/niagara-2s-config/root-shell.config
- Niagara 8cores, 4
threads/core:
/cs/systems/Simics/Configs/niagara-32s-config/root-shell.config
For simulations of CMP and
multi-CMP machines, you can use peanut configurations:
- Peanut 1 core:
/cs/systems/Simics/Configs/peanut-1p-config/root-shell.config
With SimicsFS:
/cs/systems/Simics/Configs/peanut-1p-config/root-shell-simicsFS.config
- Peanut 2 cores:
/cs/systems/Simics/Configs/peanut-2p-config/root-shell.config
With
SimicsFS:
/cs/systems/Simics/Configs/peanut-2p-config/root-shell-simicsFS.config
- Peanut 4 cores:
/cs/systems/Simics/Configs/peanut-4p-config/root-shell.config
With
SimicsFS:
/cs/systems/Simics/Configs/peanut-4p-config/root-shell-simicsFS.config
Copying files to a simulated machine
You
will need to use SimicsFS (see Simics
user guide, section 7.3). Some configurations already have SimicsFS
installed. All Niagara configurations come with SimicsFS.
Configurations for other platforms with SimicsFS installed will have
"simicsFS" in their name. If you need to install SimicsFS, you can use
a script for Solaris 10 simulated machine:
/cs/systems/Simics/Scripts/install-SimicsFS-sol10.simics
Making your simulations fast.
Simics
simulates actions of the hardware entirely in software. Therefore, your
benchmarks will run much more slowly that
on real hardware. Depending on your set-up it may take more than one
hour to simulate one second of real time. Therefore, you want to do
your best to ensure that your simulations run efficiently.
Simics is a CPU-intensive application. Your simulations will run
quickly if your simics application uses a dedicated CPU. When you log
onto a CPU server, check that there are CPUs available by running top. That command will show
you the list of running jobs and their CPU utilizations. If you see
that there are as many CPU-intensive jobs as there are CPUs on that
system, you are better off running your simulation on another machine.
Another
consideration is memory. If there isn't enough physical memory for a
simics run on your machine, the memory will be swapped to disk. This
will significantly slow down your simulation. (A sign that your
simulation is swapping is if your simics instance has CPU utilization
well below 100% check
that by running top.)
If that's the case, you are better off limiting the amount of memory
that simics is allowed to use. To do this, run simics like this: simics -e 'set-memory-limit 500.
|