Add two kernel dispatch-based exit events that are useful for limiting
the simulation and enabling debug flags at specific GPU kernels. Since
the KVM CPU typically used with GPUFS is not deterministic, this help
with enabling debug flags when the Tick number may vary. The exit at GPU
kernel option can also limit simulation by only simulating a few hundred
kernels, for example, and exit at a determined point.
Change-Id: I81bae92a80c25fc38c41e999aa662e1417b7a20d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/71418
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Add `--pmu-dump-stats-on <event>` and `--pmu-reset-stats-on <event>`
options to the Arm `baremetal.py` config to optionally dump and/or
reset stats on various PMU events.
These options allow the user to specify which PMU events should cause
the dumping or resetting of gem5 stats. The available `<event>`s are
PMU `enable`, `disable`, `reset`, and `interrupt`. Both these CLI
options may be specified multiple times to enable more than one event
to cause a stats dump/reset if desired. Stats are dumped before they
are reset.
These options are useful for sampled simulation workloads (e.g.
SimPoints) which are controlled by the PMU.
Change-Id: Ie2ffe11c6aa1f3a57a58425ccec3681c780065c8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69959
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Add an option to add a PMU to the CPUs in `starter_fs.py` and
`baremetal.py`. By default PMUs will not be added.
Also adds an `--arm-ppi-number` option. Each PMU will be connected to
its core using the specified PPI.
Change-Id: I9cfb5781f211338919550f2320a7133d88801f6a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69957
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Currently the amdgpu simulated device is assumed to be a Vega10. As a
result there are a few things that are hardcoded. One of those is the
number of SDMAs. In order to add a newer device, such as MI100+, we need
to enable a flexible number of SDMAs.
In order to support a variable number of SDMAs and with the MMIO offsets
of each device being potentially different, the MMIO interface for SDMAs
is changed to use an SDMA class method dispatch table with forwards a
32-bit value from the MMIO packet to the MMIO functions in SDMA of the
format `void method(uint32_t)`. Several changes are made to enable this:
- Allow the SDMA to have a variable MMIO base and size. These are
configured in python.
- An SDMA class method dispatch table which contains the MMIO offset
relative to the SDMA's MMIO base address.
- An updated writeMMIO method to iterate over the SDMA MMIO address
ranges and call the appropriate SDMA MMIO method which matches the
MMIO offset.
- Moved all SDMA related MMIO data bit twiddling, masking, etc. into
the MMIO methods themselves instead of in the writeMMIO method in
SDMAEngine.
Change-Id: Ifce626f84d52f9e27e4438ba4e685e30dbf06dbc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70040
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Previously the CPU type and memory modes were hardcoded for KVM, because
there was a deadlock bug. After some recent testing, this deadlock bug
no longer exists with the simple CPU models. Thus, changing the configs
to allow for other CPU models as a first step toward lifting the KVM
requirement from GPUFS.
Change-Id: Ib616c3ef60f173871421b55a8bb73b25ce2990b5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69979
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
This file is a required input to the simulator for GPUFS. There seems to
be confusion from several users who are not providing this input. This
usually results in the amdgpu driver failing to load, leading to the
application under test exiting along with it.
This changeset adds a simple md5 hashsum check to compare against the
known good MMIO trace located in the gem5-resources repository.
Change-Id: I59819fc795a6bc4bc6badbd4d120db1246498987
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69978
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
The dmesg level is currently set to 3 which will not display errors if
the amdgpu driver fails to load. Changing to level 8 will show errors in
the gem5 terminal and is not too spammy. This will help GPUFS developers
with bug reports since we would actually be able to observe an error.
Currently if the driver fails to load, there is no way to detect it and
applications will attempt to run, usually failing on getting device
properties.
Change-Id: I56b9581c1a12a8ce329066d18d6a072d006c096d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69977
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Removed the calls to `sys.exit()` from the Arm simple configs. These
calls terminate gem5's embedded Python interpreter and gem5 at the end
of the config script, preventing gem5 from dropping into the
interactive IPython shell when the `--interactive` option has been
specified.
Change-Id: I0c350b0d107f297691255361d25c566c889f9469
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69687
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Only the GICv3 model has a `gicv4` parameter, causing the current
`baremetal.py` config to throw an exception when used with the
VExpress_GEM5_V1 platform containing a GICv2.
This patch checks for the existence of the `gicv4` parameter, allowing
all VExpress platforms to be used.
Change-Id: I72667a9caee64fa497bda516217cd424050eb242
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69685
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
gem5 supports Tarmac trace generation for Arm simulations, but there
are no examples of how to use this feature.
This patch adds a `--tarmac-gen` option to three of the simple Arm
configs. Tarmac generation is useful for out-of-the-box users, and
this patch also provides an example of how to use the Tarmac
generation feature.
Change-Id: I0d3c523b5c0bb6d94de93bc502e4451622fb635d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69684
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I modified the spec-2017 benchmark file to include a
processor.switch() statement (which had been removed
in an earlier commit). I also replaced the use of
get_roi_ticks() with get_tick_stopwatch() as this
particular workload is not annotated with "workbegin"
and "workend" annotations.
Lastly, I fixed a minor bug in the spec-2006 file
which printed the total simulated ticks as zero due
to incorrect indexing of get_tick_stopwatch().
Change-Id: If0b6f88d6701a11f32e2e69994582524e0d7097b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69537
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The call to processor switch from KVM to TIMING was
removed in an earlier commit. This change fixes that.
Also, get_roi_ticks() doesn't work because spec2006
does not have work_begin and work_exit annotations.
This change uses get_tick_stopwatch() to calculate
the roi ticks.
Change-Id: I55efe28ebd686cb4e6c88a528533127fb73c88ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69357
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Add DRAMSys as a new AbstractMemorySystem to the gem5 stdlib.
Also, provide convenient subclasses with predefined DRAMSys
configurations.
Add two new stdlib examples:
- dramsys-traffic.py: Demonstrates the usage of DRAMSys
using the stdlib TrafficGenerators
- arm-hello-dramsys.py: A variant of the arm-hello.py
script that uses DRAMSys as it's memory.
These DRAMSys memory components are only compiled into the standard
library if DRAMSys is not compiled into gem5.
Change-Id: I9db87c41fbd9c28bc44e9d6bde13fc225dc16be9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62914
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
This change refactors the Looppoint files. While functionally
equivalent, this classes have been moved and altered to be easier to
handle going forward. The following changes have been made:
- New classes have been added to represent the data structure of the
Looppoint JSON. This simplifies the parsing of JSON files and makes it
handle Looppoint data structures. Ultimately this is hidden from the
user via the new 'gem5.resources.Looppoint' class which will be the
front-facing class for Looppoint interactions.
- The `LooppointCheckpoint` class has been replaced with
`LooppointCsvLoader`. This new class takes in a CSV pintpoints file
to load necessary looppoint data.
- The `LoopPointRestore` class has been replaced by
`LooppointJsonLoader`.
- All Looppoint classes have been moved to `gem5.resources`. This will
make it easier when we add Looppoints as specific gem5 resources.
Change-Id: I11dd1fe8f76658db220320584270d57cb37a3c62
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67611
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This patches does the following:
- Adds 'SimpointResource' which encapsulates Simpoint data and
functionality. It replaces the old 'gem5.util.simpoint.SimPoint'
class. Simpoints can be loaded from gem5-resources using the
`obtain_resource` function.
- Adds 'SimpointDirectoryResource'. This inherits form
'SimpointResource'. While 'SimpointResource' takes raw Simpoint data
via parameters, 'SimpointDirectoryResource' assumes the data exists
in files, in a directory.
- Updates the
"configs/example/gem5_library/checkpoints/simpoints-se-checkpoint.py"
and
"configs/example/gem5_library/checkpoints/simpoints-se-restory.py"
example files to utilize this new Simpoint resource classes.
**Note**: While the old "SimPoint" class
("src/python/gem5/util/simpoint.py") is marked as deprecated, it may be
difficult to utilize given updates to the APIs in the gem5 stdlib Cores
and Simulator modules.
Change-Id: I9bed5c643ffc735838c9f22a58c53547941010e7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67339
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
An example case,
```python
mem_side_port = RequestPort(
"This port sends requests and " "receives responses"
)
```
This is the residue of running the python formatter.
This is done by finding all tokens matching the regex `"\s"(?![.;"])`
and manually replacing them by empty strings.
Change-Id: Icf223bbe889e5fa5749a81ef77aa6e721f38b549
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66111
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The "test-gem5-library-example-riscvmatched-fs" test, which runs
"configs/example/gem5_library/riscvmatched-fs.py", was running the
script in full. This takes a very long time. Given we already have boot
tests for RISCV, it's better to just run this configuration to just the
end of the Linux boot (significantly faster than a full OS boot). This
patch adds this feature to the config script and modifies the test to
utilize it.
Change-Id: I1e37a26aab5e9a127ebd64590be79fbc16fe53aa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65853
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously the scalar cache path used the same latency parameter as the
vector cache path for memory requests. This commit adds new parameters
for the scalar cache path latencies. This commit also modifies the model
to use the new latency parameter to set the memory request latency in
the scalar cache. The new paramters are '--scalar-mem-req-latency' and
'--scalar-mem-resp-latency' and are set to default values of 50 and 0
respectively
Change-Id: I7483f780f2fc0cfbc320ed1fd0c2ee3e2dfc7af2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65511
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
This patch:
- Makes this function private.
- Updates the function's documentation.
- Changes the 'init' parameter to 'board_initialized'.
It doesn't make much sense for this function to be exposed directly to
the user as it requires knowing whether the board is initialized or not.
In addition to this I believe it makes more sense for the 'init' logic
to be flipped and renamed "board_initialized' so that this value is True
if the board has been initialized.
The documentation for this function has been updated.
Change-Id: I016c65bde88357111d3e648d7aa99aeb6e31f410
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64833
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The "config/example/gem5_library/arm-ubuntu-boot-exit.py" script is
renamed to "config/example/gem5_library/arm-ubuntu-run.py". This makes
it more consistent with similar scripts in the
"config/example/gem5_library" directory: "x86-ubuntu-run.py" and
"riscv-ubuntu-run.py".
Change-Id: I9d96fd68e122f2841573b1717b0969cd44972771
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65132
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Through working with the gem5 stdlib there have been instances where
connecting the memory, processor, and cache hierarchy to the board (via
the AbstractBoard's `_connect_things` function) at the point of the
AbstractBoard's construction is problematic as the memory, processor,
and cache hierarchy may require information to connect correctly that is
only known to the AbstractBoard after construction. In particular this
can occur when a Workload contains information needed to configure
correctly.
To resolve this problem the `_connect_things` function has been moved to
run as a pre-initialization step. That is, run immediately before
`m5.instantiate`. This is done in the Simulator module.
This will break cases where a user utilizes the stdlib AbstractBoard but
does not use the stdlib Simulator module. As such, an Exception is
raised in these cases explaining the fix to the user. This is done via a
hack where the boards' `createCCObject` function (inheritted
from SimObject) is overriden with a check to ensure `_connect_things`
has been run. To fix the `_pre_instantiate` function must be executed
prior to `m5.instantiate` in the Python configuration script. Test and
config scripts in the gem5 repo have been updated accordingly.
Change-Id: Ibaef36eb7433ce104b861b1da80fc600f08f715a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65051
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The KVM CPU hangs if there are not multiple event queues when more than
one CPU is created. Since GPUFS primarily relies on the KVM CPU, support
for multiple event queues is needed. Some GPU libraries, such as AMD
Research's ATMI library, assume more than one CPU.
This changeset adds support for multiple CPUs and was tested for up to
four CPUs.
Change-Id: Ia354e02209d0fa18195f3ad44f4fb1d58e93b5ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65131
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
It never made much sense to set checkpoint via the Simulator module as
Checkpoints are very tightly coupled with the Workload being run. This
change therefore moves the checkpoint to the set_workload functions.
Setting checkpoints via the Simulator is deprecated and will be removed
in a future release.
Change-Id: I24d2133b38a86423d3553ec888c917c5fe47b93d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64571
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
