Thanks for the overview, Ali. It helped a lot. Draining is definitely the trickier thing.
This is my understanding of the flow in O3: 1. When drain() is called, it sets the "drainPending" flag to TRUE following which the fetch stage does not fetch any instructions. 2. Subsequently, when all the instructions in the pipeline are processed (i.e. the ROB is empty and IEW does not have stores to writeback), the commit stage calls signalDrained(), which sets the state of the cpu to SimObject::Drained and processes the drainEvent. Korey, I think for inorder we could follow the same technique: 1. The first stage of the pipeline should not process the stage when a drainPending flag is set (or should this be associated specifically with the fetch logic?) 2. The last stage of the pipeline should check if there are any entries in the interstage communication structure and call a signalDrained() routine no entries exist. Again should this be done by the graduation logic Comments? regards, Soumyaroop On Tue, Feb 2, 2010 at 3:16 PM, Ali Saidi <[email protected]> wrote: > You need to implement the following functions for the CPU. Taking a > look at the simple timing CPU should be an easier way to grasp what > must be done. Before the system can take a checkpoint, all the > requests must be drained from it. drain() is called on each simobject > which needs to respond if it has an outstanding request. If it does > then it needs to stop issuing requests and wait for the current > request to complete, calling the drain Event's process() method when > this occurs. resume() is the opposite of drain() which means the > system can continue issuing requests and acting as normal. serialize() > needs to save all of the state the CPU needs to put itself in the same > state as it was executing and unserialize() restores that saved state. > Looking at other implementations of save()/restore() is the easiest > way to do this. Finally, if you want to be able to switch to/from the > inorder cpu switchOut() and takeOverFrom() need to be implemented. > > > Hope that helps, > Ali > > > On Feb 2, 2010, at 8:40 PM, Korey Sewell wrote: > >> Looks like we might need a "Checkpointing - Internals" page on the >> wiki that summarizes this. >> >> I'm a little in the dark on what needs to be done myself... I assume >> the main components for checkpointing would be serialize and >> unserialize, but I guess traversing the function trace to/from those >> functions would reveal more. Without any further documentation, I'd >> probably try to GDB breakpoint in those functions and then figure >> things out from there. >> >> Anyone with some thoughts and developmental "starter" advice here? >> >> >> On Tue, Feb 2, 2010 at 2:20 PM, soumyaroop roy <[email protected]> >> wrote: >> Hello there, >> >> Could someone give me a quick overview on how to implement >> checkpointing for inorder? I am not able to find any documentation for >> it. So, I was trying to follow O3. But which methods - serialize(), >> unserialize()? And what about cpu switching? >> >> regards, >> Soumyaroop >> >> -- >> Soumyaroop Roy >> Ph.D. Candidate >> Department of Computer Science and Engineering >> University of South Florida, Tampa >> http://www.csee.usf.edu/~sroy >> _______________________________________________ >> 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 > -- Soumyaroop Roy Ph.D. Candidate Department of Computer Science and Engineering University of South Florida, Tampa http://www.csee.usf.edu/~sroy _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
