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>
The "Regs" structure in the DynInst class was using placement new to
allocate register arrays in a dynamically allocated blob which can be
resized based on the number of source and destination registers.
Unfortunately, it was assumed that the alignment of the components of
that structure would work out because they were ordered from largest to
smallest, which should imply largest alignment to smallest.
This change instead uses an overloaded new operator to allocate extra
memory for the DynInst itself, and then initialize arrays within that
extra space. The DynInst class then gets pointers to the arrays so it
can access them. This has the benefit that only one chunk of memory is
allocated, instead of one for the DynInst and then a second for the
arrays.
Also, this new version uses the alignof operator to figure out what
alignment is needed for each array, which should avoid any undefined
behavior. The new-ing, initialization, destructing, and delete-ing are
also more carefully orchestrated. Hopefully one or both of these will
squash potential memory management bugs.
Change-Id: Id2fa090b53909f14a8cb39801e9930d4608e42f7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52485
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This changeset adds CHI support in the components library. Currently,
only a very simple one level protocol is implemented, but hopefully this
design will be able to scale to other more complex hierarchies.
I've tested this with RISC-V with 1 and 4 cores and with x86 with 1
core. Since we don't have an Arm-compatible board, I haven't tested with
ARM. Note that x86 with more than 1 core boots most of the way, but it
hangs during systemd (the kernel comes up completely).
Change-Id: I56953238c6b0ca5ac754b103a1b6ec05a85a0af5
Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52463
Reviewed-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Use the BaseISA::newPCState(Addr) method instead, so that we don't need
to know how to build PCState objects for the given ISA.
Because the pcState() accessor still takes a const reference to a
PCState, we still need to use the TheISA::PCState type to call it. In
the future this will also take a PCStatePtr, so that use will go away.
Change-Id: I8f2f66b58c342e8c455d438047857c0119566b2b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52054
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are a few places where TheISA::PCState is still necessary,
specifically when checking if a PC is branching, and also when getting
the nextInstAddr.
It's likely that checking if a PC is branching will become part of the
base PCState interface, but nextInstAddr will likely be removed from the
ThreadContext, ExecContext, etc, interfaces, and then removed from the
interfaces in the O3 which doesn't seem to use them internally.
Change-Id: I499f31d569b9b0c665a745caf612d1e96babf37a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52051
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
The minor CPU was using a PCState object both to track redirects when
taking a branch, etc, and to track where to fetch a line of memory from.
It would need to create a new PCState object, or at least update the
existing one, whenever it needed to advance to the next line.
This is problematic since it means the minor CPU needs to know how to
create or set a PCState object, and since it by necessity only
understands the most basic aspect of a PCState, what the address is, it
can only set that, with all the other potential attributes staying at
their old values or getting set to some default.
Instead, this change separates the two. There is now a PC which is used
for redirects which the later stages will only pick up if there is a
change in "sequence", the same behavior as before. This PC will only
ever be set when changing sequence, and will otherwise not be
meaningful/useful.
There is also now a separate fetch address which is what the fetch stage
uses to get new lines. This was all the PC value that was artificially
updated was used for anyway.
Change-Id: Ia64bbe21e980566ae77786999689c9c8a94e9378
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52048
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: ZHENGRONG WANG <seanyukigeek@gmail.com>
Maintainer: ZHENGRONG WANG <seanyukigeek@gmail.com>
By using a PCStateBase pointer or reference, we can (mostly) avoid
having to know what the ISA specific PState class is, letting the ISA
specific instruction classes cast to the type they need internally.
There are a couple minor places where we need to do those casts outside
of ISA specific types, one in the generic NopStaticInstPtr class, and a
few in generic faults.
Right now, we'll just use the TheISA::PCState type in those isolated
spots (sometimes hidden by auto), and deal with it later, possibly
with a virtual "advance" method of some sort.
Change-Id: I774c67dc648a85556230f601e087211b3d5630a9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52043
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Most of the time, the type pointed to by a PCState pointer or reference
will be the same as all the others, if not nullptr.
This change adds a set of "set" functions which assume that the
underlying type of each pointer or reference are the same, and handles
casting, copying things over, creating a new copy, etc, for you. It uses
a new "update" virtual method on PCState subclasses which casts the
source to the same type as the destination and copies values over.
Note that the "set" function doesn't actually verify that the two types
are the same, just like the overloaded ==, != and << operators. In the
future, those checks can be added for debugging purposes, probably
guarded by a configuration variable which can be toggled on or off to
get better performance or more thorough error checking.
The main advantage of these wrappers are that they allows consistent
semantics whether your moving a value from a pointer, or from a yet
unconverted PCState subclass, or vice versa, which will be particularly
helpful while transitioning between using raw PCState instances and
using primarily pointers and references.
This change also adds wrappers which handle std::unique_ptr, which makes
it easier to use them as arguments to these functions. Otherwise, if the
std::unique_ptr is a temporary value, using the return value of .get()
will let the std::unique_ptr go out of scope, making it delete the data
pointed to by the returned pointed. By keeping the std::unique_ptr
around on the stack, that prevents it from going out of scope.
Change-Id: I2c737b08e0590a2c46e212a7b9efa543bdb81ad3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52041
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
This method is the seed which creates a new PCState object of the
appropriate type. It can be used to initialize PCStateBase *s so that they
always point to something valid and can be manipulated without having to
first check if there's something there, as opposed to the alternative
where a pointer might be null until it's first pointed at something.
Change-Id: If06ee633846603acbfd2432f3d8bac6746a8b729
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52040
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Introduce a virtual output() method which prints the current PCState to
the given output stream, and define an overload for << to use that
method. This will make it possible to print a PCState without knowing
what the actual type is.
Change-Id: I663619b168c0b2b90c148b45ae16d77f03934e5b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52039
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
The TraceFile object needs to be registered into the scheduler for
triggering its trace function. For now only the TraceFile created by
sc_create_vcd_trace_file is registered automatically. This design is not
good for users to implement their own TraceFile class.
In addition, some libraries, ex Verilator, implement thier own trace file.
To bridge them into gem5, we also need the ability to create customized
TraceFile class.
Change-Id: I38fe510048655c6a2cd848a0a1263a66a1778eee
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52923
Reviewed-by: Earl Ou <shunhsingou@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This means that if ArchMMU came from the CPU class itself, subclasses
would have a chance to define their own version before the BaseCPU
method consumed it.
The intention is that Arch* *will* be defined in subclasses in later
changes, which will make this more important.
Change-Id: Ib20d5b10aeb26d33840cca4b5a1085d9c73f10de
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52489
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Instead, get the byte order from the workload. The workload has a better
idea what the byte order should be, for instance based on what software
it's loaded or how the hardware was configured, and this gets rid of a
use of TARGET_ISA which was setting a default endianness.
Change-Id: Ic5d8a6f69a664957c4f837e3799ff93397ccfc64
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52106
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
The workload would have a better idea of what it's endianness is than
the system object that holds it. This is the first step towards getting
rid of the getByteOrder method on the system object, which currently
checks TARGET_ISA to determine what the default endianness should be.
If it makes sense for a Workload, it could determine the endianness
dynamically by, for instance, reading it out of a binary image before
putting it into memory.
This does assume that the workload has a consistent endianness
throughout which may not be true, but this is not a new assumption.
Also, mark the SEWorkload SimObject class as "abstract", since it isn't
useful until they get subclassed by some arch specific version.
Change-Id: I8d4ba8382f22236a81f9738cc3506cdb97bdbfb2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52104
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.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>
Also move up the accessors for them. By putting the storage in the base
class, we can keep the accessors non-virtual and keep their overhead
low. Subclasses will be free to set those values to whatever they want
with no overhead, just as if they were natively part of that class.
Change-Id: I58e058def174e0bf591c0a9f050c23f61e9d8823
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52037
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
`setup_memory_ranges()`, now `_setup_memory_ranges()`, had to be called
by subclasses. Since `setup_memory_ranges() was always called at the top
of the `_setup_board()` function (or could be), this function is now
automatically called within the AbstractBoard's constructor prior to
`_setup_board` and `_connect_things`.
Change-Id: I6bf3231666b86059ffc484cfca44e45cfde52ea6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52883
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@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>
With some values of rotations and datasizes, is it possible to call
"bits" with first being smaller than seccond. To prevent it, rcl,
similar to other rotations had an if to check if the value to rotate
is bigger than 1, however, rcl was checking for 'shiftAmt' instead
of 'realShiftAmt'.
This was not detected before because:
1 - The assert triggered in "bits" is from a recent commit
2 - The result is correct.
Change-Id: I669f4e064e12b035538e5dd0cc61eb4546603512
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52803
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
