Enable a gem5 system to be an SST::Component.
This change includes,
- SST::gem5Component: responsible for,
- initializing the Python environment for gem5
- instantiating gem5 SimObjects
- connecting SST::SSTResponderSubComponent to
gem5::OutgoingRequestBridge
- hanlding the gem5 event queue (no thread-synchronization)
- handling executing gem5 events
- SST::SSTResponderSubComponent: responsible for,
- receiving gem5 requests and sending the requests to
memory.
- sending responses to the corresponding
gem5::OutgoingRequestBridge.
- SST::SSTResponder: owned by SSTResponderSubComponent, the
actual actor that sends gem5's requests to memory.
- gem5::OutgoingRequestBridge: receives the requests from
gem5 and sends them to SST. This SimObject allows the initialization
requests to be cached and the receiver could query the
initialization data later on.
- gem5::SSTResponderInterface: the interface specifying how SST
communicates with gem5.
- A working example of a gem5/SST setup.
More information is available at ext/sst/README.md.
For installation instructions, please refer to ext/sst/INSTALL.md.
Change-Id: I6b81260ef825415bcfe72b8a078854f4c94de782
Signed-off-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50468
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This way there will always be a workload object, even if nothing needs
to be set up. This default can also be used in low_power_sweep.py,
where the workload object was just a placeholder.
This will allow required functionality like determining endianness of a
system into the workload, rather than (for instance) in the more generic
System object. This also makes accessing less essential functionality
simpler, because we don't have to detect whether the workload is there,
and can just return default, placeholder values from the StubWorkload.
Change-Id: Idfc3e75c65318d75a3eae6a19944ae1f79a2d111
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52103
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In order to fix several regression failures [1] the master/slave
terminology in src/cpu/BaseCPU.py was reintroduced [2].
This patch is addressing the issue by providing 2 different
ways of connecting cpu ports:
*) connectBus: The method assumes an object with a bus interface is
passed as an argument, therefore it tries to bind cpu ports to the
bus.mem_side_ports and bus.cpu_side_ports
*) connectAllPorts: No assumption on the port owning device is made.
The method simply accepts ports as arguments which will be directly
connected to the peer cpu ports
This will be used for example by ruby Sequencers
[1]: https://gem5.atlassian.net/browse/GEM5-775
[2]: https://gem5-review.googlesource.com/c/public/gem5/+/34495
Change-Id: I715ab8471621d6e5eb36731d7eaefbedf9663a71
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52584
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This enables an SE mode execution of binary if added a Board's
superclass.
This has been abstracted from the SimpleBoard.
The 'set_workload' function has been renamed 'set_se_binary_workload'.
This is clearer on its purpose and doesn't overlap with other
'set_workload' functions.
Change-Id: I714425a3b6b98b91e762ad076eba583bc5953ddd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52186
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
This patch moves 'connect_things' to the AbstractBoard constructor,
thereby meaning it does not need to be called directly in gem5
configuration scripts. This method has been changed to private as a
result.
As boards that inherit from AbstractBoard require certain things to be
setup prior to `connect_things` being called, a new abstract function,
`_setup_board` has been created. This is called in the AbstractBoard
constructor before `connect_things` and can be overridden by boards to
setup board properties as required.
Change-Id: I558a4321b850a6b19e20b7d56d0bcae5805114b6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52184
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The override parameter in the constructor has been renamed to to
'download_md5_mismatch'. This makes the purpose of this parameter
clearer.
The default value has been changed from False to True. We found in most
cases we want to re-download files if the md5 values have changes. Not
wanting to do so is the corner case. This allows us to remove a lot of
parameters from test and example scripts, included in this patch.
Change-Id: I99fc7743f5adf78bf6f4f8efc6222e6df83ac6da
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52086
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The purpose of this class is to:
* Create a standard way to set a typical kernel/disk image workload.
* Cleans up the manner in which readfile values/contents are set.
* Allows a user to specify their own kernel arguments, but still sets
sensible defaults.
As of this commit, this interface has been added to the X86Board and the
RISCVBoard.
Change-Id: I34f4c2b829f1ae5c1cae12039436cbb345a89d09
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51949
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
In order to have more fine grained control over which SLICC controllers
are part of which Ruby network in a disjoint configuration, the
create_system function in GPU_VIPER is broken up into multiple construct
calls for each SLICC machine type in the protocol. By default this does
not change anything functionally. A future config will use the construct
calls to explicitly set which network (CPU or GPU) the controller is in.
Change-Id: Ic038b300c5c3732e96992ef4bfe14e43fa0ea824
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/51847
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This device and the file it's in have the same name as one already
defined by arm. This is basically ok when those are mutually exclusive,
but can't coexist when both ISAs can be included at the same time. This
is because the file name would put them both under
m5.objects.VirtIOMMIO, and the name of the object itself would conflict
when importing * from m5.objects.
Change-Id: I558676b7d64cc68adb2d81b070a1816aa0bea6ba
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/50335
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The 'components_library' name was always a placeholder. A more accurate
name would be the 'gem5 library'. This is analogous to standard
libraries shipped as part of programming languages. Over time this will
begin to incorporate more commonly used code at the Python configuration
script level. Most of the former 'components_library' is now in
'gem5.components'.
Change-Id: I5927db7004c43b29c39e7767da3f779627081618
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49691
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some debate on how best to distribute the components
library. This change builds the components library into the gem5 binary.
The components library will now function similar to the `m5` library.
There is no need for awkward imports or obtaining the library from some
third-party source.
Additional incorporated in this patch:
* Added `__init__.py` to the Python modules.
* Fixed a typo in the `abstract_ruby_cache_hierarchy.py` filename.
* Ensured that imports within the library are relative.
Issue-on: https://gem5.atlassian.net/browse/GEM5-1023
Change-Id: I3988c8710cda8dcf7b21109a2cf5c3f1608cc71a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49690
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Austin Harris <mail@austin-harris.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously these scripts were in `configs/example/components-library`
though they are now used purely for testing purposes and have therefore
been moved to `tests/gem5/configs/example/components-library`.
There should be example scripts for usage of the components library, but
these scripts are no longer suitable since being made more flexible for
the purposes of testing.
Change-Id: I7c4d5bb86fe94898f006220dd962841344b1868e
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49558
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This `requires` function allows a simple way to specify ISA, KVM, and
cache coherence protocol requirments within the library and scripts.
An exception will be thrown if the gem5 binary does not meet these
requirements.
The `requires` function may be expanded with other requirements as
needed. At present we only check ISA, KVM, and cache coherence
protocols.
Change-Id: I5c8ff3766ebb9f3292aa553b02781b43d6752775
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49324
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Previously, the RISC-V devices queried the system object in
SimObject::init() for the number of CPUs and the number of threads.
However, the system object doesn't actually count the number of
CPUs/threads until it runs init(). Therefore, we've just been getting
lucky in the order that the SimObject init() functions were called.
This change instead decouples these two functions and makes the number
of CPUs/threads a parameter for the RISC-V interrupt devices. This
change also updates the example config script.
Change-Id: Ic4da5604156837cfeec05e58d188b42a02420de1
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49431
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Ayaz Akram <yazakram@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
The purpose of the gem5 components library is to provide gem5 users a
standard set of common and useful gem5 components pre-built to add to
their experiments. The gem5 components library adopts a modular
architecture design with the goal of components being easy to add and
remove from designs, and extendable as needed. E.g., any Memory system
should be interchangable with any other, and if not a helpful error
messages should be raised.
Examples of using the gem5 components library can be found in
`configs/example/components-library`.
Important Disclaimer:
This is a pre-alpha release of the gem5 components library. The purpose
of this release is to get some community feedback on this new component
of gem5. Though some testing has been done, we expect regular fixes and
improvements until this is in a stable state.
The components library has been formatted with Python Black; typing has
been checked with MyPy; and the library has been tested with the scripts
in `configs/example/components-libary`. More rigorous tests are to be
added in future revisions.
More detailed documentation will appear in future revisions.
Jira Ticket outlining TODOs and known bugs can be found here:
https://gem5.atlassian.net/browse/GEM5-648
Change-Id: I3492ec4a6d8c59ffbae899ce8e87ab4ffb92b976
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47466
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch adds support for a gfx902 Vega APU, ripping the
appropriate values for device_id from the ROCm Thunk
(src/topology.c).
Note: gfx902 isn't officially supported by ROCm. This
means that it may not work for all programs. In particular,
rocBLAS is incompatible with gfx902, so anything that uses
rocBLAS won't be able to run with gfx902.
Change-Id: I48893e7cc9c7e52275fdfd22314f371a9db8e90a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47530
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
ROCm determines if a device is a dGPU in two ways. The first
is by looking at the device ID. The second is through a flag that
gets set only if the reported cpu_cores_count is 0.
If these don't agree, ROCm breaks when doing memory operations.
Previously, cpu_cores_count was non-zero on the Fiji config.
This patch sets it to 0 to appease ROCm
Change-Id: I0fd0ce724f491ed6a4598188b3799468668585f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/47525
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
