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>
The
'configs/example/gem5_library_checkpoints/simpoints-se-checkpoint.py'
example would dump the savepoint in the CWD. This is fine when running
as an example, but we also run this script as a test. In this case the
checkpoint litters the repository.
To fix this, an optional 'checkpoint-path' argument is added to this
example which specifies where the checkpoint is to be saved. In the
tests, the checkpoint is saved to 'tests/gem5/resources'. This is our
default location for resources needed/produced by tests and is ignored
by git.
Change-Id: I3dccc574b9e64d32386fd822ed7248ee365a0a08
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64092
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The
'configs/example/gem5_library_example_tests/test_gem5_library_examples.py'
example would dump the savepoint in the CWD. This is fine when running
as an example, but we also run this script as a test. In this case the
checkpoint litters the repository.
To fix this, an optional 'checkpoint-path' argument is added to this
example which specifies where the checkpoint is to be saved. In the
tests, the checkpoint is saved to 'tests/gem5/resources'. This is our
default location for resources needed/produced by tests and is ignored
by git.
Change-Id: Ib985433786c99c37794a1c67cc4337a5dfd0498d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64091
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Previously the L1 request and response latencies were not configurable
in the GPU config scripts. As a result, the simulations used the default
values from GPU.py. This commits adds support to change this value as an
input parameter. The parameters to use are "--mem-req-latency" followed
by the value and "--mem-resp-latency" followed by the value. The default
values are the same as those in GPU.py (which is 50). These new
parameters should be set instead of changing the mandatory queue latency when configuring the L1 cache.
Change-Id: I812d77758ea12530899953f308c91f4c8b05866d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63971
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Previously the LDS bus latency was not configurable in the GPU config
scripts. As a result, the simulations would use the default value from
GPU.py. This commit adds support to change this value as an input
option. The option to use is "--vrf_lm_bus_latency".
Change-Id: I8d8852e6d7b9d03ebec1fe8b392968f396dd3526
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63652
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair.wisc@gmail.com>
Support has been added for SDMA RLC queues which are used for host to
device and device to host "memcpy" calls. Previously the SDMA engine was
disabled which caused GPU BLIT kernels to be called. This removes the
environment variable disabling SDMAs which has two main benefits:
- It will be much easier to debug host/device transfer by using SDMA
debug flag.
- Simulation time is improved since we no longer need detailed GPU
simulation to copy data and instead are doing a simple large DMA
Change-Id: I7524245731d301b5c26394318f2156ed6b4c983a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62717
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
simpoints-se-checkpoint.py & simpoints-se-restore.py:
These are two example scripts to show how to use SimPoints functions with
the stdlib.
se_binary_workload.py:
Allow se_binary_workload to take in SimPoint Class item and schedule
SimPoint exit events.
exit_event.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit events.
simulator.py:
Added SIMPOINT_BEGIN and MAX_INSTS exit event scheduling functions.
They can schedule exit events before or during the simulation.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1259
Change-Id: Iaa07a83de9dddc293b9f1a230aba8e35d4f5af6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63154
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The TARGET_ISA variable would let you select one ISA from a list of
possible ISAs. That has now been replaced with USE_ARM_ISA, USE_X86_ISA,
etc, variables which are boolean on or off. That will allow any number
of ISAs to be enabled or disabled individually. Enabling something other
than exactly one of these will probably prevent you from getting a
working gem5 binary, but those problems are being addressed in other,
parallel change series.
I decided to use the USE_ prefix since it was consistent with most other
on/off variables we have in gem5. One noteable exception is the
BUILD_GPU setting which, you could convincingly argue, is a better
prefix than USE_. Another option would be to use CONFIG_, in
anticipation of using a kconfig style config mechanism in gem5.
It seemed premature to start using a CONFIG_ prefix here, and if we
decide to switch to some other prefix like BUILD_, it should be a
purposeful choice and not something somebody just starts using.
Change-Id: I90fef2835aa4712782e6c1313fbf564d0ed45538
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52491
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The environment variable HSA_ENABLE_INTERRUPT controls if Interrupt or
busy wait signals are used in the ROCm runtime. Interrupts are not being
sent in gem5 causing simulations to hang indefinitely in certain
situations. To fix this, always disable interrupts to fall back to busy
wait signals. Using interrupts is an old and simple optimization to not
waste CPU cycles, but from the perspective of simulation this is not
important. Disabling interrupt-based HSA signals therefore increases the
number of applications working within gem5.
Change-Id: I1ae21d7ee01548a4d00a8972642079b90278f9a2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61652
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
This change consists of two scripts,
- riscv-hello-save-checkpoint.py: runs the first million ticks of the
simulation and save a checkpoint.
- riscv-hello-load-checkpoint.py: loads the above checkpoint, and runs
the rest of the simulation.
This change also adds the two scripts as part of quick tests.
Change-Id: I7bd97ba953fab52f298cbbcf213f2ea5c185cc38
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58829
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
This changes adds a new board to the gem5 stdlib, which is capable
of simulating an ARM based full system. It also adds an example
config script to perform a boot-test using an Ubuntu 18.04 disk
image. A test has been added in the gem5-library-example for the
same.
Change-Id: Ic95ee56084a444c7f1cf21cdcbf40585dcf5274a
Signed-off-by: Kaustav Goswami <kggoswami@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58910
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The supported version of ROCm in GPUFS only supports the DKMS build of
the amdgpu driver. However, since a gem5 user can potentially pass in
any Linux kernel as a parameter, it is possible that the DKMS package
for that kernel was not installed on the disk image. This would result
in the simulation appearing to work when in reality it is just spinning
waiting for commands from the driver. This check exits gem5 early in the
simulation and outputs an error on the console to sanity check the
correct driver is being used.
Change-Id: I708912e5625e47eba15dcb2f722772a3b2928b98
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/58129
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
