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
