I had a similar issue a while back I didn't all the way solve but I had some thoughts on that that may be relevant here.
To be short, waiting for the CPU to drain isnt exactly enough because of what you witnessed with the different timing mode intricacies that affect simulation. But what I hypothesize might work is that *After* you drain the CPU you directly wait for the memory system to drain. If I'm not mistaken, the various queues throughout the caches/memory system have drain functions that you can call. It might work that you walk the memory hierarchy and call drain once again after you call the CPU drain and then that would signify a case for a clean switch (and if not that functionality isn't there, it seems some type of code to walk through the memory hierarchy and ensure all the relevant queues are empty would be the right thing to do). On Tue, Jul 6, 2010 at 2:22 PM, Timothy M Jones <[email protected]>wrote: > Hi everyone, > > For a while now I've been trying to implement SMARTS-like simulation within > M5. I'm almost there now but am stuck on one particular part. > > For SMARTS simulation we repeatedly switch CPUs between Atomic (for > fast-forwarding and functional warming), then O3 (for measurements) and back > again. When switching, I change the memory mode to suit the CPU I'm next > using. > > This works fine except for a corner case. If O3 gets told to drain whilst > waiting for an instruction cache access, it may finish draining and be > switched out before the request is returned. Then Atomic is switched in and > gets a timing callback, so fails. > > I've tried various schemes to address this (apart from simply ignoring the > timing callback in Atomic, since it seems like this shouldn't be the place > to sort this out - after all, it's not Atomic's fault it's getting a timing > callback but a problem with something that happened beforehand). However, I > can't find a solution to fix this easily. Could someone help me out and > point me in the best direction to go? > > I've tried preventing O3 from draining if fetch is waiting on an > instruction cache access, but that's not always obvious to spot since the > request can be squashed leaving no trace of it. > > I've tried preventing the port from signaling that it's drained until its > event queue is empty. However, this has the knock-on effect that it is > sometimes not empty when switching from Atomic to O3. Since Atomic doesn't > have a drain function, it simulates forever. > > Are either of these solutions the best way to solve this problem and if so, > which is the path I should continue to pursue? Or, is there a third option > that I haven't thought about? > > Cheers > Tim > > -- > Timothy M. Jones > http://homepages.inf.ed.ac.uk/tjones1 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > _______________________________________________ > 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
