We have some customized protocols in gem5 repository and they require
the include path from src directory. It causes the users of those
protocols need to handle the include path correctly by theirselve. This
is tedious and unstable. We should add the default include path in
SIMGEN command line to prevent issues.
Change-Id: I2a3748646567635d131a8fb4099e02e332691e97
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/71118
Reviewed-by: Wei-Han Chen <weihanchen@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This change updates the HBMCtrl such that both pseudo channels
can be in separate states (read or write) at the same time. In
addition, the controller queues are now always split in two
halves for both pseudo channels.
Change-Id: Ifb599e611ad99f6c511baaf245bad2b5c9210a86
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/65491
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 change adds a single DDR5 memory inteface.
A DDR5 DIMM contains two physical channels. Therefore,
two instances of this interface should be used to model
a DDR5 DIMM. The configuration includes 3 different speed
bins models. The configuration is tested with different
types of memory traffic using the traffic generator and shows
performance similar to what is observed in existing
literature [1]. One of the key features of DDR5
"same bank refresh" is yet not supported in gem5, but is
expected to improve the performance of the DDR5 model.
[1] Exploration of DDR5 with the Open-Source Simulator DRAMSys.
Change-Id: I5856a10c8dcd92dbecc7fd4dcea0f674b2412dd7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/68257
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 patch changes the RISCVMatched Cache Hierarchy to
private L1 shared L2.
It also changes the RISCVMatched Core's parameters to
better match hardware performance.
Also, sizes are changed to MiB or KiB instead of MB
or KB, to match the datasheet.
All the changes that deviate from the datasheet and the
ARM HPI CPU (reference for pipeline parameters)
are documented.
The core parameters that are changed are:
- threadPolicy:
This is initialized to "SingleThreaded".
- decodeToExecuteForwardDelay:
This is changed from 1 to 2 to avoid a PMC address fault.
- fetch1ToFetch2BackwardDelay:
This is changed from 1 to 0 to better match hardware performance.
- fetch2InputBufferSize:
This is changed from 2 to 1 to better match hardware performance.
- decodeInputBufferSize:
This is changed from 3 to 2 to better match hardware performance.
- decodeToExecuteForwardDelay:
This is changed from 2 to 1 to better match hardware performance.
- executeInputBufferSize:
This is changed from 7 to 4 to better match hardware performance.
- executeMaxAccessesInMemory:
This is changed from 2 to 1 to better match hardware performance.
- executeLSQStoreBufferSize:
This is changed from 5 to 3 to better match hardware performance.
- executeBranchDelay:
This is changed from 1 to 2 to better match hardware performance.
- enableIdling:
This is changed to False to better match hardware performance.
- MemReadFU: changed to 2 cycles from 3 cycles.
The changes in the branch predictor are:
- BTBEntries:
This is changed from 16 entries to 32 entries.
- RASSize:
This is changed from 6 entries to 12 entries.
- IndirectSets:
This is changed from 8 sets to 16 sets.
- localPredictorSize:
This is changed from 8192 to 16384.
- globalPredictorSize:
This is changed from 8192 to 16384.
- choicePredictorSize:
This is changed from 8192 to 16384.
- localCtrBits:
This is changed from 2 to 4.
- globalCtrBits:
This is changed from 2 to 4.
- choiceCtrBits:
This is changed from 2 to 4.
Change-Id: I4235140f33be6a3b529a819ae6a7223cb88bb7ab
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70798
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Add support for the Arm SVE Integer Matrix Multiply-Accumulate
(SMMLA, USMMLA, UMMLA) instructions. Because the associated SUDOT and
USDOT instructions have not yet been implemented, the SVE Feature ID
register 0 (ID_AA64ZFR0_EL1) has not yet been updated to indicate
support for SVE Int8 matrix multiplication instructions at this time.
For more information please refer to the "ARM Architecture Reference
Manual Supplement - The Scalable Vector Extension (SVE), for ARMv8-A"
(https://developer.arm.com/architectures/cpu-architecture/a-profile/
docs/arm-architecture-reference-manual-supplement-armv8-a)
Additional Contributors: Giacomo Travaglini
Change-Id: Ia50e28fae03634cbe04b42a9900bab65a604817f
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70730
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Sets the appropriate bit in the ID_AA64ZFR0_EL1 sysreg that declares
support for ARMv8.2-F64MM.
This indicates that all pre-requisites for Armv8.2 SVE FP64
double-precision floating-point matrix multiplication instructions
have been met.
FMMLA, and LD1RO* instructions have been implemented, as well as the
128-bit element variants of TRN1, TRN2, UZP1, UZP2, ZIP1, and ZIP2.
For more information please refer to the "ARM Architecture Reference
Manual Supplement - The Scalable Vector Extension (SVE), for ARMv8-A"
(https://developer.arm.com/architectures/cpu-architecture/a-profile/
docs/arm-architecture-reference-manual-supplement-armv8-a)
Additional Contributors: Giacomo Travaglini
Change-Id: Idac3a3ca590e6eb2beb217a40a8c10af1e917440
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70729
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Add support for the Arm SVE Load-Broadcast Octaword (LD1RO{B,H,W,D})
instructions. These are similar to the Load-Broadcast
Quadword (LD1RQ{B,H,W,D}) instructions, but work on a 32-byte memory
segment rather than a 16-byte memory segment. Consequently, the LD1ROx
implementations build on the code for the LD1RQx implementations.
For more information please refer to the "ARM Architecture Reference
Manual Supplement - The Scalable Vector Extension (SVE), for ARMv8-A"
(https://developer.arm.com/architectures/cpu-architecture/a-profile/
docs/arm-architecture-reference-manual-supplement-armv8-a)
Change-Id: I98ee4f56c8099bf40c9034baa488d318ae57d3aa
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70727
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add support for the Arm SVE Floating Point Matrix Multiply-Accumulate
(FMMLA) instruction. Both 32-bit element (single precision) and 64-bit
element (double precision) encodings are implemented, but because the
associated required instructions (LD1RO*, etc) have not yet been
implemented, the SVE Feature ID register 0 (ID_AA64ZFR0_EL1) has only
been updated to indicate 32-bit element support at this time.
For more information please refer to the "ARM Architecture Reference
Manual Supplement - The Scalable Vector Extension (SVE), for ARMv8-A"
(https://developer.arm.com/architectures/cpu-architecture/a-profile/
docs/arm-architecture-reference-manual-supplement-armv8-a)
Additional Contributors: Giacomo Travaglini
Change-Id: If3547378ffa48527fe540767399bcc37a5dab524
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70726
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Write queue drain logic seems off currently. An event is scheduled if
the write queue is empty instead of non-empty. There is no check to see
if draining is complete when bus is in write mode. Finally the power
down check on drain always fails if DRAM powerdown is disabled.
This changeset reverses the drain conditional for the write queue to
schedule an event if the write queue is *not* empty and checks in the
event processing method that the queues are all empty so that
signalDrainDone can be called. Lastly the powerdown state is ignored if
DRAM powerdown is disabled. Powerdown is disabled in the GPU_VIPER
protocol by default. This changeset successfully drains and checkpoints
a GPUFS simulation using GPU_VIPER protocol.
Change-Id: I5459856a694c9054b28677049a06b99b9ad91bbb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/69917
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This is probably the easiest way to instantiate a release containing
any implemented extension. It is alternatively possible to use the
latest release (e.g. Armv92 as of now).
This could be preferrable for consistency across simulations.
However if users want to always be up to date with development,
using ArmAllRelease will allow them to do so without the need
to change their configuration script
Change-Id: Ibca629e99da9b571f233de9d05a5a9186d02aa99
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70958
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
At the moment it is not possible to trace the value of VecElemClass
registers. If a AArch32 SIMD binary is run with tracing on,
simulation will fail the following assertion [1].
std::string
valString(const void *val, size_t size) const override
{
assert(size == sizeof(ValueType));
The problem is that Arm VecElems are stored in RegVal (uint64_t),
but the VecElem data type (ValueType above) per se is a uint32_t.
So valString is getting called with size = 8 (coming from RegVal)
but ValueType has size = 4. We fix this problem by using RegVal as
a VecElemRegClassOps template parameter to make them match.
This is not changing anything from a functionality perspective.
The result will be that we will be able to print VecElems as 64bit
values.
This solution is the most simple one but a bit dirty. I believe
in the long term we should make the VecElemClass use the void* interface
rather than the RegVal one. In this way we will be able to correctly
print the VecElem size as 32bit value.
[1]: https://github.com/gem5/gem5/blob/v22.1.0.0/src/cpu/reg_class.hh#L362
Change-Id: Ic3fc252d41449f828b77f938fefc0cd4274b1c57
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70697
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Patch https://gem5-review.googlesource.com/c/public/gem5/+/70040 added
support for a variable number of SDMA engines to support newer GPU
models. As part of this an SDMA IDs map was added to map from SDMA ID
number to the SDMA SimObject pointer. In order to get the correct
pointer in unserialize now, we need to store the ID in the checkpoint
and use that to index the new map. We can't simply assign using the loop
variable as the SDMAs might not be in order in the checkpoint and
additionally the checkpoint contains both the gfx and page offset for
the SDMA engines, so each SDMA is inserted into the SDMA offset map
(sdmaEngs) twice.
Change-Id: I08e9a8d785f467b6eebff8ab0a9336851c87258d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70878
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
This patch addresses the issue of gem5 failing to build when
the build directory path contains non-ASCII characters.
The previous patches[1] that attempted to fix this issue
became ineffective after the upgrade of Python and pybind11
to new versions. This new patch manually sets the locale in
marshal.py based on the `LC_CTYPE` environment variable,
providing a comprehensive solution that works with Non-ASCII
build directory paths.
[1] https://gem5-review.googlesource.com/c/public/gem5/+/58369
Change-Id: I3ad28b6ee52fd347d2fe71f279baab629e88d12c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70818
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
The decoding function was wrongly named decodeNeon3SameExtra,
referring to the "AdvSIMD three same Extra" instruction pool
This might be an old name as I can only find the
"AdvSIMD *scalar* three same Extra" in the Arm arm. The
encoding space reserved to the pool bears the
"Advanced SIMD three-register extension" name; we
therefore rename the function to decodeNeon3RegExtension
Change-Id: I056da8f0c7808935d12a4b05490d30654178071f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70724
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Unfortunately the building of SST (in "ext/sst") depends on generated
header files. Therefore it adds the build directory to the include path.
For this to work the libgem5.so must be build with
"--duplicate-sources".
Change-Id: I5ed26a89c81402d421f5dfa110de7cf758f28694
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/70497
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
