Turns out those two events are happening in different ticks. Here is a trace segment that was observed between the LSQunit and the cache (in the method LSQUnit<Impl>::completeDataAccess(..) actually):
[Op] [Address] [Data] [Core] [CurTick] R 0x27fa94 0x73 1 16263000 R 0x27fa90 0x13a 1 16297000 R 0x27fa94 0x73 1 16305000 R 0x27fa90 0x13c 1 16307000 W 0x27fa90 0x13c 1 16308000 W 0x27fa94 0x13d 1 16311001 R 0x27fa94 0x13d 1 16313000 W 0x27fa90 0x13e 1 16368000 R 0x27fa90 0x13e 1 16368001 What I mentioned regards the events with CurTick 16307000 and 16308000 (accesses to 0x27fa90 with data 0x13c). These two operations appear here with an inverse order than the one specified by program. Below is the trace segment monitored at the same execution but observed at the head of the ROB (in-order), where W, R and RF stand for, respectively, write, read and forwarded read operations. [Op] [Address] [Data] R 0x27fa88 0x1 R 0x27fa90 0x13a W 0x27fa90 0x13c RF 0x27fa90 0x13c R 0x27fa94 0x73 W 0x27fa94 0x13d RF 0x27fa94 0x13d R 0x27fa90 0x13c W 0x27fa90 0x13e RF 0x27fa90 0x13e R 0x27fa94 0x13d What's the explanation for this behavior? I'd appreciate if you could make it clear for me if I missed an important notion. Or it could be a subtle bug... I also faced this issue when I was trying to implement the TSO memory model. I was able to insert constraints between all other instructions except this case. I'm inclined to think that this happens when there is squashing of instructions. But I couldn't verify it yet. I really would appreciate your help to solve this and be able to continue my research. Thanks, -- Eberle A. Rambo. On Thu, Apr 7, 2011 at 12:06 PM, Eberle <[email protected]> wrote: > 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
