The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
On the O3 CPU, when the number of threads on the CPU (SMT) is too low to
hold all the old style CPU workload items, then it would increase the
number of threads to match. There are three problems with this.
1. This behavior was only implemented on O3.
2. It could silently hide a bug in the config where the number of
workload items was accidentally too big.
3. It makes the DerivO3CPUParams struct tamper with itself in the
create() method, which means not even config.ini will accurately
reflect the actual config of the system.
Change-Id: I0aab70d4b98093f7f14156ca437e763f031049ab
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35937
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently, when the numThreads parameter is set to something larger than
1 in full system mode, the O3 CPU will just silently change it back down
again to 1. This could be confusing to the user since it won't be
immediately apparent, even when looking at config.ini, that their config
isn't being respected.
This change moves that check into the CPU constructor, where CPU
behavior probably should be rather than the create() method which should
just build the object, and also turns it into an error.
Change-Id: I627ff8702b5e8aaad8839aa8d52524690be25619
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35936
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The fetch policy is only meaningful for SMT simulations. The
"SingleThreaded" value is a placeholder which is the default, and is
only supposed to be used in non-SMT simulations.
Rather than have this enum value and have special checks for it in
various places in O3, we can just eliminate it and set the default,
which is still only meaningful in SMT simulations, be an SMT fetch
policy.
The DerivO3CPUParams::create() function would forcefully change the
the fetch policy from "SingleThreaded" to "RoundRobin" anyway if there
were more than one thread, so that can be the actual default instead of
the shadow effective default.
Change-Id: I458fda00b5bcc246b0957e6c937eab0c5b4563c3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35935
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
All parameters in functions defined within SLICC are const& by default
(except for the implicit types, e.g. TBE). This allow us to specify
if we want to pass parameters as & or const&. Default behavior is
maintained.
A use case is to allow refactoring of common code in actions that
enqueue messages. Messages can be passed as a non-const ref. to
to functions with common initialization. E.g.:
void initRequestMsg(RequestMsg & out_msg) {
// Common msg init code
}
action(sendRequest1, ...) {
enqueue(...) {
initRequestMsg(out_msg);
// Request1 specific code
}
}
action(sendRequest2, ...) {
enqueue(...) {
initRequestMsg(out_msg);
// Request2 specific code
}
}
Change-Id: Ic6a18169a661b3e36710b2a9f8a0e6bc5fce40f8
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31259
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Added mapAddressToDownstreamMachine that may be used by the protocols
to map an address to different target donwstream controller of the same
type.
These functions do not use the global mapping provided by the network
and map addresses to one of the controllers specified in the
downstream_destinations parameter.
This change facilitates reusing the same cache state-machine/controllers
to model different levels of the cache hierarchy.
Change-Id: I9a202e9461e0d2f16ed232ff8b60bbde2d15570d
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31415
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Returns the offset of an address with respect to a base address.
Looks unnecessary, but SLICC doesn't support casting and the '-'
operator for Addr types, so the alternative to this would be to add
more some helpers like 'addrToUint64' and 'uint64ToInt'.
Change-Id: I90480cec4c8b2e6bb9706f8b94ed33abe3c93e78
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31270
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There has been some testing of this wrapper, but some components are
missing. It's not currently possible to read or set Misc registers,
64 bit integer registers, flattened integer registers, or vector
registers. In some cases that's because no mapping from gem5 indexes
to IRIS resource names has been set up, but in some cases, since R52
is 32 bit, no mapping *can* be set up, and we need to figure out what
to do with requests for 64 bit only state.
Change-Id: I2d650a7c1765b39f25058727502c96e6de5aa26b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35635
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This script was ported to python from a bash script by me back in 2011.
The original file didn't have a copyright, but since I made significant
modifications to it (porting it to python, improving its features), at
least those modifications should have become copyright Google.
Change-Id: Ia70bb1e6be5b188537bcf6899ba5884b359dbe18
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35875
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Add incomingTransactionStart/End and outgoingTransactionStart/End
functions that can be called from the protocol to profile events
that initiate a transaction locally (e.g. an incoming request) and
remotely (e.g. outgoing requests). The generated stats will include
histograms of the latency for completing each type of transaction.
This assumes assumes the protocol uses different trigger events for
initiating incoming and outgoing transactions.
Change-Id: Ib528641b9676c68907b5989b6a09bfe91373f9c9
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31421
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: John Alsop <johnathan.alsop@amd.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are cases in which we need to prevent randomization for a
specific buffer when enabled at the RubySystem level (e.g. a internal
trigger queue that requires zero latency enqueue, while other buffers
can be randomized).
This changes the randomization parameter to support enabling and
disabling randomization regardless of the RubySystem setting.
Change-Id: If7520153cc5864897fa42e8911a6f8acbcf01db5
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31419
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Templated types can now be used within structures defined in SLICC.
Usage is similar to the TBETable: the templated type must have all
possible methods in it's SLICC definition. Eg.:
structure(Map, desc="Template map definition") {
MachineID lookup(Addr);
MachineID lookup(int);
}
structure(SomeType, desc="Some other struct definition") {
MachineID addrMap, template="<Addr,MachineID>";
MachineID intMap, template="<int,MachineID>";
}
Change-Id: I02a621cea5e4a89302762334651c6534c6574e9d
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31264
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Bradford Beckmann <bradford.beckmann@gmail.com>
Maintainer: Bradford Beckmann <bradford.beckmann@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Before, for historical reasons, the PCI host device was the default
responder on the IO bus, meaning that when there was any type of
transaction which didn't have a device to go to, it would end up
looking like a PCI config transaction. It's very unlikely that this is
what it actually was, and what would happen would be arbitrary and
probably not helpful.
Also, there was no device in place to respond to accesses in x86's IO
port address space. On a real system, these accesses just return junk
and are otherwise legal. On systems where there would be physical bus
wires they would probably return whatever the last data on the bus was.
This would have been helpful when the platform was first being set up
because it would make it obvious when the OS tried to access a device
that wasn't implemented, but there were a few cases where it would
purposefully fiddle with ports with nothing on them. These had one off
backing devices in the config which would handle the accesses
harmlessly, but if the OS changed and tried to access other ports, the
configs would need to be updated.
Now, the PCI host is just another device on the bus. It claims all of
the PCI config space addresses, so any config access, even ones which
don't go with a device, will go to it, and it can respond with all 1s
like it's supposed to.
In it's place, the default responder is now a bus. On that bus is
a device which responds to the entire IO port address range with 0s.
The default on *that* bus is a device which will mark any accesses
as bad.
With this setup, accesses which don't go to a device, including a
device on the IO port address space, will go to the IO bus's default
port. There, if the access was an IO access, it will go to the device
which replies successfully with all 0s. If not, it's marked as an
error.
The device which backs the entire IO address space doesn't conflict
with the actual IO devices, since the access will only go towards it
if it's otherwise unclaimed, and the devices on the default bus don't
participate in routing on the higher level IO bus.
Change-Id: Ie02ad7165dfad3ee6f4a762e2f01f7f1b8225168
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35515
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Global stats are currently exposed using the legacy stat system (i.e.,
without a parent group). This change moves global stats from
stat_control.cc to a group that gets exported from the Root object.
The implementation adds the Root::Stats class which has a single
global instance. This instance is exposed to the rest of the simulator
using the global rootStats symbol. The intention is that objects that
need global statistics in formulas access them through the rootStats
object.
The global names simSeconds, simTicks, simFreq, and hostSeconds are
now references to their respective members in the rootStats object.
Change-Id: I267b5244a0bcca93dd2dcf03388e7085bdd79c9e
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35616
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Ruby prefetcher's non-unit filter is a circular queue, so use the class
created for this functionality.
This changes the behavior, since previously iterating through the
filter was completely arbitrary, and now it iterates from the
beginning of the queue to the end when accessing and updating
the filter's contents.
Change-Id: I3148efcbef00da0c8f6cf2dee7fb86f6c2ddb27d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24533
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Ruby prefetcher's unit filter is a circular queue, so use the class
created for this functionality.
This changes the behavior, since previously iterating through the
filter was completely arbitrary, and now it iterates from the
beginning of the queue to the end when accessing and updating
the filter's contents.
Change-Id: I834be88a33580d5857c38e9bae8b289c5a6250b9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/24532
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These regular expressions search code snippets to find places where
operands are used. Rather than build them explicitly at the end of
processing the operands{{}} construct, wait until they're first going to
be used. That way, we'll be able to define operands in as many places as
we want, as long as we've done all we're going to do before the first
instructions are defined.
This will pave the way to defining operands in regular python in let
blocks, and then possibly outside of the parser altogether, perhaps into
scons where having lots of output files for individual instructions will
be easier to manage. For now, this just lets you define multiple
operands blocks which is not all that exciting on its own :)
Change-Id: I1179092316c1c0ac2613810bfd236a32235502fb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35237
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Reviewed-by: Steve Reinhardt <stever@gmail.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Messages may be enqueued and be ready in the same cycle.
Using this feature may introduce nondeterminism in the protocol and
should be used in specific cases. A case study is to avoid needing an
additional cycle for internal protocol triggers (e.g. the All_Acks
event in src/mem/ruby/protocol/MOESI_CMP_directory-L2cache.sm).
To mitigate modeling mistakes, the 'allow_zero_latency' parameter must
be set for a MessageBuffer where this behavior is acceptable.
This changes also updates the Consumer to schedule events according to
this new behavior. The original implementation would not schedule a new
wakeup event if the wakeup for the Consumer had already been executed
in that cycle.
Additional authors:
- Tuan Ta <tuan.ta2@arm.com>
Change-Id: Ib194e7b4b4ee4b06da1baea17c0eb743f650dfdd
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31255
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Encapsulate this variable to facilitate polymorphism.
- The status enum was renamed to CoherenceBits, since it
lists the coherence bits supported by the CacheBlk.
- status was made protected and renamed to coherence since
it contains the coherence bits.
- Functions to set, clear and get the coherence bits were
created.
- To set a status bit, the block must be validated first.
This guarantees a constant flow and helps catching bugs.
As a side effect, some of the modified files contained long
lines, which had to be split.
Change-Id: I558cc51ac685d30b6bf298c78f86a6e24ff06973
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34960
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
