Dear all, I updated some of the patches (mostly spell fixes) and add a fee new patches to the series [1-4]. Most notably, [1] ensures correct handling of gem5 packets when two gem5 components communicate with each other over a SystemC interconnect. [2] is a small bugfix and [4] a small extension.
[3] Implements handling of a packet's header delay. Note that the transactors only pay for the header delay and ignore the payload delay. Since the header delay marks the point in time when packets are first seen by the transactor, this is exactly the point in time when the TLM BEGIN_REQ or BEGIN_RESP should be sent. [1] http://reviews.gem5.org/r/3796/ [2] http://reviews.gem5.org/r/3797/ [3] http://reviews.gem5.org/r/3798/ [4] http://reviews.gem5.org/r/3799/ Cheers, Christian On Wednesday, 11 January 2017 13:45:46 CET Christian Menard wrote: > Hi Andreas, > > thanks for the explanation! > > > Does that make sense? > > Yes, it does. I already pay for the packet delay on the response path in the > Master Port. However, so far the Slave Port ignores the packet delays. > Since both Ports should do the same, I was looking for the best way of > solving this. I will make a small change then and pay for the packet delays > in the Slave Port. > > Cheers, > Christian > > On Wednesday, 11 January 2017 08:49:04 CET Andreas Hansson wrote: > > Hi Christian, > > > > Great work! Thanks for getting this in shape. > > > > Regarding your question on delays, the packet.hh header has a fairly > > elaborate description (and yes, I am to blame). The delays are set and > > incremented by the CoherentXBar and Cache for cases where the request > > packets must make immediate progress due to the coherency protocol > > implementation in gem5. Normally the delays are then actually added as > > part of the response path. See for example the CoherentXBar and > > recvTimingResp. > > > > If a packet reaches the TLM bridge and these fields are non-zero, the best > > thing to do would be to pay for it then and there, delay the packet, and > > zero the fields. That way we 1) put the delays closer to where they really > > should occur, and 2) avoid having to remember what packet should have what > > delay fields. > > > > Does that make sense? > > > > Andreas > > > > On 09/01/2017, 13:58, "Christian Menard" <christian.men...@tu-dresden.de> > > > > wrote: > > >Dear all, > > > > > >I worked on series of patches [1-6] that implement a complete gem5 <-> > > >SystemC-TLM bridge. This is based on the previous work in util/tlm by > > >Matthias > > >Jung. Please see the README in the last patch [6] for more details. > > > > > >I would like to ask you to review the patches and to push them to > > >mainline > > >soon if there are no major issues found. > > > > > >I also have a small question that I would like to resolve before the > > >final > > >submission. When translating between gem5 Packets and TLM Transactions, I > > >wonder how to handle the delays that are annotated to gem5 Packets > > >(headerDelay, payloadDelay). What exactly are these delays used for and > > >how > > >should a Sender/Receiver handle these delays? > > > > > >The patch series depends on some other small patches. There are two > > >patches > > >from Matthias Jung [7,8], an old patch from me that gives the > > >ExternalMaster a > > >MasterID [9], and a new patch that does a small change in util/systemc > > >[10]. > > > > > >During my work on the bridge, I noticed a problem with the > > >CxxConfigManager. > > >Please see my post on the mailing list [11] and the corresponding patch > > >[12]. > > > > > >Thanks! > > > > > >Kind regards, > > >Christian > > > > > >[1] http://reviews.gem5.org/r/3527/ > > >[2] http://reviews.gem5.org/r/3528/ > > >[3] http://reviews.gem5.org/r/3686/ > > >[4] http://reviews.gem5.org/r/3695/ > > >[5] http://reviews.gem5.org/r/3775/ > > >[6] http://reviews.gem5.org/r/3777/ > > > > > >[7] http://reviews.gem5.org/r/3478/ > > >[8] http://reviews.gem5.org/r/3479/ > > >[9] http://reviews.gem5.org/r/3480/ > > >[10] http://reviews.gem5.org/r/3774/ > > > > > >[11] http://www.mail-archive.com/gem5-dev@gem5.org/msg21318.html > > >[12] http://reviews.gem5.org/r/3778/ > > > > > >-- > > >Dipl.-Ing. Christian Menard > > >Research Assistant > > > > > >TU Dresden > > >Faculty of Computer Science > > >Chair for Compiler Construction > > >01062 Dresden > > > > > >Phone: +49 351 463-42441 > > >e-Mail: christian.men...@tu-dresden.de > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > > recipient, please notify the sender immediately and do not disclose the > > contents to any other person, use it for any purpose, or store or copy the > > information in any medium. Thank you. -- Dipl.-Ing. Christian Menard Research Assistant TU Dresden Faculty of Computer Science Chair for Compiler Construction 01062 Dresden Phone: +49 351 463-42441 e-Mail: christian.men...@tu-dresden.de _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
