sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/10]

Browse source 
The current TLM bridge only provides a Slave Port that allows the gem5
world to send request to the SystemC world. This patch series refractors
and cleans up the existing code, and adds a Master Port that allows the
SystemC world to send requests to the gem5 world.

This patch:
  * Pay for the header delay that the gem5 XBar annotates to packets.

Reviewed at http://reviews.gem5.org/r/3798/

Signed-off-by: Jason Lowe-Power <jason@lowepower.com>
This commit is contained in:
Christian Menard 2017-02-09 19:15:48 -05:00
parent 0c4a69bcbf
commit 78e4967b6a
2 changed files with 35 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
util/tlm/sc_master_port.cc
View file

@ -329,9 +329,15 @@ SCMasterPort::recvTimingResp(PacketPtr pkt)
sc_assert(pkt->isResponse());
// pay for annotaded transport delays
auto delay =
sc_core::sc_time::from_value(pkt->payloadDelay + pkt->headerDelay);
/*
* Pay for annotated transport delays.
*
* See recvTimingReq in sc_slave_port.cc for a detailed description.
*/
auto delay = sc_core::sc_time::from_value(pkt->payloadDelay);
// reset the delays
pkt->payloadDelay = 0;
pkt->headerDelay = 0;
auto tlmSenderState = dynamic_cast<TlmSenderState*>(pkt->popSenderState());
sc_assert(tlmSenderState != nullptr);

27
util/tlm/sc_slave_port.cc
View file

@ -214,9 +214,34 @@ SCSlavePort::recvTimingReq(PacketPtr packet)
Gem5Extension* extension = new Gem5Extension(packet);
trans->set_auto_extension(extension);
/*
* Pay for annotated transport delays.
*
* The header delay marks the point in time, when the packet first is seen
* by the transactor. This is the point int time, when the transactor needs
* to send the BEGIN_REQ to the SystemC world.
*
* NOTE: We drop the payload delay here. Normally, the receiver would be
* responsible for handling the payload delay. In this case, however,
* the receiver is a SystemC module and has no notion of the gem5
* transport protocol and we cannot simply forward the
* payload delay to the receiving module. Instead, we expect the
* receiving SystemC module to model the payload delay by deferring
* the END_REQ. This could lead to incorrect delays, if the XBar
* payload delay is longer than the time the receiver needs to accept
* the request (time between BEGIN_REQ and END_REQ).
*
* TODO: We could detect the case described above by remembering the
* payload delay and comparing it to the time between BEGIN_REQ and
* END_REQ. Then, a warning should be printed.
*/
auto delay = sc_core::sc_time::from_value(packet->payloadDelay);
// reset the delays
packet->payloadDelay = 0;
packet->headerDelay = 0;
/* Starting TLM non-blocking sequence (AT) Refer to IEEE1666-2011 SystemC
* Standard Page 507 for a visualisation of the procedure */
sc_core::sc_time delay = sc_core::SC_ZERO_TIME;
tlm::tlm_phase phase = tlm::BEGIN_REQ;
tlm::tlm_sync_enum status;
status = transactor->socket->nb_transport_fw(*trans, phase, delay);