This upgrades the garnet model to support HeteroGarnet
1) Static and dynamic multi-freq domains in network
2) Support for CDC
3) Separate links for each message class
4) Separate linkwidth for each message class
5) Support for SerDes
Change-Id: I6d00e3b5cb3745e849d221066cb46b2138c47871
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32597
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This change sets the properties in hsaTopology to the proper values
specified by the user through command-line arguments. This ensures
that if the properties file is read by a program, it will return
the correct values for the simulated hardware.
This change also adds in a command-line argument for the lds size, as
it was the only other property used in hsaTopology that didn't have
a command-line argument. The default value (65536) is taken from
src/gpu-compute/LdsState.py
Change-Id: I17bb812491708f4221c39b738c906f1ad944614d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31995
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Anthony Gutierrez <anthony.gutierrez@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changeset adds the necessary changes for running
GCN3 ISA with VIPER in apu_se.py.
Changes to the VIPER protocol configs are made to add support
for DMA and scalar caches.
hsaTopology is added to help the pseudo FS create the files
needed by ROCm to understand the device on which the SW is
being run.
Change-Id: I0f47a6a36bb241a26972c0faafafcf332a7d7d1f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30274
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Bradford Beckmann <brad.beckmann@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
fs.py warns when an Arm platform is being created without a DTB file,
if the platform does not support the automatic creation of a DTB.
Updated the list of supported platforms with recent additions in order
to remove incorrect and potentially confusing warnings.
Change-Id: I549124a1afbc36e313f614dccab17973582bc3f7
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30575
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit does not make any functional changes but just rearranges
the existing code with regard to the power states. Previously, all
code regarding power states was in the ClockedObjects. However, it
seems more logical and cleaner to move this code into a separate
class, called PowerState. The PowerState is a now SimObject. Every
ClockedObject has a PowerState but this patch also allows for objects
with PowerState which are not ClockedObjects.
Change-Id: Id2db86dc14f140dc9d0912a8a7de237b9df9120d
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com>
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/28049
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
fs_power.py is an example script that demonstrates how power models
can be used with gem5. Previously, the formulas used to calculate the
dynamic and static power of the cores and the L2 cache were using
stats in equations as determined by their path relative to the
SimObject where the power model is attached to or full paths. This CL
changes these formulas to refer to the stats only by their full paths.
Change-Id: I91ea16c88c6a884fce90fd4cd2dfabcba4a1326c
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27893
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before this change, running:
./build/NULL/gem5.opt configs/example/ruby_mem_test.py -m 20000000 \
--functional 10
would only print warning for memory errors such as:
warn: Read access failed at 0x107a00
and there was no way to make the simulation fail.
This commit makes those warnings into errors such as:
panic: Read access failed at 0x107a00
unless --suppress-func-errors is given.
This will be used to automate MemTest testing in later commits.
Change-Id: I1840c1ed1853f1a71ec73bd50cadaac095794f91
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26804
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
I switch between waiting and non-waiting scenario many times per day.
The BaseCPU.wait_for_remote_gdb attribute, introduced in c2baaab0ed,
makes it much less painful by saving many recompiles.
The present commit tries to go a bit further: the se.py script is
under version control, and changing it interferes with smooth git
workflow.
Change-Id: Ie65ffc44b11d78d5e7878f81f2fcdafa143c20a8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/27287
Tested-by: Gem5 Cloud Project GCB service account <345032938727@cloudbuild.gserviceaccount.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Information about what kernel to load and how to load it was built
into the System object and its subclasses. That overloaded the System
object and made it responsible for too many things, and also was
somewhat awkward when working with SE mode which doesn't have a kernel.
This change extracts the kernel and information related to it from the
System object and puts into into a OsKernel or Workload object.
Currently the idea of a "Workload" to run and a kernel are a bit
muddled, an unfortunate carry-over from the original code. It's also an
implication of trying not to make too sweeping of a change, and to
minimize the number of times configs need to change, ie avoiding
creating a "kernel" parameter which would shortly thereafter be
renamed to "workload".
In future changes, the ideas of a kernel and a workload will be
disentangled, and workloads will be expanded to include emulated
operating systems which shephard and contain Process-es for syscall
emulation.
This change was originally split into pieces to make reviewing it
easier. Those reviews are here:
https: //gem5-review.googlesource.com/c/public/gem5/+/22243
https: //gem5-review.googlesource.com/c/public/gem5/+/24144
https: //gem5-review.googlesource.com/c/public/gem5/+/24145
https: //gem5-review.googlesource.com/c/public/gem5/+/24146
https: //gem5-review.googlesource.com/c/public/gem5/+/24147
https: //gem5-review.googlesource.com/c/public/gem5/+/24286
Change-Id: Ia3d863db276a023b6a2c7ee7a656d8142ff75589
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/26466
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All ISAs except SPARC can now take multiple disk images by passing
the --disk-image option multiple times.
Before this patch, several ISAs automatically mounted a secondary disk
called "linux-bigswap2.img", which had to be in M5_PATH even if the end
user did not want more than one disk. This was the case for for example
for X86 but not ARM.
This change was done to:
* allow ARM to have a second disk image in fs.py, which was not possible,
and allow other ISAs like X86 and ARM to take any number of disk images
* provide a simpler, more intuitive CLI interface that does not require
magic disk images to be present in M5_PATH to work for ISAs such as X86.
Linux does not need that secondary image to boot correctly, so it is
more friendly to support a minimal setup that requires the least amount
of binaries to boot, and let supply the second image manually only if
they need it.
* make fs.py --disk-image work more similarly across all ISAs
SPARC was left with a single disk only because its setup was a bit more
complex and would require further testing.
Change-Id: I8b6e08ae6daf0a5b6cd1d57d285a9677f01eb7ad
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23671
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
It is *not* true that a kernel is required in FS mode. For example,
in SPARC, gem5 is set up to run actual system firmware which will load
a kernel from the disk image. Other systems can run in a bare metal
mode where they also have no kernel.
If a configuration requires a kernel, it should check for it in C++
where there context lives, not globally in fs.py.
Change-Id: Ib094c29474c248f866bd08d4f975648a2c707a19
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24284
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
9p allows the guest Linux kernel to mount a host directory into the guest.
This allows to very easily modify test programs after a run at the end of
boot, without the need to re-insert the changes into a disk image.
It is enabled on both fs.py and fs_bigLITTLE.py with the --vio-9p
option.
Adapted from code originally present on the wiki: http://gem5.org/WA-gem5
As documented in the CLI option help, the current setup requires the guest
to know the full path to the host share, which is annoying, but overcoming
that would require actually parsing a bit of the protocol rather than just
forwarding everything to diod.
Change-Id: Iaeb1ed185dccfa8332fe6657a54e7550f64230eb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22831
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Tested-by: kokoro <noreply+kokoro@google.com>
