Update the Part 3 config file examples in learning gem5 to resolve a
warning with int_links. Some files were initializing self.int_links vector
to an empty list of SimObjects. This causes a warning.
The fix resolves this by initializing self.int_links to a pre-declared
int_links variable.
Change-Id: Iaa38a4db9cc42a949879d571d1372f0b0a456f11
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/60829
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Matt Sinclair <mattdsinclair@gmail.com>
Maintainer: Jason Lowe-Power <power.jg@gmail.com>
Reviewed-by: Jason Lowe-Power <power.jg@gmail.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>
