Modeled after the HiFive Unmatched.
For the cache, we inherited from AbstractClassicCacheHierarchy and
AbstractTwoLevelCacheHierarchy to make a PrivateL1PrivateL2 hierarchy
with the same associativity and sizes as the board. However, the L2
Size is kept as a parameter that can be set by the user.
The core is in-order, therefore we inherited from RISC-V MinorCPU and
used the same pipeline parameters as the ARM HPI CPU, except the
decodeToExecuteForwardDelay, which was increased to 2 to avoid a
PMC access fault.
For the processor, we initialized the core with an ID so that we can
return 4 cores in FS mode, which is the same as the real system,
and 1 in SE mode.
For the memory, we just have a single channel DDR4_2400 with a size of
16 GB and starting at 0x80000000.
For the board, we declared a Boolean variable as a parameter to assign
whether it is in FS mode or not. We inherited from KernelDiskWorkload
and SEBinaryWorkload and initialized the components of the board
according to the Boolean. The other parameters are the clock frequency
and the L2 cache size.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1257
Change-Id: Ic2c066bb3a41dc2f42566ce971f9a665542f9771
Co-authored-by: Jasjeet Rangi <jasrangi@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63411
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The KVM_ISA setting was moved into a CONF dict, but the code which
ensured it had a default if there was no possible KVM hosting ISA was
still setting that variable in the base environment dict. This moves
the setting into the CONF dict instead.
Change-Id: I067c969dd761b2cdb098bcba6cd6a4b643d2d427
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63752
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Finish_CopyBack_Stale is scheduled only when the requestor is the last
sharer. This prevents the cacahe evicting the line which was already
evicted while the stale WriteBack transaction was stalled.
Wrong condition check in Finish_CopyBack_Stale for eviction is also
removed.
Change-Id: Ib66acc1b9e4a6f7cea373e1fb37375427897d48d
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63611
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
While the `runtime` module's `get_runtime_isa` function throws a warning
to remind user's the function is deprecated, this was not always helpful
to a user when setting a processor without a target ISA.
This change adds additional warnings to the SimpleSwitchableProcessor
and the SimpleProcessor. These warnings explain not explicitly setting
the ISA via the processor's constructor is deprecated behavior.
Change-Id: I994ad8355e0d1c3f07374bebe2b59106fb04d212
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63331
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Prior to gem5 v21.2, partial translation entries were not cached within
the TLB, therefore Last Level (only) TLBI instructions were invalidating
every entry.
Now that we store translations from several lookup levels we are
currently over-invalidating partial translations. This patch is
adding a boolean flag to TLBIMVAA and TLBIMVA, allowing to discard
a match if the TLBI is targeting complete translations only
and the entry holds a partial translation
Change-Id: I86fa39c962355d9c566ee8aa29bebcd9967c8c57
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62453
Tested-by: kokoro <noreply+kokoro@google.com>
Misaligned access is an optional feature of riscv isa, but it is always
enabled in current gem5 model. We add a flag into the ISA class to turn
off the feature.
Note this CL only consider the load/store instruction, but not the
instruction fetch itself. To support instruction address fault, we'll
need to modify the riscv decoder.
Change-Id: Iec4cba0e4fdcb96ce400deb00cff47e56c6d1e93
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63211
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
The C and C++ standards allows the character type char to be signed or
unsigned, depending on the platform and compiler. Most systems,
including x86 GNU/Linux and Microsoft Windows, use signed char, but
those based on PowerPC and ARM processors typically use unsigned char
This means testing for:
EXPECT_FALSE(parser.parse("255", value));
is not portable as Arm platforms are able to convert 255 into an unsigned
character. We are fixing this portability issue by performing
different checks depending on the platform.
Maybe a better solution would be to explicitly set the sign of the
char (signed char in this case)
Change-Id: I44dd84378ea62ae21a6b03e1f35119bf85f8c799
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63539
Maintainer: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
This change adds a new traffic generator module to the standard
library that can read a .cfg file describing the traffic pattern
as a state machine. It wraps around the TrafficGen SimObject.
In addition it adds a method to ComplexGenerator to set the
traffic from outside using python generators like the example
found in configs/dram/sweep.py.
Change-Id: I5989bb900d26091e6e0e85ea63c741441b72069c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62473
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Add control/branch instructions committed stat to Minor CPU. The stats
can be found in board.processor.cores.core.committedControl_0 in
stats.txt. The stats counted are IsControl, IsDirectControl,
IsIndirectControl, IsCondControl, IsUncondControl, IsCall, and IsReturn.
IsControl tracks the total control/branch instructions committed.
Use inst->staticInst->isControl() flag to determine if an instruction is
a control or not, and then using other flags in the StaticInstFlags to
determine the type of control instruction and tracking the committed
ones.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1283
Change-Id: Iee1010fdf0fa4078ebe1c56b437295abdb5f4469
Co-authored-by: Kunal Pai <kunpai@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63358
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
The current MI_example protocol's L1 caches updates the MRU information twice per store requests that miss -- once when the request reaches Ruby and once when the store miss is returned from another level of the memory hierarchy.
Although this approach does not cause any correctness bugs for replacement policies like LRU since this request is the LRU in both cases, it does not work correctly for other policies like SecondChance and LFU, where updating the information twice (for misses) causes them to devolve to LRU.
Note that this was not directly a problem with Ruby previously, because it only supported LRU-based policies that were unaffected by this. However, with the integration of 20879 Ruby now uses the same replacement policies as Classic (which has additional, non-LRU based replacement policies).
This patch resolves this problem by not updating the MRU information a second time for the misses. It has been tested and validated with the replacement policy tests in 20880, and it modifies the store instead of the load in 62232.
Change-Id: I8436e3e537da0ee5841c59a94fa5e5c30105529f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63191
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
When debugging strange addresses, it is extremely useful to know *what*
instruction calculated that address. This make it much easier to follow
assembly code backwards to find the source of an incorrect address.
This change adds a DPRINTF for GPUTLB that by default prints the
disassembly when a virtual address translation is sent to the TLB.
Change-Id: I5066c064a48c5c48696863eeccd8d011245ef7b2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63176
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The previous print statement was not clear that a scalar offset was
being used when printing disassembly, which made it slightly more
difficult to track down bugs related to this (relatively) rare usage of
global load/store instructions.
This change improves the disassembly to closer match the output of
hipcc's assembly code output.
Change-Id: I8514aedacb5b1db93d0586c408c4cf1ce77a7db3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63175
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
SDMA atomic packets are used in conjunction with RLC queues in SDMA for
synchronization similar to how HSA signals are used with BLIT kernels
when SDMA is disabled. Implement a skeleton of the SDMA atomic packet
methods as well as the atomic add64 operation.
The atomic add operation appears to be the only operation used in ROCm,
so this implementation is fairly complete. See:
https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/
rocm-4.2.x/src/core/runtime/amd_blit_sdma.cpp#L880
Change-Id: I62cc337f2ffe590bdb947b48053760ee8b3a6f32
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63174
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There can only ever be two RLC queues maximum. Use this information for
a simpler data structure to store doorbell information. The patch
changes the std::unordered_map previously used to std::array. This will
also be useful in avoiding erase-while-iterating issues needed to
unregister all queues at once.
Change-Id: I95600e40de51cb1a992a20bcebaf7580ea4d0be8
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63172
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Previously framebuffer reads would try reading from MMIO trace, special
addresses, and then anything previously written to a special address
range. This does not handle direct large BAR reads, causing incorrect
results in some applications that were doing this.
Rework the readFramebuffer method to do the following. Remove the MMIO
trace read altogether, as there were not any framebuffer reads from the
trace to begin with. Read special addresses first to avoid overwriting
by previous writes. Next read previous writes to special ranges. The
special range is the GART table. These are required for functional
translations. Lastly read from the device memory directly. This does a
functional read required by the PCIDevice read method which is
non-timing. Reading from device memory is preferred over the map type
used for GART to avoid duplication of a potentially huge amount of data.
With this changeset all but one of the HIP samples and HIP examples
applications now run and pass verification of results.
Change-Id: Id3b788bfc5eaf17cfa1897f25d26f3725d4db321
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63171
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
The virtual and physical address for device memory are typically aligned
to the page size. On the host (x86), however, the physical address may
not be aligned to page size for large page sizes when mixed with 4kB
pages. As a result, the physical address calculation must add, rather
than bitwise-OR, the virtual page offset to the physical page number.
The virtual page offset on the GPU continues to use the variable page
bytes for masking and shifting.
Change-Id: I6563a1eb43d9b59577d32268b8645a7436304bcb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63034
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
The memory management hub ("mmhub") is an aperture that aliases the GPU
device memory. MMHUB addresses functionally map to the same device
address, with the exception that it is guaranteed not to overlap with
host memory. This is useful in gem5 for APIs with Addr type as it
prevents sending e.g., DMAs to the wrong place.
Change-Id: Ia296809a8dc2c5fbdeba6d70cd53215f9ab36c93
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63031
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In almost all cases reading/writing using the GPU memory manager will
want to wait until that read or write is complete. Therefore, change the
API to not default to no callback so that the user must explicitly
specify nullptr indicating they do not want to wait for completion.
Updates a write call which cannot use a callback due to being atomic in
the base gpu device code.
Change-Id: Id19145d49c7cafc97e2e178819682cb97270a16a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62716
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: 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>
SDMA write, copy, and ptePde use GPUMemMgr to write to device memory and
were dangerously not waiting for write completion which could result in
data not being completely written to memory, the data buffer being freed
and potentially reused in the simulator, or advancing to the next SDMA
packet before the previous one is complete.
This changeset adds callbacks for the corresponding "done" methods
similar to what the dmaVirt methods call when reading or writing to host
memory to fix this issue.
Change-Id: I44ce14c13f812ea2a7a76438e12a6ed7c6e0bff0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62715
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Requests sent using the GPU memory manager are not guaranteed to be
ordered. As a result, the last chunk created by the chunk generator
could complete before all of the previous chunks are done. This will
trigger the final callback and may cause an SDMA/PM4/etc. packet that is
waiting for its completion to resume before the data is ready.
This is likely a fix for verification failures in many applications.
Currently this is tested on MatrixTranspose from the HIP cookbook which
now passes its verification step. It could also potentially fix other
race conditions between reads/writes from/to memory such as using a PTE
or PDE before it is written, etc.
Change-Id: Id6fb342d899db6bd0b86c80056ecf91eeb3026f5
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62714
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Now that the memory manager can DMA read from device memory, allow the
linear copy SDMA packet to use device memory as a source. This is used
when copying memory from device to host when SDMA engines are enabled.
This improves simulation performance over using (simulated) BLIT kernels
with SDMA engines disabled.
Change-Id: I1f41b294022f0049d154a401c1dc885abb4f223b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62713
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Using the register destination to store an immediate result causes the isa parser to set the destination as a dependency, meaning the destination register from previous instructions must have a ready result before this instruction can issue. I fixed several cases where this occurs by using a non register intermediary value
Change-Id: Id2ccca820a4e072fa2cae81fa9153deb6a8d5c4c
Signed-off-by: Noah Katz <nkatz@rivosinc.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63052
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 commit:
https://gem5-review.googlesource.com/c/public/gem5/+/62471
set `sim_quantum` for any simulation done via the Simulator module.
However, this causes issues when setting exit events at a particular
tick. It resulted in the exit being off by the `sim_quantum` value. This
is required for KVM setups but is undesirable for non-KVM setups. Ergo,
this commit ensures the `sim_quantum` is only set in cases where KVM
cores are included in a simulation.
There are two items of note here:
1. When using the SwitchableProcessor the KVM cores may be switched out
and therefore not accessable via the `get_cores` method. To get round
this we check if the processor is a SwitchableProcessor and run an
additionial check that _any_ of the cores in the SwitchableProcessor
are KVM. This is a big hacky; the Processor API should be changed to
make this easier.
2. This only partially fixes the problem of exit events being off given
a specified tick. This will still occur in the case a
SwitchableProcessor is used containing KVM cores. E.g., non-KVM cores
will still be "off" when KVM cores are switched out. This issue will
be addressed in a later commit.
Change-Id: Id966d76cd1630b6c41c5972fa9423c9e48eafaf6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63051
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 way these were set up, there would be a conflict between SimObject
files with the same name set up for different ISAs.
This change creates a single file which tries to determine how many ISAs
are enabled, and if there is exactly one, it creates a backwards
compatible alias for the ISA specific CPU types.
Change-Id: Iab358c2880d49222e814a98354c81d0f306fe1fc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52493
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
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>
Previously, all components assume the info in arch/riscv/regs/misc.hh to
be the single source of CSR info. That will however make adding
non-standard CSRs difficult as all those CSRs will need to go into the
same header & data structure and might conflict with each other.
In this CL, we add two new functions to the ISA class that provide
information about CSR. The rationale is that, the ISA class is already
the owner of CSR data, so it'll also be in a better position to provide
necessary CSR metadata. With the change, we can create two CPU models
with slightly different custom CSRs easily by creating two derived
RiscvISA classes and overriding the two functions.
We assume that, any customized CSR set is still compatible with standard
CSRs, so we could still utilize the same global map if only standard
CSRs are accessed in the use case.
Note that this does not necessarily mean you cannot or should not add
your customize CSRs into the MiscRegIndex enum. You'll usually still
required to do that to give each CSR an unique id. However, the ability
to override CSRDataMap/CSRMaskMap provide an opportunity to remap how
the CSR index encoded in the instruction maps to CSR, and also give you
a chance to make the read/write logic of certain custom CSRs different.
Change-Id: I168188bdb1baed11cb3e217eb021f289a13bb036
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/62891
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
