> On Jan. 31, 2017, 4:10 p.m., Jason Lowe-Power wrote: > > I don't follow why you don't need to pay for the payload delay. Is that > > taken care of at some other point in the System-C model?
Simply paying for the payload delay in the transactor would be wrong. If we look at how it works in gem5, then the port is not responsible for paying for the header and payload delay. This is the responsibility of the receiving SimObject. The transactors are just different implementations of gem5 ports. Therefore, they should also not touch the header and payload delay and let the receiving module handle the delay. However, in this case, the receiver is a SystemC module that is not aware of the gem5 semantics, which makes it complicated. If the transactor would pay for the full payload delay, then this would mean that the transactor is an actual module that buffers all data and waits for the end of the packet before forwarding it to the SystemC world. However, the transactor should only translate between gem5 and TLM and not influence the timing. Let me explain a bit of the TLM protocol and how the transactors work: The TLM base protocol is a four phase protocol (BEGIN_REQ, END_REQ, BEGIN_RESP, END_RESP). When the slave port receives a packet from the gem5 world (recvTiningReq), it sends a BEGIN_REQ to the SyctemC world and blocks the port. Upon receiving an END_REQ from the SystemC world, the port is unblocked. When the port receives a BEGIN_RESP from the SystemC world it sends a response packet to the gem5 world (sendTimingResp) and acknowledges to the SystemC world by sending an END_RESP. The BEGIN_REQUEST needs to be send exactly when the gem5 packet header arrives at the transactor port. This is current time plus header delay. Then the receiver (a SystemC module) is responsible for modelling the time required for accepting all the data. This is simply done by sending the END_REQ after a certain time. Asuming that the request carries data, the time for transporting this data is modeled by the receiver. It simply delays the END_REQ for a certain amount of time. If we assume that the SystemC module that receives the request, can handle incoming data at lower or the same speed as the XBar, everything should work fine. If the XBar is limiting the speed of data transport, then yes, actually we should pay for the payload delay somewhere. However, I don't have a solution for this problem. Maybe someone has any suggestions? - Christian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3798/#review9355 ----------------------------------------------------------- On Jan. 30, 2017, 4:40 p.m., Christian Menard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3798/ > ----------------------------------------------------------- > > (Updated Jan. 30, 2017, 4:40 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11802:93cbf8202c63 > --------------------------- > misc: Clean up and complete the gem5<->SystemC-TLM bridge [9/6] > > 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 the header delay that the gem5 XBar annotates to packets. > > > Diffs > ----- > > util/tlm/sc_master_port.cc PRE-CREATION > util/tlm/sc_slave_port.cc PRE-CREATION > > Diff: http://reviews.gem5.org/r/3798/diff/ > > > Testing > ------- > > > Thanks, > > Christian Menard > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
