Updated the SLICC `Symbol` class to return an empty string when its
`desc` property is read.
The SLICC language does not require a symbol to have a `desc` for
protocol generation, but the generation of SLICC HTML documentation
expects a `desc` and will fail if it is not present.
Change-Id: I07cc0ab805520eb74f86c6ea8036abb7354b10a9
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60870
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
This commit adds `desc` descriptions to the new symbols introduced
with CHI DVM support. The generation of the SLICC HTML documentation
requires each symbol to have a description, so a build with
`SLICC_HTML=True` will fail without this change.
Change-Id: I06f3bdd33edd1ff6e4bec35b01a460b9359ed9f6
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60869
Maintainer: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This patch is revamping/simplifying the access permission logic in the
ArmMMU (ArmMMU::s1PermBits64) by matching more closely the Arm
architecture reference manual pseudocode.
It also fixes VHE access permission: previous version was not
considering the EL2&0 translation regime.
Now EL2&0 is handled correctly through the new hasUnprivRegime method
Change-Id: I2689738f36a35c35cc4f2ef8af68ee2a3eef65e8
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60969
Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: kokoro <noreply+kokoro@google.com>
By default backdoor access fall back to atomic if not
implemented in the ResponsePort. Given this is a common
behavior for most of the IPs, having them print all the
warning creates large number of warning in a big system.
Ideally we want to make this a debug level log, but this
can only be done through the debug trace mechanism.
Change-Id: I8a4074fc58b13c1881ad62897a89774c66880ccb
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60790
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
By design SimObject should initialize its state at init() stage.
However, the original intpin design will try to reset the sink side when
binding. This could cause unexpected issue as the other side does not
init() yet.
To align with the design, the call to upper()/lower() should be left to
the initiator in the init() function instead of constructor.
Change-Id: Iec8b228715d093381a33e747849119562bd634e1
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60751
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
For SimObject type param, we should avoid duplicated addChild
call if it already belongs to other parent.
In the original implementation, the following code:
```
class A(SimObject):
...
class B(SimObject):
a = Param.A(...)
class Top(RealView):
a = A()
b = B(a=a)
```
will generate incorrect warning:
```
warn: <orphan B>.a already has parent not resetting parent.
Note: a is not a parameter of B
warn: (Previously declared as <orphan Top>.a)
```
The code tries to add `a` as the child of `Top` as well as child of
`Top.b`, which is incorrect.
Change-Id: I8c55c5dd4cc0dd45c68169a2b08450ff053c07aa
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60789
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Base on https://graphviz.org/doc/info/shapes.html#record, record shape
has problems with edge between adjacent nodes on the same rank. This will
produce message "flat edge between adjacent nodes one of which has a record
shape" and dump a huge svg file in gem5's stdout. Also, the edge will
not be plotted in the output svg.
By looking at out dot_writer, we don't really use any record specific
label. As a result, we can simply apply box as the shape to achieve the
same output without the strange error message.
Change-Id: Ibbbcbfbc29edcd64bfeb7ae10adccfb54ea2613a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60749
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Yu-hsin Wang <yuhsingw@google.com>
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>
Previously b40b361bee added support for the Vega operand encoder. As
part of this, it made sure to check for the S_GETPC_B64 instruction,
which appears to be the only instruction in the Vega ISA that does not
use the source register. However, at the time the commit used magic
numbers without comment, which can be difficult for users to interpret.
To resolve this, this commit adds a comment to explain where the magic
numbers come from (Table 58 in the Vega ISA manual).
Change-Id: Ic5007b510e0175558d21ede8eb6db273113187b2
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60650
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Some of the Vega scalar instructions (S_SETPC_B64, S_RFE_B64,
S_CBRANCH_JOIN, and S_SET_GPR_IDX_IDX) do not use the SDST scalar
destination register. However, Vega's operand encoding function for the
SOP1 instruction type's class assumed all instructions used the
destination register, which results in an assert failure for these
instructions.
To resolve this, this commit updates the Vega SOP1 operand encoder to
ignore the destination register for these specific instructions.
Change-Id: I2f0d830f6264fc7f47c0694a2fd5da5d33d2ea0b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60649
Maintainer: Matt Sinclair <mattdsinclair@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Previously, the GPU SQC and TCP Ruby protocols always told the Sequencer
that the externalHit field was false. This impacts the statistics and
profiling, because the Sequencer uses this hit/miss information both for
profiling and the coalescer's statistics.
To resolve this, this commit updates the GPU SQC and TCP Ruby protocols
to pass the appropriate hit/miss information into the Sequencer's
readCallback and hitCallback functions.
Change-Id: Ib74af09b66fa8866eee72d3a9ab0e8a8f2196c03
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60652
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
There are some flags in gem5 Packet class to specifying the control
signals, like priv bit, secure bit, etc. For now we don't have the
corresponding way to bridge the information in gem5 and SystemC. The
control extension would be responsible for control signals.
Change-Id: I35ba8610210e0750917a78fa0adb321991968f6a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/59649
Tested-by: kokoro <noreply+kokoro@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Reviewed-by: Bobby Bruce <bbruce@ucdavis.edu>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
