This commit adds an error message to src/sim/kernel_workload.cc to tell
the user when the end address of the kernel is greater than the size of
memory. The error message also specifies the minimum memory size needed
to fit the kernel.
Change-Id: I7d8f50889ed8172f64b84f98301a35e5f2f352d3
Implementing generic reset method for MMU allows each ISA implementing
their own reset methods. The default reset MMU method is flush all TLB
entries. For example, The RISC-V needs to do PMP reset when received the
reset signal, but the TLBs don't require to be flushed.
Change-Id: I158261570fb6e5216ec105fbdc53460f83f88d15
This makes it easier to debug unexpected semihosting outputs (in my case
a wrong buffer argument was being passed).
Change-Id: I342610a92fb8efe121d030f7b9ea3307efc4fec3
This is on by default in gem5 (see src/cpu/kvm/BaseKvmCPU.py), however
the perf counters only measure host instruction counters and GPUFS is
not concerned about accuracy of KVM CPU stats. There are also a larger
set of users who have access to KVM, but do not have the paranoid level
low enough to attach performance counters.
Therefore, make the performance counters OFF by default. They can still
be enabled, but this will allow for a larger set of users to follow the
upcoming GPUFS documentation without needing to read through a
troubleshooting section after seeing a gem5 error about the KVM paranoid
level.
Change-Id: I6b465559edf3ce17e7117ada049c60bd39aecd83
These registers were only handled in AArch64 mode but are also
accessible as a c14 registers for AArch32.
Change-Id: I62fe54427e96265df0589308afa1b5d665dbf210
In AArch32 mode it is possible to read a 64-bit counter using mrrc.
Instead of truncating in the PMU code, just allow the instruction
implementation to truncate to 32 bits if accessed using mrc.
Change-Id: I77620f6d1852a7d9e79c1ecee50f4297b4103b1c
This PR has four components:
- Implement a helper method for SDWAB similar to SDWA helpers. SDWAB is
used for VOPC instructions only (vector compares).
- Update two instructions commonly using SDWAB to use helper
(v_cmp_ne_u16 and v_cmp_eq_u16).
- Add panics to *all* VOP1 and VOP2 instructions which do not implement
SDWA or DPP if they use an SDWA or DPP register.
- Add panics to *all* VOPC instructions which do not implement SDWAB or
DPP if they are an SDWA or DPP register.
Only VOP1, VOP2, and VOPC may use SDWA, SDWAB, or DPP. The panics should
therefore cover all instructions which have missing implementations for
these modes. The intent is to exit gem5 instead of continuing simulation
will data that is likely incorrect. Continuing simulation only makes
debugging gem5 more difficult.
If SDWAB or DPP are used on a VOPC instruction and those are not
implemented, it is highly likely to be a problem for the application.
Rather than continue to execute and cause undefined behavior, exit the
simulation with a panic showing the line of the instruction causing the
issue.
Change-Id: Ib3f94df7445d068b26907470c1f733be16cd2fc2
Add a panic if SDWA or DPP is used for an instruction which does not
implement support for it. If an application uses SDWA or DPP it likely
does not operate in the same way as the base instruction and therefore
gem5 should panic rather than continue. It is likely data is incorrect
which will make it more difficult to debug an application.
Change-Id: I68ac448b0d62941761ef4efa0169f95796270f48
This shows an example of how to use the previous commit which adds an
SDWAB helper. The execute() method of both are the same with the
exception of the lambda function passed to the helper method.
Change-Id: I5ffe361440b4020b9f7669c0ed946aa6b3bbec25
Implement a SDWAB helper which accepts a dynamic instruction and a
lambda function defining a comparison function taking two values and
returning a comparison result of 0 or 1 for false or true.
Current instructions which implement SDWA do so on a per-instruction
basis which adds a lot of redundant code. This allows for generic SDWAB
implementations for VOPC instructions.
All modifiers are implemented assuming that SDWBA VOPC instruction
comparison types may be U32, I32, F32, U16, I16, F16 (which exist) but
is extendible to I8, U8, or F8.
Change-Id: Idab58a327c29dd19a1a5457237f3799a04f2031b
Some instructions are clamping floating point outputs unconditionally,
leading to incorrect results. This commit finds instructions with this
issue and checks the clamp bit before applying clamp.
Change-Id: Ibc6de3813d81fd4f9d2c98dd497d19dd34cf6bde
This tests attempts to infer which tests to download per job in the
matrix thereby significantly reducing the download times for each job.
Change-Id: I61b4f4b6410aa86de7437caf213499d805861e0c
This PR improves the vector register groups overlap check in
widening/narrowing
instructions.
- Fix wrong illegal overlap condition between VS2 and VD vector register
groups.
- Also check VS1 vector register group for overlap with VD in
vector-vector
instructions.
- Parametrize widening/narrowing factors in overlap check function to
potentially
handle more cases.
Fixes issue #442.
This commit moves the requires() call that checks the cache coherence
protocol above the imports. This change was made for the chi private l1,
ruby mesi three level, mesi two level, and mi example cache hierarchies.
This ensures that a clear error message about having the wrong coherence
protocol is printed, rather than a less useful message.
Change-Id: I3bac1ffcb1f8a9d94e486237f880cf248e442ba8
This fixes the remaining implicit int/float conversions and enables the
float conversion warnings for clang when building the Arm instruction
execution logic. This depends on the previous fixes.
Change-Id: I51aac94644a483175842c36da2d49d308aaceb49
This changes `long`s in src/mem/physical.cc, which are 32 bits or more,
to `uint64_t`s, which are exactly 64 bits.
Change-Id: I64e089a2ac087bcf58b9c3c918c59dc5ff75d010
TimingExpression enables runtime calculation of the commit latency in
MinorCPU. For this, machInst is obtained by getEMI() to match it with a
given instruction. At default, getEMI() always returns 0 and is
therefore overwritten to enable timing expressions for RISC-V. This was
already done for ARM (see src/arch/arm/insts/static_inst.hh).
Change-Id: I03d669b3439fd24e00cbf893f5db9951dfe56b1f
Signed-off-by: Robert Hauser <robert.hauser@uni-rostock.de>
Updated the bib information of the local RISC-V interrupts.
Change-Id: I666c3df4529e159bd1946ca1a9623e47f84d5d9e
Signed-off-by: Robert Hauser <robert.hauser@uni-rostock.de>
Currently, only the VS2 register group is checked for overlap with VD
when executing a widening/narrowing instruction. This commits extends
the check to VS1, when applicable (i.e. vector-vector operations).
Change-Id: I892b7717c01e25546fb41e05afbd08fc40c60c59
As of now, the widening/narrowing vector register groups overlap check
always assumes a SEW multiplication factor equal to 2 (for either VD or
VS2). This commits aims at making this check more generic.
Change-Id: I4311fc3624cd324ccfdf2a1920a19efc85357120
This commit fixes the overlap check between VS2 and VD register groups
in vector widening instructions. While the narrowing instructions check
is correct, the widening one has to differentiate between two cases
(Vs2 EEW = 2*SEW and Vs2 EEW = SEW). In the first case, overlap is
allowed, as the EEW is the same as Vd. In the second case, the overlap
legality check has to be adapted to use the Vs2 EMUL to calculate the
boundaries. The rule has been derived again from Section 5.2 of RISC-V
"V" Vector Extension specifications, version 1.0.
The patch also includes some small code refactoring, e.g. using
already defined vlmul and constants for vector operands.
Fixes issue #442.
Change-Id: Ic87095fb9079e6c8f53b9a0d79fbf531a85dc71d
Vector reduce float (widening and non-widening) and integer (widening)
instructions initialize the reduce loop operation with the first element
of the destination register (i.e. `Vd[0]`).
Since all reductions per spec seem to be `Vd[0] = Vs1[0] + Vs2[*]`
(where `+` is an arbitrary binary op and `*` indicates all active
elements) gem5 will calculate this incorrectly if `Vd[0]` and/or
`Vs1[0]` are non-neutral for the operation (the later case being because
it's not taken into account at all).
To solve this we just have to initialize the reduction loop to `Vs1[0]`
(the non-widening integer reduction already does this).
If the threacContext of CPU enters the suspend mode, raise the threadID
of threadContext cpu_idle_pins with the high signal to target. If the
threadContext of CPU enters the activate mode, lower the threadID of
thread cpu_idle_pins with low signal to target.
The gem5 crashed when user try to update register value from GDB because
PR[1] changes the index of CSR_XSTATUS to MISCREG_XSTATUS, which is out
of NUM_PHYS_MISCREGS.
The CSR_XSTATUS should use setRegWithMask to update it.
[1] : https://github.com/gem5/gem5/pull/1099
gem5 issue: https://github.com/gem5/gem5/issues/1299
Change-Id: Iefc0d1f5adfb98ecfda0e74907964b47d1864b6d
These two commits add agnostic capability for both tail/mask policies,
for vector memory and arithmetic instructions respectively. The common
policy for instructions is to act as undisturbed if one is (i.e. tail or
mask), or write all 1s if none.
For those instructions in which multiple micro instructions are
instantiated to write to the same register (`VlStride` and `VlIndex` for
memory, and `VectorGather`, `VectorSlideUp` and `VectorSlideDown` for
arithmetic), a (new) micro instruction named `VPinVdCpyVsMicroInst` has
been used to pin the destination register so that there's no need to
copy the partial results between them. This idea is similar to what's on
ARM's SVE code. This micro also implements the tail/mask policy for this
cases.
Finally, it's worth noting that while now using an agnostic policy for
both tail/mask should remove all dependencies with old destination
registers, there's an exception with `VectorSlideUp`. The
`vslideup_{vx,vi}` instructions need the elements in the offset to be
unchanged. The current implementation overrides the current vta/vma and
makes them act as undisturbed, since they require the old destination
register anyways. There's a minor issue with this though, as
`v{,f}slide1up` variants do not need this, but since they share the same
constructor, will act all the same.
Related issue #997.
1. Responder (downstream components):
When sending a BEGIN_REQ, the timing annotation marks the time when
a transaction is visible to the target (see [1] on page 465).
When writing the data, the downstream component calculates the
transfer time and would send END_REQ after this time (see [1] on
page 540). Therefore, not the payloadDelay, but the headerDelay
should be used, as already written as a comment in the source files.
When reading data, payloadDelay will be 0 anyway.
2. Requester (upstream component):
For data read, the begin of the transfer is marked by BEGIN_RESP
and the upstream component would delay END_RESP to model the
data transfer (see [1] on page 540). Therefore, BEGIN_RESP should be
delayed by the headerDelay, not the payloadDelay.
[1] "IEEE Standard for Standard SystemC® Language Reference Manual," in
IEEE Std 1666-2023 (Revision of IEEE Std 1666-2011), vol., no.,
pp.1-618, 8 Sept. 2023, doi: 10.1109/IEEESTD.2023.10246125.
Change-Id: I3b5e8ad6bc37cbb309b124efdc8764fca3728b7a
Signed-off-by: Robert Hauser <robert.hauser@uni-rostock.de>
Implement small translation table extension.
This feature relaxes the lower limit on the size of the translation
tables, by increasing the maximum permitted values of the T1SZ and T0SZ
field in: TCR_EL1, TCR_EL2, TCR_EL3,VTCR_EL2 and VSTCR_EL2
Change-Id: I4c2187815b2d7f14407edb38095c6bcc2004b62a
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This PR is introducing the concept of IPA space in gem5, which is
necessary after the implementation
of FEAT_SEL2. In fact we can now have Secure and Non-Secure intermediate
physical address spaces when the PE is
executing in Secure state.
We are currently using the LongDecriptor for both stage1
and stage2 translations. There are several cases where
the bitfield meaning changes depending on the translation
stage.
Change-Id: Ic33d9ef225a57fd79ce2b4bf47896aeb6bdd8d9c
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
