The VGPR-offset used when SGPR-base addressing is used can be signed in
Vega. These are global instructions of the format:
`global_load_dword v0, v1, s[0:1]`. This is not explicitly stated in the
ISA manual however based on compiler output the offset can be negative.
This changeset assigns the offset to a signed 32-bit integer and the
compiler takes care of the signedness in the expression which calculates
the final address. This fixes a bad address calculation in a rocPRIM
unit test.
Change-Id: I271edfbb4c6344cb1a6a69a0fd3df58a6198d599
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67412
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
This port will stop execution on the CPU when raised. When lowered, it
will allow execution to reset the state of the CPU and allow execution
to resume. The state could theoretically be reset when the reset state
starts, but then it wouldn't reflect the most up to date condition of
the CPU when resuming. For instance, if a reset vector was set
somehow, that wouldn't be updated if it was changed while reset was
asserted. The tradeoff is that the state won't look like it will when
execution resumes while reset is held (to GDB for instance), but that
seems like a more obvious and less common sort of problem.
This signal is managed by the BaseCPU itself, but is backed by a
virtual method which can be overridden by other CPU types which may
not work the same way or have the same components. For instance, a
fast model CPU could toggle reset lines on the underlying model and
let it handle resetting all the state.
The fast models in particular already have a generic reset line with
the same name, but they have it at the level of the fast model which
may have multiple cores within it, each represented by a gem5 CPU.
It isn't implemented here, but there could be some sort of cooperation
between these signals where the reset at the core level is considered
an "or" of the cluster level reset and the individual core level
resets. At least in the A76 model, there are resets for each individual
core within the cluster as well, which the generic reset toggles.
Another option would be to get rid of the whole cluster reset pin, and
make the user gang the resets for each of the cores together to
whatever reset signal they're using. That's effectively what the
cluster level reset is doing, but within the C++ of the model wrapper
instead of in the python config.
Change-Id: Ie6b4769298ea224ec5dc88360cbb52ee8fbbf69c
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67574
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Roger Chang <rogerycchang@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
In the current implementation pollqueue is not thread safe. The design
of multi threads handle async events is thus causing issue in parallel
environment. Given the low rate of async events, it should be OK to only
handle them in the main thread to avoid unexpected racing issues.
Change-Id: Iddd512235e84e9d77f60985bb1771aa4cc693004
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67533
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These are the "reset" and "po_reset" lines. It seems reasonable that
these are the normal reset and the power on reset signals, but that's
not spelled out in the fast model "lisa" file, nor does it explain
exactly what the difference is between them.
Change-Id: I686b4d973fc3cfff8a3ec05f8c95ee2cb6ff6698
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67575
Reviewed-by: Jui-min Lee <fcrh@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This CL enables forwarding stream ID from amba_pv to gem5 world.
The stream ID information is originally stored in master_id of
pv::TransactionAtrribute, then it will be stored to m_id of
amba_pv::amba_pv_extension.
This CL brings the information to stream ID field of
Gem5SystemC::ControlExtension. Then the information can be set to stream
ID of the gem5 packet's request.
After bringing the information to gem5, we can identify the packet's
stream ID from gem5 side. One example usage is PL330. In PL330_DMAC, each
transaction is associated with a stream ID. If we can identitfy the
stream ID, we can, for example, set attribute to specific DMAC channel.
Change-Id: I943ce49fde57b0bcfc18b58c7566eec61cc676f4
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67591
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
In the previous version, the body of several macros was a statement
(do{...} while(0);) and not an expression. In the new version, all
macros are expressions. Expressions can be used everywhere a statement
is expected and in other locations as well.
For instance, expressions can be used with the comma operator. When
doing generic programming, the comma operator helps manipulating
parameter packs. With a statement-based implementation,
(gem5_assert(args > 0), ...) could not be written while perfectly
sound.
Also, (c1 ? a : c2 ? b : (gem5_assert(c3), c)) is a usefull
expression to assert completeness of cascaded conditions that cannot
be easily and efficiently achieved without an expression kind of
assertion.
Change-Id: Ia0efeb15e6deda6b90529a6f0e00ebe2e9b5d2a0
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67336
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
The reference can be bound to an invalid object (*nullptr) in
situations where no proper owner SimObject can be provided to the port
constructor. This rightfully triggers a UBSAN warning.
Also, these two classes do not make use of the owner reference member
themselves and expose it as a protected member reference to
subclasses. This desing has several drawbacks: requires the reference
to owner to travel the class hierarchy up and down, loosing its true
static type in the process ; non-private member variable should not be
part of the API of such fundamental classes, if only for
maintainability ; a reference bound from a nullable pointer is a lying
API as it hides the optional aspect of ownership.
Note that the reference to invalid object can't be properly fixed until
the complete removal of the owner reference. This patch lays the path
toward that fix.
Change-Id: I8b42bc57d7826656726f7708492c43366f20633a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67551
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
safe_cast now supports the exact same types as dynamic_cast would. In
particular, it now supports l-value references and rejects r-value
references.
The non-debug version has also been updated to make it build only in
the same cases as the debug version of safe_cast would.
Change-Id: I86692561c169b1ad063000c990a52ea80c6637ca
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67453
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The only difference between these types in python are the compatibility
strings which restrict what can connect to what. For ports which are
generally useful like interrupts or resets, they should have port types
with special names and even more restrictive compatibility. For other
ports which are one off signals between components, that would be
overkill, and these helpers will let you make a signal port which is
only restricted to ports which carry the same type of data.
The helpers are intended to look similar to their C++ counterpart
templates, and are functions which take a type signature as a string
as their argument, and return a class which is specialized to use that
type signature. The class itself can be stored, or used immediately.
foo = SignalSourcePort('bool')('A port for the foo signal')
Change-Id: If6359b2c69f34ff775cd9aa01272ac487db08bf7
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67511
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
The asan(enable with --with-asan) sanitizer interpret calls to dlopen().
That replaces the RUNPATH of an executable with RUNPATH of libasan.so
after libasan.so is loaded by loader. Then it may cause some shared
libraries missing, i.e. the error messages is like
"cannot open shared object file: No such file or directory" since the
RUNPATH is no longer correct. Force the libasan to static linking
can avoid this issue since libasan.a does not have a RUNPATH, thus
the replacement will never happen.
Change-Id: I8e5ff4d1fbe4644a258054be6e9f6d4db9062e56
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67298
Reviewed-by: Earl Ou <shunhsingou@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Sanitizers can enlarge binary size drammatically, north of 2GB. This
can prevent successful linkage due to symbol relocation outside from
the 2GB region allocated by the small x86_64 code model that is
enabled by default (32-bit relative offset limitation). Switching to
the medium model in x86_64 enables 64-bit relative offset for large
objects (>64KB by default) while sticking to 32-bit relative
addressing for code and smaller objects. Note this comes at a
potential performance cost so it should not be enabled in all cases.
This should still be a very happy medium for non-perf-critical
sanitized builds.
Jira issue: https://gem5.atlassian.net/browse/GEM5-1313
Change-Id: I9aceacfcda99cc29c8fb24b7c69aaab019ce97fd
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67451
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
As of Linux 5.11, the MC146818 code was changed to avoid reading garbage
data that may occur if the is a read while the registers are being
updated:
github.com/torvalds/linux/commit/05a0302c35481e9b47fb90ba40922b0a4cae40d8
Previously toggling this bit was fine as Linux would check twice. It now
checks before and after reading time information, causing it to retry
infinitely until eventually Linux bootup fails due to watchdog timeout.
This changeset always sets update in progress to false. Since this is a
simulation, the updates probably will not be occurring at the same time
a read is occurring.
Change-Id: If0f440de9f9a6bc5a773fc935d1d5af5b98a9a4b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66731
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
The ISA parser now emits the code required to access matrix
registers. In the case where a register is both a source and a
destination, the ISA parser generates appropriate code to make sure
that the contents of the source is copied to the destination. This is
required for the O3 CPU which treats these as two different physical
registers, and hence data is lost if not explicitly preserved.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I8796bd1ea55b5edf5fb8ab92ef1a6060ccc58fa1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64338
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
We add the SME access checks and trapping, which roughly mirrors that
used by SVE.
SME adds a new mode called streaming mode. When a core is in streaming
mode the behaviour of the SVE instructions changes such that they
check the SME traps and enables as opposed to the SVE ones. We
therefore update the existing SVE trap/access checking code to check
the SME equivalents when a core is in streaming mode. Else, the
original behaviour is preserved.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I7eba70da9d41d2899b753fababbd6074ed732501
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64337
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We add the following registers which are added by SME:
* ID_AA64SMFR0_EL1
* SVCR
* SMIDR_EL1
* SMPRI_EL1
* SMPRIMAP_EL2
* SMCR_EL3
* SMCR_EL2
* SMCR_EL12
* SMCR_EL1
* TPIDR2_EL0
* MPAMSM_EL1
In addition we extend some of the existing registers with SME support
(SCR_EL3, CPACR_EL1, CPTR_EL2, CPTR_EL3, etc). These regisers are
responsible for enabling SME itself, or for configuring the trapping
behaviour for the differernt ELs.
In addition we implement some dummy registers as they are officially
required by SME, but gem5 itself doesn't actually support the features
yet (FGT, HCX).
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I18ba65fb9ac2b7a4b4f361998564fb5d472d1789
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64335
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
We add support for the matrix registers to the Arm architecture. This
will be used to implement support for Arm's Scalable Matrix Extension
(SME) in subsequent commits.
We add an implementation of a matrix register for the Arm
architecture. These are akin to 2D vector registers in the sense that
they can be dynamically viewed as a variety of element sizes. As
widening the element size would reduce the matrix size by a factor of
element size, we instead layer multiple tiles of wider elements onto
the underlying matrix storage in order to retain square matrices.
We separate the storage of the matrix from the different views one can
have. The potential views are:
* Tiles: View the matrix as one or more tiles using a specified
element size. As the element size increases the number of indexable
tiles increases. When using the smallest granularity element size
(bytes) there is a single tile. As an example, using 32-bit elements
yields 4 tiles. Tiles are interleaved onto the underlaying matrix
modulo element size. A tile supports 2D indexing ([][]), with the
first index specifying the row index, and the second the column
(element index within the row).
* A Horizontal/Vertical slice (row or a column) of a tile: Take the
aforementioned tile, and extract a specified row or column slice
from it. A slice supports standard []-based indexing. A tile slice
must use the same underlying element type as is used for the tile.
* A Horizontal/Vertical slice (row or column) of the underlying matrix
storage: Treat the matrix register as an array of vectors (rows or
columns, rows preferred due to them being indepependent of the
element size being used).
On simulator start-up the matrix registers are initialised to a
maximum size. At run-time the used size can by dynamically
adjusted. However, please note that as the matrix register class
doesn't know if a smaller size is being used, the class itself doesn't
do any bounds checking itself. This is left to the user.
Jira Issue: https://gem5.atlassian.net/browse/GEM5-1289
Change-Id: I6a6a05154846e4802e9822bbbac00ab2c39538ed
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64334
Reviewed-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Maintainer: Giacomo Travaglini <giacomo.travaglini@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We now explicitly check in both the cache and the MSHRs if writes are
masked or not before promoting to a whole-line write. Failure to do
this previously was resulting in data loss when dirty data was present
in lower level caches and a coincidentally aligned and
cache-line-sized masked write occured.
Change-Id: I9434590d8b22e4d993167d789eb9d15a2e866bf1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/64340
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
