> 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? > > Christian Menard wrote: > 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?
Thanks for the explanation. I think I understand now. I think this is a perfectly fine solution, but it would be helpful if you included a little more detail in your comment. Maybe something like "We throw away the payload delay and expect the System-C object to be responsible for modeling this delay. This can lead to incorrect delays if the X-Bar's payload delay is longer than than the System-C module's delay between BEGIN_REQ and END_REQ". Feel free to modify this to make it more clear, of course. Another option, if you feel like implementing it (and don't feel any pressure to do this), is to save the payload delay and then check to see if it matches the delay between BEGIN_REQ and END_REQ. If it doesn't match (or at least if it is higher), then you could issue a "warn(...)". I think it's important to document this as one of the intricacies of the gem5-System-C bindings, but other than adding something to the comment, I'm happy with this patch. - Jason ----------------------------------------------------------- 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
