Gem 5: Final Report:

Members: Pedro Osorio Lopez

Introduction:

In this project, we decided to learn about gem5, a full system simulator which is used for
experimentation and research by the computer architecture community. What makes this platform
particularly especial over other options is the fact that it simulates actual hardware. Simulating other
systems using a specific architecture (such as using an x86 processor to simulate a RISC-V architecture) is
not possible on a real hardware, since adding those extra components would have a high fabrication
cost and clearly be inefficient. Therefore, in this project, we will provide an in-depth explanation about
the way gem5 manages to make this possible, then we will use it to make an experiment in which
different architectures will be used within the same system to run a file, and finally we will analyze the
results using the knowledge we acquired during this course.

Behind Gem5:

Gem5 is a system simulator platform, which is actually a combination of two software: m5 and GEMS.

M5 is a simulator system developed by the university of Michigan, whose primary purpose is to allow
evaluation of computer system design ideas involving hardware modification without the need to
actually build the hardware. It is built with multiple CPU modules (for the different architectures) and
also possess a classic memory model in which the processor and the software interact with each other
as master-slave (a technology of asymmetric communication in which a device known as master controls
other devices known as slaves, as it was mentioned during this semester).

On the other hand, GEMS (also known as Multifacet’s General Execution Model Simulator) was built by
the university of Wisconsin. This system is arguably a little more complex than m5, presenting a ruby
memory model; a framework that plays an essential role at controlling which variable writes can be
observed by a particular read. In simple words, it can be considered as a simulated memory subsystem
with the ability to allow parallelism. Moreover, GEMS also features a flexible interconnection system
known as Garnet 2.0 (which provides a cycle-accurate micro-architectural implementation of a network
router) and several coherence protocols.

Putting things together, the whole gem5 platform works as an event driven simulator. The actions in this
system are represented as events, and these are stored in a queue where a specific time is attached to
them. An example of this model is shown below:

Let’s suppose that we are looking for an address, in a similar way to what we covered in this class with
the caches. In the first step, the core sends a request for an access A, which would be Event 1 and gets
timecoded as “1” (assuming that the beginning is in the first clock cycle). After the request is sent, the
next step would be searching whether this address can be found in the L1 cache, which would
correspond to the second clock cycle. Supposing we get a cache hit (which we can call Event 3 or reply
event), the L1 cache controller would send this block back to the core and then generate another event.

As it was previously mentioned, gem5 is also a full system simulator. By this, we mean that the software
is able to execute both user level codes and kernel codes. Being able to do this allows gem5 to simulate
a complete system; in order words; it can virtually implement an electronic device and its operating
system. We will refer this as full system mode (FS mode).

Nevertheless, this is not its only functionality. Gem5 also features a SysCall Emulation mode. The main
difference between this mode and the one that we previously covered, is that in this case only the user
codes are executed while the kernel is mostly emulated. In other words, now we are simply simulating a
device (the hardware), but not the operating system (software). In any case, we can consider our device
to be the host machine and the device we are simulating, the simulated machine.

Gem5 is written under two programming languages: C++ and Python. The working of this platform can
be explained as follows: First step is installing gem5. Then, gem5 will take a simulation script (written in
Python), which is basically what it will be used to set up the configuration of the simulated machine.
Depending on which kind of device we want to simulate, there are different types of scripts available to
us. Once gem5 takes this input or script, it will generate and build a simulated machine. An output file
(called stats.txt) can be found inside the m5 directory of gem5, which will display the behavior of the
simulated machine, implemented in C++.
As explained above, a simulation script is required to build a simulated machine. This scripts have two
phases: the configuration phase (which is the one containing the specifications of the machine that we
are trying to build), and the simulation phase (which contains the necessary information to build the
simulated machine). The procedure can be explained as follows: the configuration from the script
written in python is read by gem5. Then, the script gets converted into c++ structures, and finally these
end up getting passed to c++ objects which will be used to model the system behavior. These simulated
objects usually represent physical components of the simulated machine, such as cache or main
memory.

The system simulator features two modes several possible combinations. The modes, as previously
mentioned, are the SysCall or System emulation (SE) and the Full System (FS). Surprisingly, it also allows
to simulate two CPU models, in-order, and out-of-order; two memory models, Classic and Ruby; and two
interconnection networks, simple and garnet.

Gem5 can be used in different platforms & requires a few dependencies in order to be properly used.
The main OS in which the simulator can be installed are Linux and MacOS, although it can also be used in
others such as BSD or Solaris. As for the dependencies, there are mainly seven that will be completely
necessary to install: