The cache does indeed invoke a function in the LSQ later in time, once it is unblocked. The cache is blocked due to some other module in turn being blocked, right? It is not necessarily just a matter of waiting a specific time. Once the cache is unblocked it calls sendRetry on its port, which in turn ends up as a recvRetry call on the connected module (in this case the LSQ). Effectively the event that unblocks the cache eventually leads to the LSQ getting called (either directly or through scheduling another event that does it), and that in turn should result in the sender (here the LSQ) calling sendTiming. The time between these events is arbitrary and could be 0, 10s, 100s or 1000s of cycles.
Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nilay Sent: 15 November 2011 13:37 To: gem5 Developer List Subject: Re: [gem5-dev] Need for recvRetry() In an event based simulation, I would expect the cache module to insert an event into the event queue which will make the simulator invoke some particular function of the LSQ later in time. In this case, the cache itself is invoking some function, which in my understanding is not really event based simulation. -- Nilay On Tue, November 15, 2011 2:43 am, Andreas Hansson wrote: > The overall idea with event-based simulation is to _not_ evaluate > conditions on a cycle to cycle basis, and only schedule something once > there is useful work to do (although not every component in gem5 adopts > this approach). Thus, if you connect something other than a CPU to a cache > (say a GPU or some other accelerator) then you should _not_ rely on that > module polling a status bit or flag. > > Sounds reasonable? > > Andreas > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Steve Reinhardt > Sent: 14 November 2011 19:36 > To: gem5 Developer List > Subject: Re: [gem5-dev] Need for recvRetry() > > I believe that should work. The ability to send a packet from within > recvRetry() is just intended as a convenience; if you don't return one, > but > call sendTiming() later, it should have the same effect, especially if > it's > something like an L1 cache where you don't have to worry about some other > requester stealing the resource that's now available before you can get > it. > > Steve > > On Mon, Nov 14, 2011 at 11:06 AM, Nilay Vaish <[email protected]> wrote: > >> Well, the lsq, in every cycle, executes a function that checks whether >> or >> not the cache is blocked. I would rather prefer that some variable is >> set >> in recvRetry(), which indicates that the cache is now available for >> servicing requests. Putting the code for sending packet in recvRetry() >> seems to be introducing more complexity than necessary. >> >> -- >> Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- 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. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
