On 7/6/10 1: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.
One way would be to just use the atomic cpu to create a set of checkpoints
you then ran from with the O3 cpu, but that is a stop gap solution.

> 
> 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.
Without looking at the code I'm not exactly sure, but that would be my
suggestion. Look at the port for the icache and if it has an outstanding
memory request then don't return 0 for drain(). I'm not sure what you mean
by the event queue in this case, but the atomic cpu shouldn't have a queue
of requests in the port, or that shouldn't be the case.

Ali


-- 
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.


_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to