For #2, You shouldnt need to explicitly used the TLBs in the latest version of the code. The CacheUnit already does the TLB translation for you so you can remove resource requests for that.
For the slot problem, you need to figure out if and when slots are getting allocated/deallocated for the dcache unit. I would use the "Resource" flag in isolation and then check to see if slots are ever getting deallocated in the dcache unit.There's a line that says "Allocating [slot ..." in resource.cc as well as a line that says "Deallocating [slot ..." in resource.cc. With those two in tandem, you should be able to figure out if this is a special case of not deallocating slots for sn:8 or is this happening to all memory request to the dcache. After that, the DCache unit has a "getSlot" function that you can go into and insert some debug messages to see why exactly it is returning that there is no slot available. I think either the tlb is never getting unblocked or the slots aren't getting deallocated after the 'CompleteReadData' is called in the execute() function. On Thu, Mar 1, 2012 at 10:48 AM, Pritha Ghoshal <[email protected]> wrote: > Hi Korey, > > The answers to your questions are: > 1. Yes, sn:7 finishes and graduates. > > 2. These are the codes in Stage 5 and 6 in cpu.cc. // DCache Initiate > Access > if (inst->isMemRef()) { > // S5.needs(DTLB, TLBUnit::DataLookup); > if (inst->isLoad()) { > S5.needs(DCache, CacheUnit::InitiateReadData); > } else if (inst->isStore()) { > S5.needs(DCache, CacheUnit::InitiateWriteData); > } > } > // Stage 6 > // --------------------------------------- > // DCache Complete Access > if (inst->isMemRef()) { > if (inst->isLoad()) { > S6.needs(DCache, CacheUnit::CompleteReadData); > } else if (inst->isStore()) { > S6.needs(DCache, CacheUnit::CompleteWriteData); > } > } > > 3. It stalls in tick 84000. > > 4. The InOrderCachePort is already on, I switched on InOrderCPUAll.. The > first time it should not be able to get the port, but at least it should go > through the same functions and then return.. In 45500 the Dcache port is > being deallocated, sn:8 should be able to get the slot then.. But the > function calls do not seem to be taking place in the same way.. > > I will look into the execute call, but one request is completing till > graduation, so I am guessing there is nothing wrong with the execute call.. > > Pritha > > > On Thu, Mar 1, 2012 at 7:28 AM, Korey Sewell <[email protected]> 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 <[email protected]>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 >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> >> -- >> - Korey >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
