Component that require randomness should not share their randomness
source with other components to avoid simulation noise. For instance,
the branch predictor of one core should not impact the random
cache replacement policy of the cache of another core. This currently
happens as all components share a single random number generator.
This PR provides their own generators to relevant components, although
a couple components still use rand().
Change-Id: I3fb7226111c9194ee457af0f0f2b83f8c7b69d1e
Co-authored-by: Arthur Perais <arthur.perais@univ-grenoble-alpes.fr>
This commit fixes three issues in MESI_Three_Level and MESI_Two_Level
implementations (MEI_Three_Level_HTM might still have issues).
1) Define functional read priorities for the cache controllers which
have states with Maybe_Stale access permission (L1 > L2 > Directory).
2) Fix incorrect access permissions in MESI_Three_Level-L1cache:
* S_IL0 is Read_Only, it is waiting for L0 to acknowledge the
invalidation request before moving to SS, also a Read_Only state.
* E_IL0 is Maybe_Stale, its contents might be valid, since there is a
transition (E_IL0, L0_Ack, EE) with no writeback data.
* M_IL0 is Maybe_Stale, its contents might be valid, since there is a
transition (M_IL0, L0_Ack, MM) with no writeback data.
3) Add missing message types carrying valid data in functional reads:
* INV_DATA is a writeback from L0 to L1.
* DATA is a response to GET_S, but there are scenarios where it might
be the only place with valid data (e.g. during L2 replacement).
Change-Id: Ie44fa317027f9ede272967e7461d337e14355eec
Functional reads can be satisfied by one of the following, in order:
1. Main memory (when the data is not present in the cache hierarchy);
2. Valid data block in cache;
3. Valid data block in coherence message;
4. Valid data block marked as Maybe_Stale;
Number 4 is not handled by the current implementation. A Maybe_Stale
block can be either truly stale or actually valid. When it is stale,
the memory read will be satisfied by either number 2 or number 3. When
it is valid, there will be no coherence message with valid data inside,
and the Maybe_Stale block will transition to a valid state after
receiving some kind of acknowledgement.
The main challenge to handle number 4 is how to know from which
Maybe_Stale block the data should be read from. For instance, in a two
level cache hierarchy, we might have a block marked as Maybe_Stale in
both L1 and L2. In this case, we should prioritize the cache controller
that is closest to the CPU. To define this priority, a new virtual
function 'functionalReadPriority' was added to the AbstractController
class.
Change-Id: I4774cd01aab7bb9ca53694cd9dc4f9416a8e4025
The getValidAddr is the method get virtual address with valid bits. It
is useful to get the correct symbol table via valid virtual address.
For ARM, we have `purifyTaggedAddr` to get the right virtual address.
For RISC-V, we only get lower 32 bits in RV32 mode to get the right
symbol table.
Change-Id: I33ad7bec6e7ea4ec82cb1b3a7f521432c6d735b6
As of PR #977, gem5 has a defined M5OPS_ADDR for arm64, even if it is
constrained to certain conditions. With that change and the arm64 board
KVM support (#725), it seems like interaction with the m5 utility under
arm64 will most commonly occur in KVM -- where instruction-mode does not
work -- and thus address-mode becomes more desirable as the default.
This also makes m5's behavior in arm64 consistent with x86, the only
other architecture that supports address-mode operations.
The PR https://github.com/gem5/gem5/pull/1316 changes the sign-extend
address generation. We also need to sign-extend the address when setting
the PC in enter/leave trap handler
Change-Id: I62d58a26dba0b0c64125fea8ac9376ebf55c4952
The number of register pins for the vector gather instructions was not
calculated correctly because the micro vl was not right. This caused
some micros to rename a new register instead of using a pinned one.
This PR improves the legacy RISC-V FS Linux script in the following
ways:
- Adds an argument to specify the bootloader, to (optionally) use the
`RiscvBootloaderKernelWorkload` class.
- Updates the DTB generation function adding the Chosen node. This
fixes the execution with recent Linux kernels.
- Checks if the `--kernel` required argument is set.
Previously, GPU L2 caches could be configured in either writeback or
writethrough mode when used in an APU. However, in a CPU+dGPU system,
only writethrough worked. This is mainly because in CPU+dGPU system, the
CPU sends either PCI or SDMA requests to transfer data from the GPU
memory to CPU. When L2 cache is configured to be writeback, the dirty
data resides in L2 when CPU transfers data from GPU memory. This leads
to the wrong version being transferred. A similar issue also crops up
when the GPU command processor reads kernel information before kernel
dispatch, only to incorrect data. This PR contains a set of commits that
fix both these issues.
The method is defined as const but the caller will actually modify the
content of the structure directly with the pointer in
BaseRemoteGDB::cmdRegW. The member access in the const method are
actually treated as const and will cause error if we use
reinterpret_cast instead.
Remove the const tag to align the expectation of the virtual method.
One of the perks of the previous TLB storage implementation [1] is that
its custom implementation of LRU exploited temporal locality to speed up
simulation performance
TlbEntry tmp_entry = *entry;
for (int i = idx; i > 0; i--)
table[i] = table[i - 1];
table[0] = tmp_entry;
return &table[0];
In other words the matching entry was placed as the first entry of the
TLB table (table[0], top of LRU stack). In this way a following lookup
would encounter it as the first entry while looping over the TLB table,
therefore massively reducing simulation time when temporal locality is
present
(most of TLB table loops would find a match in the first iteration).
int x = 0;
while (x < size) {
if (table[x].match(lookup_data)) {
With the new implementation we decouple TLB storage from the replacement
policy. The result is a more flexible implementation but with the
drawback of a slower lookup/search. We therefore we need to find another
way to exploit temporal locality. This patch addresses it by caching a
previously matched entry in the TLB table
[1]: https://github.com/gem5/gem5/blob/v24.0.0.0/src/arch/arm/tlb.cc
Change-Id: Id7dedf5411ea6f6724d1e4bdb51635417a6d5363
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
The MMU already stores a pointer to the release object, so it can query
it directly to check for PAN instead of relying on the slower HaveExt
helper
Change-Id: Ie3a186aa1d65955cff4a40871bde1ee78aa36ec0
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Two NetDest locally declared variables are using default constructor
instead of constructor with RubySystem pointer. This will cause asserts
when (1) garnet is used or (2) a protocol that uses `broadcast()` is
built.
Fix these two by passing the appropriate RubySystem pointers.
In our usecase, we'd like to intercept some gadgets in some gem5 ports,
and register them to a Python-level collection. The registered name is
the string from C++ constructor argument (portName), and it would be
great if we can access that from Python-level as well. This commit
enable this by exporting a py-binded method to access the portName.
Change-Id: I93398697536f27a52d3a1dd0e658fcb321b9e293
With this PR we replace the TlbEntry storage within the TLB from an
array of entries with a custom hardcoded FA indexing policy and LRU
replacement policy, into the flexible SetAssociative cache.
purifyTaggedAddr is known to be an expensive computation regardless of
the memoization we do, as it sits in the critical path from a host
performance point of view (instruction fetch).
In checkPermissions64 we compute it without really needing the tag
purification. The only place where it is used is to check for
PCAlignment, but the alignment checks the 3LSBs whereas a potential tag
would be stored in the most significant ones
Change-Id: I9f39db658c3575dcbacb5351813ff9bb3775046d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
PR gem5#1453 left some unused variables in the ruby code that triggered
"unused variable" warnings found comiling ALL/gem5.opt to use the CHI
protocol. These have been removed.
In #1453, an `implicit_ctor` option was added for SLICC structures. This
was done to allow statements such as `NetDest tmp;` which now require a
non-default constructor without modifying every protocol. The new
`implicit_ctor` option converts the statement `NetDest tmp;` in SLICC to
`NetDest tmp(<implicit_ctor>);` in C++. This is problematic when doing
something like `NetDest tmp := getMachines(...);` which gets converted
to `NetDest tmp(<implicit_ctor) = getMachines(...);` as the constructor
doesn't return an object. Before #1453 NetDest had a default constructor
so there we no difference between a local variable definition and local
variable assignment.
This commit fixes this issue by checking in the LocalVariableAST if the
local variable is part of an assignment or not. If it is not part of an
assignment, the implicit_ctor is used. Otherwise, the assignment is
printed to the generated code.
Note that this is not done anywhere in the public code but should be
allowed for folks writing their own Ruby protocols who might otherwise
be confused why a simple assignment presents a compile error.
This PR adds support for command line arguments in GPU-FS runs to allow
the user to configure several parts of the GPU. It also increases the
bits per set in the build_opts/VEGA_X86 file to enable GPU-FS
simulations to use 64 directories or more.
This commit addresses the requested changes. An additional
comment is added for clarification, the exception type is
changed, and a few of the error messages have been
modified.
Fix#1384.
MESI_Two_Level and MESI_Three_Level protocols are susceptible to LL/SC
livelocks when simulating boards with high core count.
This fix is based on MOESI_CMP_directory's implementation of locked
states, but tailors the solution to only apply it when a Load-Linked is
initiated.
There are two new states to act as locked states and stall any messages
leading to eviction:
* LLSC_E: equivalent to E state, go to E after timeout.
* LLSC_M: equivalent to M state, go to M after timeout.
The main new event is Load_Linked, which is very similar (in behavior)
to a Store, reusing several transient states. When a controller receives
the exclusive data, it differentiates a Load_Linked from a Store by
checking a new field added to the TBE: 'isLoadLinked'. It triggers a
different event when it is a Load_Linked, which in turn causes the
transition to one of the locked states.
The entire mechanism can be turned off by setting 'use_llsc_lock' to
false, and the amount of time to keep locked is defined by
'llsc_lock_timeout_latency'.
Change-Id: I13f415b6b7890d51d01f23001047d2363467a814
A previous PR mistakenly [1] replaced translateFunctional with
translateAtomic. This commit is reverting that
[1]: https://github.com/gem5/gem5/pull/1697
Change-Id: I945c3fe59cea36732d9f30109b950d4114aa8fad
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This PR fix the bug of vsetivli frequently flushing the pipeline.
Here are two pictures of the pipeline illustrate this phenomenon.
The vsetivli(0x00013334.0) instruction in the first picture flushes the
pipeline every time it is executed. This is due to vsetivli being
incorrectly flagged as a 'DirectControl' instruction. The branch
predictor cannot predict it correctly.
The second picture is the pipeline after fixing the bug.
Change-Id: I5bede47919c06cea86fa23a81624b502fbdc1159
This commit adds SE mode to RiscvBoard. RiscvDemoBoard has also
been modified as adding SE mode to RiscvBoard made the
overridden functions in RiscvDemoBoard obsolete.
This commit adds SE mode to X86Board. X86DemoBoard was also modified,
as functions that were previously needed to add SE mode to
X86DemoBoard were removed.
This PR adds a RiscvDemoBoard that can be used with both SE and FS
mode.This was tested using the workloads riscv-matrix-multiply-run for
SE and riscv-ubuntu-20.04-boot for FS. Two example config scripts have
also been added.
Add decoder and function of AArch32 VRINTN, VRINTX, VRINTA, VRINTZ,
VRINTM, and VRINTP (Advanced SIMD) instructions. Support both 16-bit and
32-bit variants.
Add vfpFPRint in vfp.hh to perform the behavior of round-to-integer.
Only support A32 encoding.
Change-Id: Icb9b6f71edf16ea14a439e15c480351cd8e1eb88
Fix#1682. Treat LEA as a BigLdStOp. BigLdStOps (as well as other Big*
x86 uops) do not have input dependencies on 32-/64-bit destinations. LEA
will still have input dependencies on 16-bit destinations. (LEA cannot
have an 8-bit destination.)
Change-Id: I5d0678e6bd79bfd6064941a89c6fe290750543c9
