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 _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
