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>
In the payload event queue in Gem5ToTlmBridgeBase, the phase is checked
twice for BEGIN_RESP. This commit removes the second if clause since it
is unnecessary.
Duplicate if clause in line 234 & line 256
dd2689905f/src/systemc/tlm_bridge/gem5_to_tlm.cc (L234-L267)
please correct me if I am missing something important
This commit fixes a violation of the TLM2.0 protocol as well as a
bug regarding back-pressure:
- In the BEGIN_REQ phase, transaction objects are required to set
their response status to TLM_INCOMPLETE_RESPONSE. This was not
the case in the packet2payload function that converts gem5 packets
to TLM2.0 generic payloads.
- When the target applies back-pressure to the initiator, an assert
condition was triggered as soon as the response is retried. The
cause of this was an unintentional nullptr-access into a map.
If a request is initiated by systemc, passed through TlmToGem5 bridge
and Gem5ToTlm bridge, it wouldn't have the systemc extension about the
association. This feature is also used in TlmToGem5 bridge to detect if
the packet is allocated in the current instance in async interface. In
that case, we would lose the association in the Gem5ToTlm bridge async
interface. For not making wide change, we need an extra way to support
the association in Gem5ToTlm bridge async interface.
This change adds another map to record the association and clears when
the TLM transaction is completed.
Change-Id: I486441e813236ea2cabd1bd6cbb085b08d75ec8f
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66054
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Given a data path initiated from SystemC, routed by gem5, and handled
by SystemC finally.
SystemC -> gem5 -> SystemC
The target SystemC needs to get the original transaction object.
Otherwise, it would lose the extensions in the payload.
To fix the issue, we moves the SenderState class to public for reachibility.
After that, we refactor the logic converting between payload and packet
to make sure they can use the correct instance. Finally, we fix the
potential address change during routing.
Change-Id: Ic6d24e98454f564f7dd6b43ad8c011e1ea7ea433
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/63771
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Apply the gem5 namespace to the codebase.
Some anonymous namespaces could theoretically be removed,
but since this change's main goal was to keep conflicts
at a minimum, it was decided not to modify much the
general shape of the files.
A few missing comments of the form "// namespace X" that
occurred before the newly added "} // namespace gem5"
have been added for consistency.
std out should not be included in the gem5 namespace, so
they weren't.
ProtoMessage has not been included in the gem5 namespace,
since I'm not familiar with how proto works.
Regarding the SystemC files, although they belong to gem5,
they actually perform integration between gem5 and SystemC;
therefore, it deserved its own separate namespace.
Files that are automatically generated have been included
in the gem5 namespace.
The .isa files currently are limited to a single namespace.
This limitation should be later removed to make it easier
to accomodate a better API.
Regarding the files in util, gem5:: was prepended where
suitable. Notice that this patch was tested as much as
possible given that most of these were already not
previously compiling.
Change-Id: Ia53d404ec79c46edaa98f654e23bc3b0e179fe2d
Signed-off-by: Daniel R. Carvalho <odanrc@yahoo.com.br>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/46323
Maintainer: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Bobby R. Bruce <bbruce@ucdavis.edu>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Previously we only rely on timestamp to schedule all phase change events
of tlm transactions in Gem5ToTlmBridge. However, it is valid to have
END_REQ and BEGIN_RESP of a transaction to be scheduled at the same
timestamp and the gem5 scheduler will not necessary order them in a
correct way.
This unfortunately breaks the code as sending a response before
accepting a request doesn't make sense at all and will trigger an
assertion failure.
In this CL we slightly increase the priority of END_REQ event so we can
always process phase change events in a correct order.
Change-Id: Ic33a92162c8c53af3887c7b04090115a38f96866
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/44305
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In Gem5ToTlmBridge::pec, the function expects blockingRequest should be
set no matter the tlm peer returns TLM_UPDATE or TLM_ACCEPTED.
However, current implementation only sets blockingRequest when the tlm
peer returns TLM_ACCEPTED. We should also set blockingRequest when the
tlm peer returns TLM_UPDATE.
Change-Id: I87bba3201cd68d52ded93c9c200f4fa4a40bdf5b
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/39815
Reviewed-by: Earl Ou <shunhsingou@google.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We used to have a hard-coded packet2payload and payload2packet in the
tlm_bridge implementation. However, as the conversion is operated on
generic tlm payload, we're not able to handle information stored in any
user defined SystemC extensions.
In this CL, we add a pair of function to register extra conversion steps
between tlm payload and gem5 packet. This decouples the exact conversion
logic and enables SystemC users to register any necessary steps for
their extensions.
Change-Id: I70b3405395fed0f757f0fb7e19136f47d84ac115
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/37075
Reviewed-by: Gabe Black <gabe.black@gmail.com>
Maintainer: Gabe Black <gabe.black@gmail.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The create() method on Params structs usually instantiate SimObjects
using a constructor which takes the Params struct as a parameter
somehow. There has been a lot of needless variation in how that was
done, making it annoying to pass Params down to base classes. Some of
the different forms were:
const Params &
Params &
Params *
const Params *
Params const*
This change goes through and fixes up every constructor and every
create() method to use the const Params & form. We use a reference
because the Params struct should never be null. We use const because
neither the create method nor the consuming object should modify the
record of the parameters as they came in from the config. That would
make consuming them not idempotent, and make it impossible to tell what
the actual simulation configuration was since it would change from any
user visible form (config script, config.ini, dot pdf output).
Change-Id: I77453cba52fdcfd5f4eec92dfb0bddb5a9945f31
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/35938
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The original implementation doesn't set trans and phase correctly when
scheduling PayloadEvent, and causes unexpected behavior after the event started.
This change fixes the wrong event triggering by directly applying
tlm_utils::peq instead of creating another one.
Change-Id: I207567b57f4b49c3c4ebe117d624e5cc9915c12a
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23823
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
These objects expose a standard TLM initiator or target socket with
width 64, and a gem5 slave or master port. What goes in one type of
port comes out the other with the appropriate conversion applied.
Change-Id: I65e07f746d46d3db0197968b78fffc5ddaede9bf
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17232
Reviewed-by: Gabe Black <gabeblack@google.com>
Maintainer: Gabe Black <gabeblack@google.com>
