These were all set to 8 * sizeof(char) instead of using the size of the
actual data type being traced.
Also add a very simple implementation to the generic sc_signal_in_if<T>
sc_trace which just delegates to the sc_trace of the underlying type T.
Change-Id: I129df46ef9d49705dc3dac76e30c0a3652c981eb
Reviewed-on: https://gem5-review.googlesource.com/c/12818
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
This avoids a place where data has its endianness switched so that when
the endianness based accessors switch it back it returns to normal. It
also makes it easier to show intent when accessing single bytes where
endianness doesn't matter, and there's no contextual endianness.
Change-Id: I1b97396c1b9bb39727d35112d90e3969e5fe0aab
Reviewed-on: https://gem5-review.googlesource.com/c/13455
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Trying to compile an ARM C hello world with arm-linux-gnueabihf-gcc from
Ubuntu 16.04 leads to a runtime failure with se.py:
FATAL: kernel too old
because the glibc tests if the kernel is at least 3.2.0, and gem5 was
reporting 3.0.0.
Furthermore, it is hard to obtain such toolchain at all: for example
crosstool-NG currently only allows for minimum kernels above 3.2.0.
3.7.0+ was chosen to match the aarch64 value, as it is likely that the
level of support will be very similar.
This commit does not guarantee that full 3.7.0 is supported, but it is
not likely that we had full 3.0.0 support previously either.
However, it is more likely that such support will be eventually achieved
if users can at least try out their programs and implement the missing
system calls as they are found.
Change-Id: I8df3763ae49788a6cb11cb0920e8202cd56b0f09
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/12986
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
ReplaceableEntry is referenced by many classes that do
not necessarily need access to the replacement policies.
Therefore, in order to allow better compilation units,
we factor it out to a new file.
Change-Id: I0823567bf1ca336ffcdf783682ef473e8878d7fd
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/13418
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Implementation of a Tree-PLRU replacement policy. It is based on
the assumption that a set associative cache is used.
Change-Id: I74b227e88fd6c93aab5bb2cd0e8730376db28f52
Reviewed-on: https://gem5-review.googlesource.com/c/11106
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Replacement policies aren't aware of cache sets and do not
organize blocks based on replacement data. Block search is
independent of block placement.
Besides, indexing policies have their own way of addressing
the sets, therefore there is no need to use this class anymore.
BlkType has been removed, as it wasn't being used.
Change-Id: Ia79c2a491e59f295c8d60a0466c317eb0e2bdab9
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/9782
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
Split indexing functionality from tags, so that code duplication
is reduced when adding new classes that use different indexing
policies, such as set associative, skewed associative or other
hash-based policies.
An indexing policy defines the mapping between an address' set
and its physical location. For example, a conventional set assoc
cache maps an address to all ways in a set using an immutable
function, that is, a set x is always mapped to set x. However,
skewed assoc caches map an address to a different set for each way,
using a skewing function.
FALRU has been left unmodified as it is a specialization with its
own complexity.
Change-Id: I0838b41663f21eba0aeab7aeb7839e3703ca3324
Reviewed-on: https://gem5-review.googlesource.com/c/8885
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Replaceable entries belong to table-like structures, and therefore
they should be indexable by combining a row and a column. These,
using conventional cache nomenclature translate to sets and ways.
Make these entries aware of their sets and ways. The idea is to
make indexing policies usable by other table-like structures. In
order to do so we move sets and ways to ReplaceableEntry, which
will be the common base among table entries.
Change-Id: If0e3dacf9ea2f523af9cface067469ccecf82648
Reviewed-on: https://gem5-review.googlesource.com/c/12764
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Having the blocks initialized in the constructor makes it harder
to apply inheritance in the tags classes. This patch decouples
the block initialization functionality from the constructor by
using an init() function. It also sets the parent cache.
Change-Id: I0da7fdaae492b1177c7cc3bda8639f79921fbbeb
Reviewed-on: https://gem5-review.googlesource.com/c/11509
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Decouple Tags from Packets, only extracting the necessary
functionality for block insertion. As a side effect, create
a new function to update common insertion statistics.
Change-Id: I5c58f7c17de3255beee531f72a3fd25a30d74c90
Reviewed-on: https://gem5-review.googlesource.com/c/11098
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
Accellera allows some non-standard values in the second position of the
SC_CTHREAD macro. Do that as well, with the same special handling which
automatically selects the positive edge of boolean ports/interfaces.
Change-Id: I79594980898a17afc30fea6f77384589cbc3c250
Reviewed-on: https://gem5-review.googlesource.com/c/12809
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The Accellera implementation looks like it does all the methods, then
all the threads, and then loops back and tries again, and there are
even comments in the code that suggests that. What it actually does,
however, is runs all the methods, then runs a single thread if one is
waiting, and then starts over. The effect is that the scheduler will
run any methods first, then run threads until a method might have
become ready, and then repeat.
This will actually result in more mixing of threads and methods, more
context switches, and worse performance, but it makes the regressions
pass more.
Change-Id: I7cb0485e26eed79204ff2a3c3ded27b973e0b7b0
Reviewed-on: https://gem5-review.googlesource.com/c/12808
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Make BindInfo into a more general purpose Port class which mirrors
sc_module and Module, sc_object and Object, etc. This tracks multiple
bindings internally, and also pending sensitivities. Keep a global
list of ports which are added in reverse order to match Accellera, and
which is iterated over to finalize binding and for phase callbacks.
This is as opposed to doing it one module at a time, and is to better
match Accellera's ordering for the regressions.
Also the sensitivity classes are now built with factory functions,
which gets around problems calling virtual functions from their
constructors or forgetting to having to have extra boilerplate each
place they're constructed.
The port class also now finalizes port or event finder sensitivities
when its binding is completed, unless it's already complete in which
case it does so immediately.
Change-Id: I1b01689715c425b94e0f68cf0271f5c1565d8c61
Reviewed-on: https://gem5-review.googlesource.com/c/12806
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Dynamic and Static sensitivities used to be represented by the same
classes, even though they're (almost) disjoint in how they worked. Also
timeouts, which can be used alongside dynamic sensitivities, were
handled by the sensitivities themselves. That meant that the
sensitivity mechanism had to mix in more types of behaviors,
increasing complexity. Also, the non-standard timed_out function
Accellera includes is harder to implement if the path for timeouts and
regular sensitivities are mixed together.
This change splits up dynamic and static sensitivities and splits out
timeouts. It also immitates the ordering Accellera uses when going
through sensitivities for an event. Static sensitivities are triggered
first in reverse order (why?), and then dynamic sensitivities are
triggered in what amounts to reverse order. To delete a sensitivity
which has been handled, it's swapped with the one in the last position,
and then the vector is truncated to drop it at the end. This has the
net effect of stirring the dynamic sensitivities, and isn't easily
immitated using a different approach, even if other approaches would
be more straightforward.
Double check addSensitivity for event.hh
Change-Id: I1e73dce386b95f68e9d6737deb8bed70ef717e0d
Reviewed-on: https://gem5-review.googlesource.com/c/12805
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
The datatype code was checking if SC_LONG_64 was defined to determine
if a long was 64 bits. The code that would define that value was
dropped when porting over from the Accellera implementation, and so
the wrong code was being included. This change both makes those checks
look at the *value* of SC_LONG_64 to ensure that it's not missing by
accident, and assigns it a value in sc_fxdefs.hh.
Change-Id: Ie9bb1146452a3db1d9d99c0db575098bb06463ff
Reviewed-on: https://gem5-review.googlesource.com/c/12616
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
We were keeping track of processes which should be initialized and
those which shouldn't on two different lists, and then processing
each list one after the other. This could reorder processes from the
order they were created, and so cause spurious differences which cause
the Accellera tests to fail.
This does make the scheduler slightly simpler, so it's not all bad.
Change-Id: I63306a41ce7bea91fa9ff2f6774ce9150134ce48
Reviewed-on: https://gem5-review.googlesource.com/c/12613
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
It's totally legal to signal that an event happened to waiting
processes in any order we choose, but to match the order of events
which appears in the Accellera test golden output, we need to do things
in the order they did. This is less efficient, but will reduce the
number of false positives.
Change-Id: Ie2882249ae846991d627f5f688a9e89e629bb300
Reviewed-on: https://gem5-review.googlesource.com/c/12612
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Since we don't track the current process using the sc_curr_proc_handle
structure, we keep one around just to return from the appropriate
accessor, and set its values when it's requested. If the object is
kept around, those values won't change to track changing processes.
From what I see, none of the tests rely on the value tracking the
process beyond the callsight.
Change-Id: I1ad3b7a7b15aa0bc4d218f986ffbe7c51501b296
Reviewed-on: https://gem5-review.googlesource.com/c/12611
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
