> 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? > > Jason Lowe-Power wrote: > 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.
Yes, I agree, its very important to document this. I updated the patch and hope it is clearer now. I had the same idea about the warning, I will see if I manage to implement this. - Christian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3798/#review9355 ----------------------------------------------------------- On Feb. 1, 2017, 5:57 p.m., Christian Menard wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3798/ > ----------------------------------------------------------- > > (Updated Feb. 1, 2017, 5:57 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11802:31b809f6c634 > --------------------------- > 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 for 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
