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>
Theses improvements are:
1. Renames the test suite to the correct "ResourceDownloaderTestSuite".
This was correctly named MD5FileTestSuite due to a copy-and-paste
error.
2. Adds the `setUpClass` and `tearDownClass` from the Python's unittest
framework. These are used to create the simple "resources.json" file
used for testing, set the "GEM5_RESOURCE_JSON", and delete these when
the test is complete.
3. The tests have been updated to utilize the improvements added in 2.
Change-Id: Ia54e45892452bf23b54c8b5a6bb4a94910d83c5f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62651
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This commit adds the concept of a "Workload" to the stdlib. Workloads
specify the details needed to run a particular gem5 workload on an
stdlib board. These are specified as part of gem5-resources and loaded
via the `Workload` class though can be specified locally via the
`CustomWorkload` class.
Tests are included in this commit to verify the functionality of these
Workloads.
Change-Id: I8840d281eb01ee4138f01ee499cae96bf7e0579d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62532
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 `set_se_binary_workload` function was only setting up the binary to
work on one (the first) processor core. This caused an exception to be
thrown when trying to run an SE mode binary on a multicore system.
Tests have been added to ensure this works as intended.
Note: While this implementation fixes the bugs, it is limited. Future
work is needed to allow for multiprogram workloads.
Change-Id: I33dbaf5015705c299215dc83e8449b16df301cd4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62014
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The BaseCPUProcessor is processor containing BaseCPUCores. This gives
gem5 stdlib users a way to create processors containing BaseCPU
SimObjects. While SimpleProcessor does this by-proxy (the user simply
specifies the desires CPUType and ISA and the correct BaseCPU
instantiation is chosen), this new Processor allows a more raw passing
of BaseCPU objects.
The SimpleProcessor now inherrits from this BaseCPUProcessor to avoid
duplcation of functionality. A refactor to achieve this was moving the
setting of the board's memory mode from the SimpleProcessor's
"incorporate_processor" function to the BaseCPUProcessor's then altering
it to determine MemMode based on BaseCPU subclass rather than the
CPUType.
The tests/gem5/configs/simple_binary_run.py test script has been
extended to create an stdlib run with a BaseCPUProcessor instead of the
SimpleProcessor and tests have been included to ensure the
BaseCPUProcessor functions as intended.
Multiple cores comprising of different BaseCPU types has not been tested
and is not officially supported as of this commit.
Change-Id: I229943ab98ece39646f1b4feb909250bb5c61772
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62353
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
test_hello_se.py:
Added "take_params_progs" to store avaliable isa and the binary names.
Added two new parameters in function "verify_config" to take verifier
and input arguments for the binary.
simple_binary_run.py:
Added a new unrequired args called "arguments" to take input arguments
for the binary. Its default value is [ ] so the
"arguments = args.arguments" in the "set_se_workload" can run without
inputting any args.arguments.
Change-Id: Ib99dc92aa97060de5e1d34d9cac5800b82dab9e6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/61771
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
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>
The previous version of this requires the user to set the `main-isa` at
runtime, as inplemented via
https://gem5-review.googlesource.com/c/public/gem5/+/55423. In order to
keep this work in-sync with how the multi-protocol approach will work
(see here: https://gem5-review.googlesource.com/c/public/gem5/+/59193),
it's been decided this should be set at compile time. With this we are
keeping the `TARGET_ISA` parameter. If this is set, this is the de
facto "main-isa". The `main-isa` parameter has been removed from the
gem5 command-line.
If the `TARGET_ISA` parameter is not set, but only one ISA is compiled,
then this single ISA is assumed to be the `main-isa` for simulation. If
neither `TARGET_ISA` is set or the binary is compiled to a single ISA,
an exception is thrown when `get_runtime_isa` is called.
At the time of writing this change is moot as the multi-isa work has
yet to be merged into the gem5 develop branch. It exists here:
https://gem5.googlesource.com/public/gem5/+/refs/heads/multi-isa and
will need refactored to work with this patch.
The multi-isa tests have been updated. As we no longer pass the
`main-isa` as a run-time parameter, we remove many tests which validated
this use-case.
Change-Id: If3366212fe1dacbae389efa43d79349deb907537
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59949
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The following weekly tests were failing:
https://jenkins.gem5.org/job/weekly/53
This appears to be due to the "lulesh" tests failing with the docker
container running out of memory. This can be recreated with:
```
git clone -b develop https://gem5.googlesource.com/public/gem5
cd gem5
git clone -b develop https://gem5.googlesource.com/public/gem5-resources
docker pull gcr.io/gem5-test/gcn-gpu:latest
docker build -t hacc-test-weekly gem5-resources/src/gpu/halo-finder
docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w \
$(pwd) --memory="18g" hacc-test-weekly bash -c \
"scons build/GCN3_X86/gem5.opt -j`nproc`"
docker run --rm --volume $(pwd):$(pwd) -w \
"$(pwd)/gem5-resources/src/gpu/lulesh" \
-u $UID:$GID --memory="18g" hacc-test-weekly make
docker run --rm -u $UID:$GID --volume "$(pwd)":"$(pwd)" -w \
"$(pwd)" --memory="18g" \
hacc-test-weekly build/GCN3_X86/gem5.opt configs/example/apu_se.py -n3 \
--mem-size=8GB --reg-alloc-policy=dynamic \
--benchmark-root="$(pwd)/gem5-resources/src/gpu/lulesh/bin" -c lulesh
```
It is currently unknown as to why this process consumes so much memory
or how it can be reduced, but increasing the docker container limit to
24GB for the Weekly tests does appear to fix the issue.
Change-Id: Ifcd65d4ab8bf6a12ddf7a45d61c779e691619072
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60009
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
Add a longer test for the GPU Ruby random tester to the nightly
regression. This test is sized to take approximately 30 minutes
while providing more coverage than the per check-in Ruby random test,
which takes 30 seconds.
Change-Id: I398feb1283b24f801275ba13d6c53d236849f2eb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59272
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
