Use the protocol-specific controller names in CHI.
**Important**: This could change some scripts. As long as people use
CHI_config (likely), this shouldn't be a problem, but if you have a
different version of CHI_config.py locally, you will need to make the
following updates:
`Cache_Controller` -> `CHI_Cache_Controller`
`Memory_Controller` -> `CHI_Memory_Controller`
Website updates coming soon!
Change-Id: I7afdcede884ac5f9a9a76cc3d3dd35941e4e2faa
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Use protocol-specific names in Learning gem5 configs. Now, we should no
longer use the generic names for the controllers (it's deprecated). This
updates Learning gem5.
Website changes coming soon. (Hopefull before I push this...)
Change-Id: I18fc5b8bb0fef7c3b8b5cea8de4f73fc0f66a1b3
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This change is a step toward multiple protocols building at the same
time in scons. Add functions and use lists instead of single protocol.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This change makes it so that the MachineType.cc/hh file are not unique
for each protocol. All of the machine types are now tracked.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Rename all SLICC generated SimObjects to have the protocol in their
name. This will allow for two different protocols to have the same
machine names (e.g., L1Cache). For compatiblity, we check to see if the
current or main protocol that is built matches the SimObject's protocol
and export the backwards-compatible name.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Move the html output to be in a subdirectory with the protocol name.
Change-Id: I1510d2d5a531cc6db74d10a0478c23bc8a836a26
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Move all generated protocol-specific files to a subdirectory with the
protocol's name.
This change also updates SLICC to have separate variables for the
filename, c identifier and python identifier instead of just using
variations of the c identifier.
Change-Id: I62f69a4606b030ee23cb2d96493f3257a6923748
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Wrap all protocol-specific types in `namespace <protocol>`. This will
facilitate compiling multiple protocols into one binary.
There is a one-time hack to the generated `MachineType.cc` file to use
the namespace for the protocol until we generalize the machine types.
Change-Id: I5947e8ac69afe6f7ed257d7c5980ad65e9338acf
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This changes extends SLICC to understand two different kinds of slicc
files: files that are protocol-specific and files that are shared or
included between different protocols.
Each declaration in SLICC can now be shared or not. If it is shared,
then we can take a different action in the code generation (e.g., wrap
in a namespace).
*Developer facing change*
Removes the RubySlicc_interfaces.slicc file from the SLICC includes of
every protocol.
Changes required: If you have a custom protocol, you will need to remove
the line `include "RubySlicc_interfaces.slicc" from your .slicc file.
Change-Id: Ia6c2dafe2b8fe86749a13d17daa885bddd166855
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This extends gem5's version of python enums to support an equal operator
and the hash operator so we can compare two instances of enums and add
these to sets/dicts/etc.
Change-Id: I4a785bf9570a54254ada1db684379ee77e67b192
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Change inst_threshold param to inst_thresholds, which it is now
expecting a list of thresholds instead of one threshold.
Add more getter and setter functions:
addThreshold:
it is for adding new thresholds
getCounter:
it is for getting the current counter
getThresholds:
it returns the list of targeted thresholds
resetThresholds:
it clears all the targeted thresholds
Change-Id: I48d022effe7b315112ac150e6a4eaf5aab41c514
The listener pointer does not get deleted with the removeListener()
function call, so we need to make sure it is deleted in the
ProbeListenerObject.
Change-Id: I370f34651b889c8c00a378743e9c1c09fa1d775e
x86-global-inst-tracker.py:
- change the incorrect use of comment styly
- add more comments about the usage of the script and the purpose of
the script
src/cpu/probes/inst_tracker.cc:
- change the way of stopListening to use the manager function to remove
listeners. If in the future, the ProbeListner object does not call the
manager to remove itself in the destruction, then we should call it
here.
- fix stlying
src/cpu/probes/inst_tracker.hh:
- fix stlying
Change-Id: I6f3d745e15883a8a702593f72f984e0d4cc4c526
The GlobalInstTracker manages the global instruction counter and
responsible for triggering an exit event when the global instruction
counter reaches the defined threshold.
The LocalInstTracker listens to one core's retiredInsts probe point
and updates the GlobalInstTracker every time there is an instruction
committed.
The purpose of this instruction tracker is to raise an instruction
executed exit event with multi-core simulation.
Related discussion can be found:
https://github.com/gem5/gem5/issues/1087
Change-Id: Iab6fec57f14f28e590b035506282130ba8662706
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>
