Let me rephrase my last question: Is there any way that a comparison could be performed between the checkpoint output by inorder with that output by a simple CPU? Say, if the number of committed instructions in both are the same when the checkpoints are dumped, should I expect that the register and memory state for both CPU's should be identical?
In any case, what kind of testing strategy should be put in place to test the correctness of checkpointing apart from just taking checkpoints for programs/benchmarks, resuming from those checkpoints, running the programs till completion, and finally verifying the correctness of the outputs? -Soumyaroop On Sat, Feb 6, 2010 at 12:15 AM, soumyaroop roy <[email protected]> wrote: > On Thu, Feb 4, 2010 at 3:22 PM, Korey Sewell <[email protected]> wrote: >> >>> >>> 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?) >> >> This sounds good. There is already a "checkSignals" type function in the >> pipeline stage definition that you may be able to play off of. Maybe >> defining the drainPending flag in the CPU and then in the first stage's >> checkSignal function it can check for that drainPending flag and block the >> stage from processing if that's set. > > The checkSignalsAndUpdate() routine seems to be taking care of > squashes for each thread. FirstStage::processStage() proceeds to fetch > instructions after that. So, why not just insert the check on > drainPending between the two tasks? Let me know if my understanding is > incorrect. > >> >>> 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 >> >> Hmmm.... What we are basically trying to accomplish here is to signal >> "drained" when all instructions are out the pipeline. Checking the >> interstage communication structs can get tricky since they rotate every >> cycle. Why not just check the CPU's global instruction list of active insts? >> You could potentially check that list every time an instruction is retired >> from the CPU (cpu->instDone()???) and then once the list for all threads is >> empty, the pipeline is officially drained. > > Yes, this is pretty simple. Since instDone() only schedules > instructions to be removed from the global instruction list of active > instructions, I added this logic in cleanUpRemovedInsts(). > > I'll run some tests and update on the status. Btw, would it be legal > to compare the checkpoint outputs for one processor with that of > another one if the checkpoint are being taken at the same instruction > count (doesn't seem so!)? > > > -Soumyaroop > >> >> >> >> >> -- >> - Korey >> >> _______________________________________________ >> 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 > -- 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
