Current [TraceCPU
documentation](https://www.gem5.org/documentation/general_docs/cpu_models/TraceCPU)
still references the deprecated **se.py/fs.py** scripts for elastic
trace generation (script paths are also outdated).
With this PR we provide a simpler Arm based elastic trace generation
script that can
be used out of the box by a user or that can be extended as needed.
According to the original paper [1] the elastic trace generation process
requires a cpu with a big number of entries in the ROB, LQ and SQ, so
that there are no stalls due to resource limitation.
At the moment these numbers are copy pasted from the
CpuConfig.config_etrace method [2].
[1]: https://ieeexplore.ieee.org/document/7818336
[2]: https://github.com/gem5/gem5/blob/stable/\
configs/common/CpuConfig.py#L40
Change-Id: I00fde49e5420e420a4eddb7b49de4b74360348c9
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Richard Cooper <richard.cooper@arm.com>
- A new abstract BTB class is created to enable different BTB
implementations. The new BTB class gets its own parameter
and stats.
- An enum is added to differentiate branch instruction types.
This enum is used to enhance statistics and BPU management.
- The existing BTB is moved into `simple_btb` as default.
- An additional function is added to store the static instruction in
the BTB. This function is used for the decoupled front-end.
- Update configs to match new BTB parameters.
Change-Id: I99b29a19a1b57e59ea2b188ed7d62a8b79426529
Signed-off-by: David Schall <david.schall@ed.ac.uk>
Make it possible to read any type of reg, assuming it fits in a RegVal.
This avoids assuming building in a dependency on the readIntReg
accessor.
It also avoids setting up a situation where the API could at least
theoretically base the timing expression on the value of *any* int reg,
even ones the instruction does not interact with. The ...ReadIntReg
expression was only ever used with the result of the ...SrcReg
expression, and in my opinion, that's realy the only way it makes sense
to use it. It doesn't seem useful to split that operation into two
parts.
If it actually does make sense (although I doubt this), these operations
can't really be generalized easily since the TimingExpr... classes all
expect to pass around uint64_ts, and a RegId, the *real* value of a
SrcReg index which does not assume a register type, would not fit in
that in the general case.
Change-Id: I253a0a058dc078deeb28ef0babead4c8ffc3b792
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/49776
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
The BaseCPU type had been specializing itself based on the value of
TARGET_ISA, which is not compatible with building more than one ISA at a
time.
This change refactors the CPU models so that the BaseCPU is more
general, and the ISA specific components are added to the CPU when the
CPU types are fully specialized. For instance, The AtomicSimpleCPU has a
version called X86AtomicSimpleCPU which installs the X86 specific
aspects of the CPU.
This specialization is done in three ways.
1. The mmu parameter is assigned an instance of the architecture
specific MMU type. This provides a reasonable default, but also avoids
having having to use the ISA specific type when the parameter is
created.
2. The ISA specific types are made available as class attributes, and
the utility functions (including __init__!) in the BaseCPU class can
refer to them to get the types they need to set up the CPU at run time.
Because SimObjects have strange, unhelpful semantics as far as assigning
to their attributes, these types need to be set up in a non-SimObject
class, which is then brought in as a base of the actual SimObject type.
Because the metaclass of this other type is just "type", things work
like you would expect. The SimObject doesn't do any special processing
of base classes if they aren't also SimObjects, so these attributes
survive and are accessible using normal lookup in the BaseCPU class.
3. There are some methods like addCheckerCPU and properties like
needsTSO which have ISA specific values or behaviors. These are set in
the ISA specific subclass, where they are inherently specific to an ISA
and don't need to check TARGET_ISA.
Also, the DummyChecker which was set up for the BaseSimpleCPU which
doesn't actually do anything in either C++ or python was not carried
forward. The CPU type still exists, but it isn't installed in the
simple CPUs.
To provide backward compatibility, each ISA implements a .py file which
matches the original .py for a CPU, and the original is renamed with a
Base prefix. The ISA specific version creates an alias with the old CPU
name which maps to the ISA specific type. This way, old scripts which
refer to, for example, AtomicSimpleCPU, will get the X86AtomicSimpleCPU
if the x86 version was compiled in, the ArmAtomicSimpleCPU on arm, etc.
Unfortunately, because of how tags on PySource and by extension SimObjects
are implemented right now, if you set the tags on two SimObjects or
PySources which have the same module path, the later will overwrite the
former whether or not they both would be included. There are some
changes in review which would revamp this and make it work like you
would expect, without this central bookkeeping which has the conflict.
Since I can't use that here, I fell back to checking TARGET_ISA to
decide whether to tell SCons about those files at all.
In the long term, this mechanism should be revamped so that these
compatibility types are only available if there is exactly one ISA
compiled into gem5. After the configs have been updated and no longer
assume they can use AtomicSimpleCPU in all cases, then these types can
be deleted.
Also, because ISAs can now either provide subclasses for a CPU or not,
the CPU_MODELS variable has been removed, meaning the non-ISA
specialized versions of those CPU models will always be included in
gem5, except when building the NULL ISA.
In the future, a more granular config mechanism will hopefully be
implemented for *all* of gem5 and not just the CPUs, and these can be
conditional again in case you only need certain models, and want to
reduce build time or binary size by excluding the others.
Change-Id: I02fc3f645c551678ede46268bbea9f66c3f6c74b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/52490
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Python 2.7 used to return lists for operations such as map and range,
this has changed in Python 3. To make the configs Python 3 compliant,
add explicit conversions from iterators to lists where needed, replace
xrange with range, and fix changes to exec syntax.
This change doesn't fix import paths since that might require us to
restructure the configs slightly.
Change-Id: Idcea8482b286779fc98b4e144ca8f54069c08024
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/16002
Reviewed-by: Gabe Black <gabeblack@google.com>
Replacement policies (LRU, Random) are currently considered as array
indexing methods, but have completely different functionalities:
- Array indexers determine the possible locations for block allocation.
This information is used to generate replacement candidates when
conflicts happen.
- Replacement policies determine which of the replacement candidates
should be evicted to make room for new allocations.
For this reason, they were split into different classes. Advantages:
- Easier and more straightforward to implement other replacement
policies (RRIP, LFU, ARC, ...)
- Allow easier future implementation of cache organization schemes
As now we can't assure the use of sets, the previous way to create a
true LRU is not viable. Now a timestamp_bits parameter controls how
many bits are dedicated for the timestamp, and a true LRU can be
achieved through an infinite number of bits (although a few bits suffice
in practice).
Change-Id: I23750db121f1474d17831137e6ff618beb2b3eda
Reviewed-on: https://gem5-review.googlesource.com/8501
Reviewed-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Nikos Nikoleris <nikos.nikoleris@arm.com>
The High-Performance In-order (HPI) CPU timing model is tuned to be
representative of a modern in-order ARMv8-A implementation. The HPI
core and its supporting simulation scripts, namely starter_se.py and
starter_fs.py (under /configs/example/arm/) are part of the ARM
Research Starter Kit on System Modeling. More information can be found
at: http://www.arm.com/ResearchEnablement/SystemModeling
Change-Id: I124bd06ba42d20abff09d447542b031d17eabe22
Signed-off-by: Ashkan Tousi <ashkan.tousimojarad@arm.com>
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/4201
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
This patch adds some more functionality to the cpu model and the arch to
interface with the vector register file.
This change consists mainly of augmenting ThreadContexts and ExecContexts
with calls to get/set full vectors, underlying microarchitectural elements
or lanes. Those are meant to interface with the vector register file. All
classes that implement this interface also get an appropriate implementation.
This requires implementing the vector register file for the different
models using the VecRegContainer class.
This change set also updates the Result abstraction to contemplate the
possibility of having a vector as result.
The changes also affect how the remote_gdb connection works.
There are some (nasty) side effects, such as the need to define dummy
numPhysVecRegs parameter values for architectures that do not implement
vector extensions.
Nathanael Premillieu's work with an increasing number of fixes and
improvements of mine.
Change-Id: Iee65f4e8b03abfe1e94e6940a51b68d0977fd5bb
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
[ Fix RISCV build issues and CC reg free list initialisation ]
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/2705
When importing the cores.arm package, we currently throw an exception
if a timing model can't be imported due to a missing dependency (e.g.,
the required CPU model wasn't included in the build). This is
undesirable since it prevents other, working, timing models from being
added to the package. Wrap the import_module call in a try-except
block and skip timing models that have missing dependencies.
Change-Id: I92bab62c989f433a8a4a7bf59207d9d81b3d19e1
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/3946
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>
