Input ports can specify a custom handler that is called
on resource stalls. The handler should return 'true' to
indicate the stall was handled and new messages from that
queue can be processed on that cycle. When it returns
'false' or no handler is defined, a resource stall is
generated.
Handlers are defined using the 'rsc_stall_handler' (for
resource stalls) and the 'prot_stall_handler' (for
protocol stalls) parameters. For example:
in_port(mandatory_in, RubyRequest, mandatoryQueue,
rsc_stall_handler=mandatory_in_stall_handler) {
...
}
bool mandatory_in_stall_handler() {
// Do something here to handle the stall !
return true;
// or return false if we don't want to do anything
}
Note: this patch required a change to the generate()
functions interface in the SLICC compiler, so we
could propagate a reference to the in_port to the
appropriate generate() functions. The updated interface
allows passing and forwarding of keyword arguments.
Change-Id: I3481d130d5eb411e6760a54d098d3da5de511c86
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31265
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 functions for connecting the sequencer and cpu ports.
Using these functions instead of wiring up the ports directly allow
protocols to provide specialized sequencer implementations. For
instance, connecting the cpu icache_port and dcache_port to
different sequencer ports or to different sequencers.
A follow-up patch will update the configurations to use these
functions.
Change-Id: I2d8db8bbfb05c731c0e549f482a9ab93f341474b
Signed-off-by: Tiago Mück <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/31417
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 result is returned to the caller from the pseudoInst dispatch
function, the default behavior is to not store that value using the
guestABI mechanism. In the x86 definition, I accidentally used this
version but then didn't store the result manually. The fix should simply
be to not return the result to the instruction definition and to let the
guestABI mechanism handle everything normally.
Change-Id: Ib69f266ad6314032622e5d8d69e9ff114c62657a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/38195
Reviewed-by: Daniel Gerzhoy <daniel.gerzhoy@gmail.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
exp_cnt (expInstsIssued in the code) is used in the waitcnt instruction
to track that data has been read out of VGPRs in previous global
memory instructions, making it safe to overwrite the VGPRs used in said
global memory instructions.
Previously, exp_cnt wasn't being tracked at all, which lead to the
waitcnt finishing immediately, leading to the memory instruction's VPGRs
getting overwritten by subsequent instructions, causing errors.
This patch makes it so waitcnts waiting on exp_cnt will wait for MUBUF
buffer store instructions to read their VGPRs before completing
Change-Id: Idd2b59511bc086cf316217da27b7a228272b0b0f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37555
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com>
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The existing device tree generation method would use the default
frequency as both the min and max frequency when setting up the OSC
device tree nodes. This would sort of work, except it seems that if
the kernel needed to adjust a frequency, it would fail to do so since
it would assume the new frequency was out of range.
Since the existing property is used to set the initial frequency of
those clocks, and because the default, min and max frequencies are all
mostly independent variables (other than obvious ordering restrictions),
two new properties were added, min_freq and max_freq, which are only
there to fill in the frequency range property in the device tree. If
they aren't set, then the device tree generation method falls back to
the old way of using the default frequency as both min and max.
Change-Id: Ie907bd673f8bcb149e69e45c5b486863149b8a68
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Since this class has a custom destructor ~ProbeListener(), it should
also generally have the 4 other methods defined, otherwise calling
those methods lead to subtle failures.
In this specific case, the ProbeManager *const manager; field stores a
pointer back to the ProbeListener object at:
ProbeListener::ProbeListener {
manager->addListener(name, *this);
which gets unregistered by the destructor:
ProbeListener::~ProbeListener()
manager->removeListener(name, *this);
and because the default copy does not re-register anything, it leads to
unregistration.
Therefore, a copy constructor would need the manager to support multiple
identical listeners, or at least refcount them, which would be overkill.
The two move operations would be more feasible, as we could make them
unregister the old ProbeListener address and then re-register the new one,
but that is not very efficient, so we just delete them as well.
A consequence of not implementing the move methods is that it is
impossible to store ProbeListener inside an std::vector. since objects
inside std::vector may need to be moved in memory when the vector resizes,
and therefore need to be movable. The alternative is to use an std::vector
of std::unique_ptr instead.
Change-Id: I8dc0157665391f86e2ca81d144bc6a42e9312d6c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37977
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This register is used since the Linux kernel 5.6 aarch64 boot.
This register indicates CPU capabilities in aarch32 mode, and it has the
same value as the aarch32 ID_ISAR6 miscregister, which is also added.
The capability values of those registers are analogous to those present in
aarch64 accessible ID_AA64ISAR0_EL1 and ID_AA64ISAR1_EL1, which refer to
aarch64 capabilities however, and were already implemented before this
commit.
The arm architecture document clarifies that reads to this system register
location before it had been defined should return 0, but we were faulting
instead:
> Prior to the introduction of the features described by this register,
this register was unnamed and reserved, RES0 from EL1, EL2, and EL3.
Change-Id: I70e99536dc98925e88233fd4c6887bbcdd5d87dc
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/30935
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In clang, the following error was given:
```
In file included from build/X86/sim/eventq.hh:51:
build/X86/sim/serialize.hh:533:19: error: 'ScopedCheckpointSection' is a protected member of 'Serializable'
Serializable::ScopedCheckpointSection sec(os, sectionName);
^
build/X86/sim/serialize.hh:175:11: note: declared protected here
class ScopedCheckpointSection {
^
```
The use, at line 533, was introduced in this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/36135
This can be fixed by making ScopedCheckpointSection public.
Change-Id: Ib6ffba18d5e8c37980d4febb548f2405cb45ce8c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37915
Reviewed-by: Ciro Santilli <ciro.santilli@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>
Once all ISAs are converted, the base StaticInst class will be able to
drop its local arrays, and will no longer need to know what the global
maximum number of source or destination registers is for a given
instruction.
Most of the convertion was very simple and just involved adding tags to
declare and install the register arrays in all the class definitions.
Since SPARC has a relatively simple ISA definition, there weren't many
places that needed to be updated.
The exception was the BlockMem template, which was declaring the microop
classes within the body of the macroop. That was ok when those
declarations didn't need anything other than the name of their parent,
but now they also need to know how big to declare their arrays based on
their actual implementation.
To facilitate that, and to significantly streamline the definition of
the macroop class, the microop class definitions were moved to their own
template, and only the declaration was left in the parent class.
Change-Id: I09e6b1d1041c6a0aeaee63ce5f9a18cf482b6203
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36879
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This will prevent checkpoints from breaking on every miscreg addition.
Before this commit, miscregs were stored as an array:
[system.cpu.isa]
miscRegs=965 0 0 0 0 0 0 0 0 0 0 0 17895697 ...
and after this commit they are stored as a map:
[system.cpu.isa]
[system.cpu.isa.miscRegs]
cpsr=965
spsr=0
spsr_fiq=0
spsr_irq=0
spsr_svc=0
spsr_mon=0
spsr_abt=0
spsr_hyp=0
spsr_und=0
elr_hyp=0
fpsid=0
fpscr=0
mvfr1=17895697
JIRA: https://gem5.atlassian.net/browse/GEM5-661
Change-Id: I49999c7206bd9ac1cfb81297d45c8117ff8ae675
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/36116
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The SmartDict, used by buildEnv, has been added long time ago for
the following reasons: (checking its documentation)
---
The SmartDict class fixes a couple of issues with using the content
of os.environ or similar dicts of strings as Python variables:
1) Undefined variables should return False rather than raising KeyError.
2) String values of 'False', '0', etc., should evaluate to False
(not just the empty string).
---
These are valid reasons, but I believe they should be addressed in
a more standardized way by using a common dictionary.
1) We should simply rely on dict.get
if buildEnv.get('KEY', False/None):
2) We should discourage the use of stringified False or 0.
If we are using a dictionary, can't we just pass those values as
booleans?
The SmartDict is basically converting every value into a
string ("Variable") at every access (__getitem__)
The Variable is a string + some "basic" conversion methods
What is the problem of passing every dict value as a string?
The problem is the ambiguity on the boolean conversion.
If a variable is modelling a boolean, we can return true if
the value is 'yes', 'true'... and false if the value is
'no', 'false' etc. We should raise an exception if it is
something different, like a typo (e.g.) 'Fasle'.
But if the variable is not modelling a boolean, we don't know
how to handle that. How should we convert 'mystring' ?
If we decide to treat 'mystring' as True (which is basically
what a str.__bool__ would return) we will break typoes detection,
as 'Fasle' will now be converted to True, rather than raising
an exception.
Change-Id: I960fbfb1ec0f703e1e372dd752ee75f00632acac
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37775
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Hoa Nguyen <hoanguyen@ucdavis.edu>
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We used to have a hard-coded packet2payload and payload2packet in the
tlm_bridge implementation. However, as the conversion is operated on
generic tlm payload, we're not able to handle information stored in any
user defined SystemC extensions.
In this CL, we add a pair of function to register extra conversion steps
between tlm payload and gem5 packet. This decouples the exact conversion
logic and enables SystemC users to register any necessary steps for
their extensions.
Change-Id: I70b3405395fed0f757f0fb7e19136f47d84ac115
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37075
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
