Fix#1809. Shift the mmap end to a lower address in case the process has
a large max stack size, to avoid overlapping the stack with the mmap
memory range.
Change-Id: Idae343dbbe851a7510463ff141c03f1847e36328
Previous PR #1758 implements the generic getValidAddr to get pure
vaddr without any tags or sign-extend bits.
In RISC-V implementation, the getValidAddr will zero-extend
address in RV32 mode and use it to do TLB translation. Use
getValidAddr to get zero-extend vaddr can reduce zero-extend
repetition
Change-Id: I2273ce48bccb873790103ba0fcdb0b48de9ced4c
src/cpu/simple/probes/LooppointAnalysis.py:
- remove default values for bb_valid_addr_range and
marker_valid_addr_range
- add more comments to explain parameter behaviors
- add citation to the LoopPoint paper
src/cpu/simple/probes/looppoint_analysis.cc:
- fix the incorrect styles
- remove updateBackwardBranch() function call
- match the style of checking if listeners vector is empty
- change the way of stopListening() to remove the listeners through the
manager instead of through the ProbeListener object's destructor.
src/cpu/simple/probes/looppoint_analysis.hh:
- removed backwardBranchPC and use the backwardBranchCounter to replace
its functionaility. Therefore, also removed updateBackwardBranch
function.
Change-Id: Id2430e2f04e61f72d5c4f1aad5cfd4d24a0fbc45
Add comments to most variables and functions.
Change the naming of some variables and functions to improve the
clearness.
Change-Id: Idb557ec84698b4344ed4683f5de87b1a3c2fd66d
In looppoint_analysis.hh, added LooppointAnalysis and
LooppointAnalysisManager classes.
Added all functions and variables for the classes.
Comments needed.
Change-Id: Ia7425b672ef092a68c99b702136850bfa1fcf0a2
Because the LoopPoint analysis will be done with ATOMIC CPU, so all
files related to the LoopPoint analysis object will be under
/src/cpu/simple/probes.
Change-Id: Icbdb0742b712a23dc8f6a19f4c1c827a1f5bf288
This change updates the names for the GPU children in a better way than
overriding the parent. Now it looks something like
```text
board.gpus.shader.CUs00
board.gpus.gpu_caches.ruby_gpu.controllers02
board.gpus.memory.mem_ctrl0
```
Note that it is "gpus" with an "s" because the board accepts more than 1
GPU, optionally.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This function returns the GPUs (for now, possibly other devices in the
future). It needs to be in the abstract board so the GPU-specific cache
hierarchies can be used with non-GPU boards.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This prepends loading the GPU drivers to anything passed in via the
readfile_contents. Note that if the user sets a specific readfile via a
file they will be responsible for loading the driver
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This change separates the instantiation of gpu memory from
instantiatiing the gpu cache. Prior to this change, the gpu
cache instantiated the memories for the gpu by receiving number
of channels as a parameter. With this change, the gpu memory
should be constructed outside the gpu, without being added as a
child to any other object, and passed to the constructor of
the gpu.
This change adds a new method to AbstractMemorySystem to allow
getting its objects of the class MemInterface. This is useful
when certain other classes require a list of MemInterface objects
to create physical memory. In addition, ChanneledMemory and
HighBandwidthMemory implement this function.
Adds GPU_VIPER protocol related caches to stdlib components: CorePair
cache, TCP, SQC, TCC, Directory, and DMA controllers. Adds GPU related
components in a new components/devices/gpus/ directory. Adds prebuilt
GPU and CPU cache hierarchies, GPU and CPU network classes, and a board
overriding the X86Board to provide helper methods for disk image root,
the complex kernel parameter list, and method to provide functionality
to the current GPUFS scripts to load in applications and handle loading
the GPU driver.
The new GPU components can be used as follows:
- Create a GPU device *before* the CPU cache hierarchy is created.
- Add the GPU's CPU-side DMA controllers to the list of CPU cache
controllers.
- Use GPU device method to connect to an AbstractBoard.
Each GPU components has it's own RubySystem, PCI device ID, and address
ranges for VBIOS and legacy PCI BARs. Therefore, in theory, multiple
GPUs can be created. This requires PR #1453 .
An example of using this board is added to configs/example/gem5_library
under x86-mi300x-gpu.py. It is designed to work with the disk image,
kernel, and applications provided in the gem5-resources repository.
Change-Id: Ie65ffcfee5e311d9492de935d6d0631260645cd3
This commit is building over the CHI-TLM wrapping introduced
by the previous commit and it is adding a CHI traffic generator
as a SimObject.
This will get the python objects as input and it will forward
them to the TlmController to convert them into ruby CHI
messages
Change-Id: Ia67094c9bb880e37b24184313df546ecbaa3289f
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is wrapping the external AMBA CHI-TLM with pybind11
so that it will be possible to use its data structures/functions
from python.
More specifically we will be able to instantiate a ARM::CHI::Payload
and ARM::CHI::Phase from a gem5 config, with the end goal of being
able to configure a CHI transaction from python
Change-Id: I9587b445c21df44161fa3d9e09fc2651541b38bd
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is extending the previously defined CHIGenericController
to implement a CacheController which acts as a bridge between the
AMBA TLM 2.0 implementation of CHI [1][2] with the gem5 (ruby) one.
In other words it translates AMBA CHI transactions into ruby
messages (which are then forwarded to the MessageQueues)
and viceversa.
ARM::CHI::Payload, CHIRequestMsg
<--> CHIDataMsg
ARM::CHI::Phase CHIResponseMsg
CHIDataMsg
[1]: https://developer.arm.com/documentation/101459/latest
[2]: https://developer.arm.com/Architectures/AMBA#Downloads
Change-Id: I6f35e7b4ade4d0de1b5e5d2dbf73ce796a9f9fb6
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Component implementing a generic controller that allow classic caches
interaction with Ruby/CHI.
The CHIGenericController provides an interface to send/receive CHI
messages to/from the interconnect. This is implement in C++ rather then
SLICC. This controller is seen as a MachineType:Cache by the CHI
implementation in SLICC.
Change-Id: I3afc4363f4290095c2f7428c8487bccd932e0300
This snoop reponse is not generated internally by the SLICC
implementation, but is required for compatibility with classic caches
which may remain in SD state while returning SC data upon receiving
a converted SnpShared.
Change-Id: I5270b29c8863c7afd8abc39b3c7978b95330c183
Vector slide instructions can have the same register group as source and
destination.
Because we are pinning the destination this will provoke an
auto-reference in the dependency graph.
The solution is to use the `vcpy` micro. This way we use the `vtmp`
register group as source and pin the destination without issues.
1. Add missing override to `print` function.
2. Change `TlbEntry` to struct in `ArmISA` class.
This was found attempting to compile gem5 on MacOS (Apple Silicon) with
clang v19.
This commit changes MESIThreeLevel, MIExample, and OctopiCache
so they work with this PR. It also adds MESIThreeLevel and
OctopiCache to the testlib tests.
This change does many things, but they must all be atomically done.
**USER FACING CHANGE**: The Ruby protocols in Kconfig have changed names
(they are now the same case as the SLICC file names). So, after this
commit, your build configurations need to be updated. You can do so by
running `scons menuconfig <build dir>` and selecting the right ruby
options. Alternatively, if you're using a `build_opts` file, you can run
`scons defconfig build/<ISA> build_opts/<ISA>` which should update your
config correctly.
Detailed changes are described below.
Kconfig changes:
- Kconfig files in ruby now must all be declared in the ruby/Kconfig
file
- All of the protocol names are changed to match their slicc file names
including the case
- A new option is available called "Use multiple protocols" which should
be selected if multiple protocols are selected. This is only used to
set the PROTOCOL variable to "MULTIPLE" when in multiple mode.
- The PROTOCOL variable can now be "MULTIPLE" which means it will be
ignored. If it's not "MULTIPLE" then it holds the "main" protocol,
which is necessary for backwards compatibility with the Ruby.py files.
Ruby config changes:
To make this change backwards compatible with Ruby.py, this change adds
a new "protocol" config called MULTIPLE.py which is used to allow the
user to set a "--protocol" option on the command line. This is only
needed if you are using a gem5 binary with multiple protocols but need
to use Ruby.py.
stdlib changes:
- Make the coherence protocol file behave like the ISA file
- Add a function to get the coherence protocol from the `CacheHierarchy`
like we do with the ISA in the `Processor`.
- Use this function where `get_runtime_coherence_protocol` was used
- Update the requires code to work with the ne CoherenceProtocol
- Fix a typo in the AMD Hammer name and also add the missing MSI
protocol
Scons changes:
- In Ruby we now gather up all of the protocols and build them all if
there are multiple protocols
- There's some bending over backwards to tell the user if they are using
an out of date gem5.build/config file and how to update it
- Note that multiple ruby protocols adds a significant amount of time to
the build since we have to run slicc twice for each file.
build_opts:
- Update all files with new names
- Add a new NULL_All_Ruby that will be used for testing
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This removes two #defines: PARTIAL_FUNC_READS and PROTOCOL_<protocol>.
Instead, update the code to use the runtime information about which
protocol we are using.
Change-Id: Icb6f10fc2d3fd59128c62f9f6e37b52ef2581b61
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Add a ProtocolInfo class that is specialized (through inheritance) for
each protocol. This class currently has the protocol's name and any
protocol-specific options (partial_func_reads is the only one so far).
Note that the SLICC language has been updated so that you can specify
the options in the `protocol` statement in the `.slicc` file.
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Update the standard library Ruby protocols to use the protocol-specific
class names instead of the deprecated general names.
Unfortunately, some code became duplicated between similar controllers.
I tried multiple inheritance, but it didn't work out for me. I think the
correct solution is to move some of the shared code down into the
generated python. That's out of the scope for these changes.
Change-Id: I3444bee3c2917dcbe92b600b85e60244129aad35
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
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>
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>
