I understand what you are saying and I am checking when there is a forwarding, so it's definitely not the case. I will turn on the trace flags in cache and see what happens there.
I am wondering if it's possible that those two operations are receiving the acknowledge/data from cache at the same cycle in LSQunit. Then I'd be capturing the events in the correct cycle but possibly in a incorrect order in the same cycle. What I mean is that in the same cycle, the method LSQUnit<Impl>::completeDataAccess(..) is called for the Load operation before it's called for the aforementioned Store operation. That could be the case. Is it possible? Thanks, -- Eberle A. Rambo. Mastering in Computer Science System Design Automation Lab (LAPS) and Interdepartmental Core of Microelectronics (NIME) Department of Informatics and Statistics (INE) Federal University of Santa Catarina (UFSC) On Thu, Apr 7, 2011 at 10:59 AM, Korey Sewell <[email protected]> wrote: > Actually, disregard the scenario I placed below. > > I think my original point about LSQ forwarding and Ali's extension of > that point make sense here. > > On Thu, Apr 7, 2011 at 9:55 AM, Korey Sewell <[email protected]> wrote: > > Have you turned on the trace flags in the Cache? > > > > Try m5 --trace-help for a listing of flags. > > > > If you are talking about things that are happening in the memory > > system, then you may want to observe how things are being handled > > w/the MSHRS. > > > > Particularly, what if you have store to A misses in the cache, but > > then you have a load from A before store has completed...what do you > > expect in that scenario? Can you observe (or not observe) that using > > trace flags? > > > > > > On Thu, Apr 7, 2011 at 9:50 AM, Eberle <[email protected]> wrote: > >> I've observed that with other loads closer to the store. But this one is > not > >> the case. > >> > >> > >> -- > >> Eberle A. Rambo. > >> Mastering in Computer Science > >> System Design Automation Lab (LAPS) and > >> Interdepartmental Core of Microelectronics (NIME) > >> Department of Informatics and Statistics (INE) > >> Federal University of Santa Catarina (UFSC) > >> > >> > >> On Thu, Apr 7, 2011 at 10:43 AM, Korey Sewell <[email protected]> > wrote: > >> > >>> The O3 model does have load-store forwarding, so yes, if you have a > >>> store to A in the LSQ and another load comes to that same address A > >>> while the store is still in the LSQ, then the load can save time and > >>> just pull the data from the LSQ instead of going out to memory. > >>> > >>> I'm not sure if this is what you are observing or not. > >>> > >>> On Thu, Apr 7, 2011 at 9:37 AM, Eberle <[email protected]> wrote: > >>> > Hi there, > >>> > > >>> > I've been facing a situation that I suppose it shouldn't happen. > >>> > Using the O3 model and SPARC ISA, in the middle of the execution > there > >>> are > >>> > some memory operations: Store to address A followed by other accesses > to > >>> > other addresses and then a Load to address A. > >>> > What happens is that this Load is being somehow flagged as completed > >>> before > >>> > the Store, but reading his data though. > >>> > I've checked in the Memory Dependency Unit and some other related > units > >>> but > >>> > there was nothing I could do there that would change that behavior. > And I > >>> > know that when something like that is detected in the LSQ, it returns > a > >>> > fault, squashes, etc. > >>> > > >>> > As far as I know, the O3 model implements the Alpha Memory Model, and > the > >>> > reordering between memory operations to the same address is not > allowed > >>> > (except in some aggressive implementations, which I think it's not > the > >>> > case). > >>> > Is this normal and I'm missing something? Or it really shouldn't > happen? > >>> > > >>> > > >>> > Thanks in advance, > >>> > > >>> > -- > >>> > Eberle A. Rambo. > >>> > System Design Automation Lab (LAPS) and > >>> > Interdepartmental Core of Microelectronics (NIME) > >>> > Department of Informatics and Statistics (INE) > >>> > Federal University of Santa Catarina (UFSC) > >>> > _______________________________________________ > >>> > m5-dev mailing list > >>> > [email protected] > >>> > http://m5sim.org/mailman/listinfo/m5-dev > >>> > > >>> > >>> > >>> > >>> -- > >>> - Korey > >>> _______________________________________________ > >>> m5-dev mailing list > >>> [email protected] > >>> http://m5sim.org/mailman/listinfo/m5-dev > >>> > >> _______________________________________________ > >> m5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > > > > > -- > > - Korey > > > > > > -- > - Korey > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
