Anthony, that's not too many cycles deep, so I'd run the simulator with the traceflags O3CPUAll on and save the trace.
Once, that is done, grep out the information for the relevant CPU (cpu1?) and the relevant Instruction (sn:175). The trace output is made such that anytime a reference is made to that instruction you should be able to find it just by using "sn:175". Once you find that instruction, you should be asking/trying to find out if "sn:175" is waiting for a memory instruction to come back, blocked on some event, or simply bypassed on being squashed when the drain event is being called. If the instruction is issued, then it's definitely in the ROB , so in the drain() function for commit_impl.hh you can check to see how the other instructions in the ROB are getting squashed/completed after a drain() and then figure out why that instruction is not getting removed. On Thu, Mar 10, 2011 at 1:17 AM, Anthony Gutierrez <[email protected]>wrote: > I am using the drain() functionality, and I also tried doDrain() which > loops until all objects have completely drained but that doesn't seem to > function properly for the o3 cpu model. Even when I try to do a single > switch starting from an o3 and switching to a simpleTiming cpu only once I > get the following assertion failure. I dump the instList in mem_dep_unit and > it always seems that cpu 1 has a single instruction remaining. This only > seems to happen when I use more than 1 core, if I use a single core I can > switch just fine. > > **** REAL SIMULATION **** > info: Entering event queue @ 0. Starting simulation... > info: Launching CPU 1 @ 99779000 > info: Entering event queue @ 100000000. Starting simulation... > hack: be nice to actually delete the event here > switching cpus > Instruction list 0 size: 0 > Instruction list 1 size: 0 > Instruction list 2 size: 0 > Instruction list 3 size: 0 > Memory dependence hash size: 0 > ================================ > Instruction list 0 size: 1 > Instruction:0 > PC: (0xfffffc0000010034=>0xfffffc0000010038) > [sn:175] > [tid:0] > Issued:1 > Squashed:0 > > Instruction list 1 size: 0 > Instruction list 2 size: 0 > Instruction list 3 size: 0 > Memory dependence hash size: 1 > ================================ > > m5.opt: build/ALPHA_FS/cpu/o3/mem_dep_unit_impl.hh:117: void > MemDepUnit<MemDepPred, Impl>::switchOut() [with MemDepPred = StoreSet, Impl > = O3CPUImpl]: Assertion `instList[0].empty()' failed. > > > Here is the code I added to the fs.py config script. > > if options.big_core: > little_core_cpus = [TimingSimpleCPU(defer_registration=True, > cpu_id=(np+i)) for i in xrange(np)] > > > for i in xrange(np): > little_core_cpus[i].system = testsys > little_core_cpus[i].clock = testsys.cpu[0].clock > > testsys.little_core_cpus = little_core_cpus > switch_little_core_cpu_list = [(testsys.cpu[i], little_core_cpus[i]) > for i in xrange(np)] > > print "**** REAL SIMULATION ****" > if options.big_core: > exit_event = m5.simulate(100000000) > m5.doDrain(testsys) > m5.switchCpus(switch_little_core_cpu_list) > > m5.resume(testsys) > exit_event = m5.simulate(maxtick - m5.curTick()) > else: > exit_event = m5.simulate(maxtick) > > > On 03/10/2011 12:57 AM, Ali Saidi wrote: > >> It is possible. I don't know if it works in the current code, but it did >> work at some point in the past. You probably need to drain() the system >> before you make the switch which should prevent any instructions from being >> inflight in the cpu. >> >> Ali >> >> >> >> On Mar 9, 2011, at 2:53 PM, Anthony Gutierrez wrote: >> >> I found a problem with my original script, I realized I wasn't reversing >>> the order of the switch list after I switched cpus. I corrected this but I >>> still get the same assertion failure. Can anybody tell me, is what I'm >>> trying to do even possible in m5 without major code modifications? i.e. >>> switching back and forth periodically between two different sets of cores. >>> >>> -Tony >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >>> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> >> > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- - Korey
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
