The debug flags API has a couple of quirks that should be cleaned
up. Specifically:
* Only CompoundFlag should expose a list of children.
* The global enable flag is just called "active", this isn't very
descriptive.
* Only SimpleFlag exposed a status member. This should be in the base
class to make the API symmetric.
* Flag::Sync() is an implementation detail and needs to be protected.
Change-Id: I4d7fd32c80891191aa04f0bd0c334c8cf8d372f5
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34118
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Compound flags are currently constructed using a constructor with a
finite set of arguments that default to nullptr that refer to child
flags. C++11 introduces two cleaner ways to achieve the same thing,
variadic templates and initializer_list. Use an initializer list to
pass dependent flags.
Change-Id: Iadcd04986ab20efccfae9b92b26c079b9612262e
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34115
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Currently there are independent round robin arbiter at each
input port and output port. Every time a VC is selected for
output allocation round robin is incremented irrespective of
if it is selected by its output port or not. This leads to
unfair arbitration at input port and is well known[1]. This
patch fixes it to increment only if the output port also
selects it.
[1] D. U. Becker and W. J. Dally, "Allocator implementations
for network-on-chip routers," Proceedings of the Conference
on High Performance Computing Networking, Storage and
Analysis, Portland, OR, 2009, pp. 1-12
Change-Id: I65963fb8082c51c0e3c6e031a8b87b4f5c3626e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32601
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Currently the Switch Allocator takes up most of the simulation
wall clock time. This function checks for all VCs to see if it
should wakeup next. The input units which are simulated before
the switch allocator could have scheduled it already. This patch
adds a check for it.
Change-Id: I8609d4e7f925aa5e97198f6cd07466530f6fcf4c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32600
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 change allows configuring each router with a certain number
of VCs for each VNET. This is beneficial when dealing with
heterogenous link widths in a system. Configuring VCs
for each router allows one to ensure equal throughput
within the network while avoiding head-of-line blocking.
Changing a router's VCs number can be done in topology files
using the vcs_per_vnet value argument of router.
Change-Id: Icf4f510248128429a1a11f19f9802ee96f340611
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32599
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This upgrades the garnet model to support HeteroGarnet
1) Static and dynamic multi-freq domains in network
2) Support for CDC
3) Separate links for each message class
4) Separate linkwidth for each message class
5) Support for SerDes
Change-Id: I6d00e3b5cb3745e849d221066cb46b2138c47871
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32597
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
During squash of branch predictor history, RAS recovery mess up the
stack because of function "restore" in RAS (src/cpu/pred/ras.cc). In
restore function, it does not update "usedEntries" variable resulting in
restore failure.
To be specific, in order to remove mispredicted call, it uses pop() and
it updates tos. However in order to restore mispredicted ret
instruction, it uses restore() but it does not update tos. This pair of
function call mess up the RAS resulting in many misspeculation.
The solution is to update usedEntries variable as “push” function does.
This is possible because restoration is done with reverse order of push
and pop.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-732
Change-Id: Ia14e71c26d20b2795fd55a6a0dd3284c03570614
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33214
Reviewed-by: Trivikram Reddy <tvreddy@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously `tests/gem5/fs/linux/arm/run.py` contained an ugly,
hard-coded `gem5_root` variable. In this commit we pass `gem5_root`
as an argument from `tests/gem5/fs/linux/arm/test.py`, utilizing
`config.base_dir`.
Change-Id: I2b1e3369b1078cce9375fadb7c39fa4292648658
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33955
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
We were downloading resources to various different locations, for no
real reason. This standardizes the process. From this commit onwards,
all testing resources are downloaded to `tests/gem5/resources` by
default. This may be overriden via the `--bin-path` TestLib argument.
Note: In order to do this I have changed the meaning of the `bin-path`
TestLib argument slightly. Previously the `bin-path` assumed a flat
(non-existant) hierarchy. A simple directory of local resources. This
new bin-path functionality maintains logical sub-directories. This is
technically an API change and will be noted in the release notes.
Change-Id: I4df85c121fa65f787fd71f03d74361afea121380
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33145
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
This is part of a process of getting rid of the `tests/config`
directory, and placing these configs either where they are used,
removing them if unneeded, or moving them to `configs/example`.
These config files, in this patchset, are part of the realview tests
found in `tests/gem5/fs/linux/arm/`. They have been moved to
`tests/gem5/configs`.
Change-Id: I7706b59c58da6413f5f3dd816a1e5cd54a834a58
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33143
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
When the system call happens during the execution of the system call
instruction, it can be ambiguous what state takes precedence, the state
update from the instruction or the system call. These may be tracked
differently and found in an unpredictable order in, for example, the O3
CPU. An instruction can avoid updating any state explicitly, but
implicitly updated state (specifically the PC) will always update,
whether the instruction wants it to or not.
If the system call can be deferred by using a Fault object, then it's no
longer ambiguous. The PC update will be discarded, and the system call
can set the PC however it likes. Because there is no implicit PC update,
the PC needs to be walked forward, either to what it would have been
anyway, or to what the system call set in NPC.
In addition, because of the existing semantics around handling Faults,
the instruction no longer needs to be marked as serializing,
non-speculative, etc.
The "normal", aka architectural, aka FS version of the system call
instructions don't return a Fault artificially.
Change-Id: I72011a16a89332b1dcfb01c79f2f0d75c55ab773
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33281
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Gem5 Hardware Transactional Memory (HTM)
Here we provide a brief note describing HTM support in Gem5 at
a high level.
HTM is an architectural feature that enables speculative concurrency in
a shared-memory system; groups of instructions known as transactions are
executed as an atomic unit. The system allows that transactions be
executed concurrently but intervenes if a transaction's
atomicity/isolation is jeapordised and takes corrective action. In this
implementation, corrective active explicitely means rolling back a
thread's architectural state and reverting any memory updates to a point
just before the transaction began.
This HTM implementation relies on--
(1) A checkpointing mechanism for architectural register state.
(2) Buffering speculative memory updates.
This patch is focusing on the definition of the HTM checkpoint (1)
The checkpointing mechanism is architecture dependent. Each ISA
leveraging HTM support can define a class HTMCheckpoint inhereting from
the generic one (GenericISA::HTMCheckpoint).
Those will need to save/restore the architectural state by overriding
the virtual HTMCheckpoint::save (when starting a transaction) and
HTMCheckpoint::restore (when aborting a transaction).
Instances of this class live in O3's ThreadState and Atomic's
SimpleThread. It is up to the ISA to populate this instance when
executing an instruction that begins a new transaction.
JIRA: https://gem5.atlassian.net/browse/GEM5-587
Change-Id: Icd8d1913d23652d78fe89e930ab1e302eb52363d
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30314
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This class can already accept a proxy variable and a "functor" which is
a pointer to either a function or an instance of a class with the ()
operator overloaded.
This change adds a FunctorProxy partial specialization which accepts
anything that can be used to construct a std::function<Result()>. The
constructor argument is copied and stored in the proxy which makes it
possible to define a lambda inline without having to keep a copy of it
around for the proxy to point to.
Also, the ValueBase stat's functor method now has a second version which
accepts a const reference rather than just a reference to its argument.
We need both because when accepting a reference to a lambda it needs to
be a const reference, but when accepting a pointer to a functor object,
we don't want it to be const because that would force the () operator to
also be const.
Change-Id: Icb1b3682d51b721f6e16614490ed0fe289cee094
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/32901
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
If the cxx_type value changes, then the way the parameter is declared
in the param struct will also change, and the header needs to be
updated. scons would miss this sort of change before because it was only
checking the module the SimObject's source came from. The python names
and types of the parameters could stay the same, but the C++
representation might have changed because of edits somewhere else.
This CL assumes that cxx_type is the only thing that will change and
transparently affect the params struct. I tried making scons sensitive
to the entire ptype which would capture other parameters, but that
didn't work for some reason. This should be pretty safe in general, but
not 100% safe
Issue-on: https://gem5.atlassian.net/browse/GEM5-753
Change-Id: I06774889e60b987f727799f55d7ea2a775b6a319
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33695
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This test, which measures the performance of cprintf vs. sprintf, was
missing a couple of includes which were needed for the alarm() and
signal() functions, as well as the SIGALRM constant.
Also, it was using %#x to print the value of a pointer which gcc
complained about when compiling sprintf. This is fixed by changing that
format specifier to %p, the specifier to use when printing pointers.
Apparently either the implicit conversion to an integer value (which %#x
expects) or the size of the type it was converted to weren't good enough
for gcc any more.
Change-Id: I8eca3479bef2c2fa79f8ef4881bb3ff35d7c54ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33897
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
