I also asked something similar with O3CPU http://www.mail-archive.com/gem5-users@gem5.org/msg01855.html
On 3/1/12, Korey Sewell <ksew...@umich.edu> wrote: > - Have you seen any of the other load/stores complete (e.g. [sn:7])? > > - what code is in your createBackEndSked() function in cpu.cc? Do your > load/store instructions have a schedule entry to complete the data > read/write? > > - At what tick does it stall after 45500? If it's soon after that, then > maybe the activity counter got set too low in the InOrderCPU constructor. > > - I'd suggest turning on the "InOrderCachePort" trace flag and rerunning. > There should be some reason printed out to why [sn:8] is failing on it's > access to the cache (is the cache port blocked?) > > Lastly, you'll want to look at the "execute()" function in a particular > resource to trace the program flow. In each pipeline stage, a instruction > will find a resource that it wants to access and request that resource. > That requests translates into a "execute()" call into that particular > resources code. > > > On Thu, Mar 1, 2012 at 1:37 AM, Pritha Ghoshal <pritha9...@tamu.edu> wrote: > >> Hi, >> >> I am trying to Inorder 9 stage pipeline and it is stalling after the first >> few cycles.. This is the culprit as far as I managed to dig in by turning >> on traces.. >> >> The following snippets of the trace are from the same tick, one after >> another.. Initially it is trying to send a request to Dcache, it prints >> "In >> cache unit" and "Available slots" before allocating the slot, these two >> statements I had added to cpu/inorder/resources/cache_unit.cc >> getSlot(inst) >> function and cpu/inorder/resource.cc getSlot(inst) function. >> >> 45500: system.cpu.stage5: [tid:0]: [sn:7]: sending request to >> system.cpu.dcache_port. >> 45500: system.cpu.dcache_port: Before going to getslot 9 >> 45500: system.cpu.dcache_port: In cache unit >> 45500: system.cpu.dcache_port: Available slots:9 >> 45500: system.cpu.dcache_port: Allocating [slot:0] for [tid:0]: [sn:7] >> >> But the next time when getSlot is being called in resource.cc in the same >> tick, it does not print either of the two statements.. I am not sure what >> is the flow of the program, and why there should be a difference between >> two requests one after another.. >> >> 45500: system.cpu.stage5: [tid:0]: [sn:8]: sending request to >> system.cpu.dcache_port. >> 45500: system.cpu.dcache_port: Before going to getslot 8 >> 45500: system.cpu.dcache_port: No slot available for [tid:0]: [sn:8] >> 45500: system.cpu.stage5: [tid:0]: [sn:8] request to >> system.cpu.dcache_port failed. >> >> Because the dcache port is never got by the instruction serial number 8, >> the flow of instruction gets stalled and the cpu goes to sleep for ever.. >> Could anyone suggest any reason for this apparent difference in behavior? >> >> Pritha >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > - Korey > -- -- // Naderan *Mahmood; _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
