The following APIs are not exported from the _m5 namespace and not
used by any of the debug glue code:
* m5.debug.findFlag
* m5.debug.setDebugFlag
* m5.debug.clearDebugFlag
* m5.debug.dumpDebugFlags
All of them have a clean Python interface where flags are exported
using the m5.debug.flags dictionary. There is also an m5.debug.help
function that lists the available debug flags.
Remove the unused APIs to avoid confusion.
Change-Id: I74738451eb5874f83b135adaccd30a0c6b478996
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34120
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>
There is currently no Python API to check if a debug flag is
enabled. Add a new status property that can be read or set to control
the status of a flag. The stat of a flag can also be queried by
converting it to a bool.
For example:
m5.debug.flags["XBar"].status = True
if m5.debug.flags["XBar"]:
print("XBar debugging is on")
Change-Id: I5a50c39ced182ab44e18c061c463d7d9c41ef186
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/34119
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>
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>
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>
Allow all sub-compressors of BDI to be successful as long as
they are able to compress. Then, BDI's actual size threshold
acts as the cutting point.
This situation arises on any multi compressor; yet, generalizing
this assumption might be too bold.
Change-Id: Iec5057d16d4a7ba5fb573133a30ea10869bd67e0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33386
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The size can be zero in special occasions, which would
generate divisions by zero. This patch expands the
stats to support them. It also fixes the compression
factor calculation in the Multi compressor.
As a side effect, now that zero sizes are handled, allow
the Zero compressor to generate it.
Change-Id: I9f7dee76576b09fdc9bef3e1f3f89be3726dcbd9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33383
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
When compressing using a multi-compressor, one must be able to
identify which sub-compressor should be used to decompress data.
This can be achieved by either adding encoding bits to block's
tag or data entry.
It was previously assumed that these encoding bits would be added
to the tag, but now make it a parameter that defaults to the data
entry.
Change-Id: Id322425e7a6ad59cb2ec7a4167a43de4c55c482c
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33380
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The compressors are not able to process a whole line at once,
so they must divide it into multiple same-sized chunks. This
patch makes the base compressor responsible for this division,
so that the derived classes are mostly agnostic to this
translation.
This change has been coupled with a change of the signature
of the public compress() to avoid introducing a temporary
function rename. Previously, this function did not return
the compressed data, under the assumption that everything
related to the compressed data would be handled by the
compressor. However, sometimes the units using the compressor
could need to know or store the compressed data.
For example, when sharing dictionaries the compressed data
must be checked to determine if two blocks can co-allocate
(DISH, Panda et al. 2016).
Change-Id: Id8dbf68936b1457ca8292cc0a852b0f0a2eeeb51
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33379
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously either the compression data was the one declared within
DictionaryCompressor, or the derived class would have to override
the compress() to use a derived compression data.
With this change, the instantiation can be overridden, and thus
any derived class can choose the compression data pointer type
they need to use.
Change-Id: I387936265a3de6785a6096c7a6bd21774202b1c7
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/33378
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
