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 <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
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
