Hmmm, this seems to sound really stupid, but I was able to see the line
printed just before going to getSlot call, but I cannot see the lines
printed in the getSlot call for sn:8... The number at the end of the line
is the number of available slots.. Let me dig deeper to see what is going
on..
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.stage5: [tid:0]: [sn:8]: sending request to
system.cpu.dcache_port.
45500: system.cpu.dcache_port: Before going to getslot 8
On Thu, Mar 1, 2012 at 10:55 AM, Korey Sewell <ksew...@umich.edu> wrote:
> The function trace you need to follow is the code in resource::request().
>
> In each pipeline stage, an instruction will *request* a resource.
>
> Go to resource.cc and the request() function. From there you should be
> able to trace if getslot() ever gets called for sn:8 and if it doesnt what
> is the reason for it not being called.
>
> Once you identify why getslot() isnt being called, we can determine if its
> your configuration or a bug in the code or whatever it may be.
>
> Alternatively, You could always run the simulation through GDB, place a
> breakpoint in cacheunit::getslot() and stop every time you get to the
> getslot() function. If it doesnt stop for sn:8, then your problem is
> confirmed, if it stops in getslot() maybe you placed the debug message in
> getslot() to late in the code?
>
>
> On Thu, Mar 1, 2012 at 11:40 AM, Pritha Ghoshal <pritha9...@tamu.edu>wrote:
>
>> The TLB line is actually commented out, I forgot to delete it while
>> pasting it..
>>
>> About the slots, I can see the slot is getting dellocated from the sn:7
>> request in the next tick, in Stage6... But it neither gets allocated nor
>> deallocated for sn:8...
>>
>> I had put in two debug messages in cache getSlot and the resource getSlot
>> functions :
>> 45500: system.cpu.dcache_port: In cache unit // In cache_unit getSlot
>> 45500: system.cpu.dcache_port: Available slots:9 //In resource.cc
>> getSlot
>>
>> These get printed in the first case - sn:7, but they never get printed in
>> the second case.. I am not sure if it is calling some different function,
>> because I am not able to track what happens to the getSlot call in the
>> second time.. I expected these two lines to get printed again as the call
>> goes from resource.cc to cache_unit.cc - getSlot and returns to resource.cc
>> -getSlot..
>>
>> On Thu, Mar 1, 2012 at 10:12 AM, Korey Sewell <ksew...@umich.edu> wrote:
>>
>>> 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 <pritha9...@tamu.edu>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 <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
>>>>
>>>
>>>
>>>
>>> --
>>> - 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
>>
>
>
>
> --
> - 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
