Hi I'm still having trouble switching correctly between DetailedCPU and SimpleCPU for CMP simulation. I seem to be flushing the pipeline correctly in the DetailedCPU. I'm doing this by checking 4 different buffers/queues: the IQ, LSQ, DecodeQ, and storebuffer. once these are empty, I feel that it is safe to say the pipe is empty and also that all memory is updated for that particular CPU. the other CPUs will likewise do the same and once all CPUs have done this, the signalSwitched call in the Sampler can proceed to let the SimpleCPUs takeOverFrom the Detailed CPUs. Now the problem I'm seeing is that the ExecContexts don't really "completely" takeOverFrom the ExecContexts tied to the previous phase's CPUs. There is a structure called waitList in ExecContext, which seems to be only getting modified by the Tru64::* functions. However, this structure is not "copied" when a takeOverFrom occurs. An example, is when some context is put into a suspended state. Is this something that has not been completed yet? It's really hard to tell between what is correct, incorrect, or not yet implemented yet. Another thing I was wondering is if the CPU's should all be set up with defer_registration set to True. It seems like if I don't set this, then I end up with much more ExecContexts in the Process then the number of CPUs. Also, what I see is that if I'm currently executing Detailed mode and a thread is created, the Tru64::init_exec_context will actually try to use an ExecContext from one of the SimpleCPU's instead of the DetailedCPUs. anyways... i know i ask a lot of questions, but any help would be really appreciated. thanks jeff

Jeff wrote: > Hi > > I'm still having trouble switching correctly between DetailedCPU and SimpleCPU for CMP simulation. > > I seem to be flushing the pipeline correctly in the DetailedCPU. I'm doing this by checking 4 different buffers/queues: the IQ, LSQ, DecodeQ, and storebuffer. once these are empty, I feel that it is safe to say the pipe is empty and also that all memory is updated for that particular CPU. the other CPUs will likewise do the same and once all CPUs have done this, the signalSwitched call in the Sampler can proceed to let the SimpleCPUs takeOverFrom the Detailed CPUs. > > Now the problem I'm seeing is that the ExecContexts don't really "completely" takeOverFrom the ExecContexts tied to the previous phase's CPUs. There is a structure called waitList in ExecContext, which seems to be only getting modified by the Tru64::* functions. However, this structure is not "copied" when a takeOverFrom occurs. An example, is when some context is put into a suspended state. Is this something that has not been completed yet? Yea, unfortunately the Tru64 pthreads syscall emulation ended up turning into a thread scheduler in m5 itself. I pulled the plug before it got too ugly, but that's what that is for. I can see how that might cause problems with the sampler, but can't suggest any quick fixes off the top of my head. > It's really hard to tell between what is correct, incorrect, or not yet implemented yet. > > Another thing I was wondering is if the CPU's should all be set up with defer_registration set to True. > > It seems like if I don't set this, then I end up with much more ExecContexts in the Process then the number of CPUs. Also, what I see is that if I'm currently executing Detailed mode and a thread is created, the Tru64::init_exec_context will actually try to use an ExecContext from one of the SimpleCPU's instead of the DetailedCPUs. I believe that defer_registration should be true for all the CPUs that you're not using at the beginning of the simulation. > > anyways... i know i ask a lot of questions, but any help would be really appreciated. > > thanks > jeff > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > m5sim-users mailing list > m5sim-users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/m5sim-users