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 > > > > On Mon, 14 Nov 2011, Andreas Hansson wrote: > > Hi Nilay, >> >> The idea behind the recvRetry is that the module that is trying to send a >> packet (the LSQ/CPU in this case) should only retry once the receiving >> module (the cache in this case) is available. The alternative is to "poll" >> by repeatedly trying to send, but this creates unnecessary function calls >> thus reducing simulation performance. (You would also have to address the >> issue of deciding how often to poll etc.) >> >> Andreas >> >> >> >> -----Original Message----- >> From: [email protected] >> [mailto:gem5-dev-bounces@gem5.**org<[email protected]>] >> On Behalf Of Nilay Vaish >> Sent: 14 November 2011 18:26 >> To: [email protected] >> Subject: [gem5-dev] Need for recvRetry() >> >> Hi >> >> I am try to do something with LSQ in the O3 CPU. There is function called >> recvRetry(). As per the documentation in the source files and the source >> code itself, it seems that the cache informs the processor side that an >> earlier failed request can be retired now. Why do we need this function? >> Would it not be simple to let the processor retry the request on its own? >> >> -- >> Nilay >> ______________________________**_________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/**listinfo/gem5-dev<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<http://m5sim.org/mailman/listinfo/gem5-dev> >> >> ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > _______________________________________________ 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
