So we probably don't want to pass speculative store data to the RubyPort, but what about speculative load and store requests? I suspect we do want to send them to the RubyPort before the speculation is confirmed. That might require splitting stores to two separate transactions: the request and the actual data write. Also I suspect that the RubyPort will need to forward probes to the cpu models to allow the LSQ to maintain the proper consistency model. If those two things end up being true, then what is the benefit of putting the non-speculative store buffer in each protocol, versus just in the o3 cpu model?
I'm not yet ready to advocate that is the right solution. I just want us to think these issues thru before deciding to go down one path or the other. Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On > Behalf Of Nilay Vaish > Sent: Thursday, February 24, 2011 10:45 AM > To: M5 Developer List > Subject: Re: [m5-dev] Store Buffer > > On Thu, 24 Feb 2011, Arkaprava Basu wrote: > > > Fundamentally, I wish to handle only non-speculative memory state > within > > Ruby. Otherwise I think there might be risk of Ruby getting affected > by the > > CPU model's behavior/nuances. As you suggested, Rubyport may well be > the line > > dividing speculative and non-speculative state. > > I also agree that beyond RubyPort, all the stores should be > non-speculative. > > > > I haven't looked at the Store buffer code in libruby and do not know > how it > > interfaces with the protocols. So sorry, I don't have specific > answers to > > your questions. I think Derek is the best person to comment on this > as I > > believe he has used store buffer implementation for his prior > research. > > I think currently the store buffer is not being used at all. I looked > through GEMS code, and some of the protocols do declare a store buffer, > but no one makes use of it. In gem5, store buffers are not included > in the protocol files. In fact, current libruby code does nothing > useful > at all. > > > I do think though, that the highest level (closest to the processor) > cache > > controller (i.e. *-L1Cache.sm ) need to be made aware of the store > buffer > > (unless it is hacked to bypass SLICC) . > > > > Thanks > > Arka > > > > -- > Nilay > > > On 02/23/2011 11:29 PM, Beckmann, Brad wrote: > >> Sorry, I should have been more clear. It fundamentally comes down > to how > >> does the Ruby interface help support memory consistency, especially > >> considering more realistic buffering between the CPU and memory > system > >> (both speculative and non-speculative). I'm pretty certain that > Ruby and > >> the RubyPort interface will need be changed. I just want us to > fully > >> understand the issues before making any changes or removing certain > >> options. So are you advocating that the RubyPort interface be the > line > >> between speculative memory state and non-speculative memory state? > >> > >> As far as the current Ruby store buffer goes, how does it work with > the L1 > >> cache controller? For instance, if the L1 cache receives a > probe/forwarded > >> request to a block that exists in the non-speculative store buffer, > what is > >> the mechanism to retrieve the up-to-date data from the buffer entry? > Is > >> the mechanism protocol agnostic? > >> > >> Brad > >> > >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
