Hi Nilay,

Thank you for your reply. In MESI_CMP_directory-L1cache.sm, there are
several latency parameters: l1_request_latency, l1_response_latency, and
to_l2_latency. Do you mean these parameters decide the communication time?
However, I didn't see any different latencies between a local access (L1D-0
to L2-0) and a remote access (L1D-0 to L2-1).  For example, in
action(b_issueGETX), the out_msg.Destination varies based on the return
value of mapAddressToRange(), however, the latency is statically set as
l1_request_latency, which is 2 in default. Also there are other two actions
which involve delayed cycles (which call profileMsgDelay()), but I've no
idea if it is related to the varied communication time.

I expect to control the communication time myself. For example, if it is a
local access from a L1 cache to its own L2 cache slice (L1D-0 to L2-0), the
access latency is 2; if it is a remote access from a L1 cache to a remote
L2 cache slice (L1D-0 to L2-3), the access latency is 2 * num_of_hops (2*4
in this case). So I thought it should be calculated based on the distance
from the requestor to the destination. But I cannot find anywhere that is
related to it. So could you please give me any hints on how to deal with
it? Do I misunderstand it at all? Thank you for your help.


Thanks,
Yingying

On Wed, Oct 24, 2012 at 10:40 AM, Nilay Vaish <ni...@cs.wisc.edu> wrote:

> On Tue, 23 Oct 2012, Cookie wrote:
>
>  Hi,
>>
>> I added a function in CacheMemory.* called hashCompare(DataBlock dbk).
>> This
>> function is called in MESI_CMP_directory-L2cache.sm:
>> -----------------------------
>> in_port(**responseIntraChipL2Network_in, ResponseMsg, responseToL2Cache,
>> rank
>> = 1) {
>> ......
>> if(in_msg.Type == CoherenceResponseType:MEMORY_**DATA) {
>>
>>              DataBlock dbk := cache_entry.DataBlk;
>>              L2cacheMemory.hashCompare(dbk)**;
>>
>>              trigger(Event:Mem_Data, in_msg.Address, cache_entry, tbe);
>> ....
>> }
>> -----------------------------
>> It was also added in RubySlicc_Types.sm. However when I compiled it, it
>> got
>> following error:
>> -----------------------------
>> build/X86/mem/protocol/**L2Cache_Wakeup.do: In function
>> `L2Cache_Controller::wakeup()'**:
>> /home/ytian/Documents/Gem5/**build/X86/mem/protocol/**
>> L2Cache_Wakeup.cc:234:
>> undefined reference to `CacheMemory::hashCompare(**DataBlock)'
>> collect2: ld returned 1 exit status
>> scons: *** [build/X86/gem5.debug] Error 1
>> scons: building terminated because of errors.
>> -----------------------------
>> Could anyone tell me what the problem is? I added other functions (which
>> didn't take parameters) in this way and they worked fine.
>>
>
> You should try to figure this error on your own, it is regular compilation
> problem. I think there is difference between the declaration that appears
> in CacheMemory.hh and the definition that appears in CacheMemory.cc.
>
>
>
>> Also I have another question related to the communication between L1 and
>> L2
>> caches. As I know, a local L1 (let's say L1D-0) probably requests cache
>> block from a remote L2 cache slice (e.g., L2cache-1). Compared to a local
>> access (L1D-0 to L2cache-0), is there any latency varies? I assume that a
>> local access incurs smaller access latency than a remote access, is it
>> correct? Could anyone tell how it is simulated in any related code? Since
>> in MESI_CMP_directory-*.sm, i cannot find any places that differ the
>> requestor from local to remote one. Could you please give me any
>> explanation/instruction on the communication between L1caches and a shared
>> L2 cache? Thank you for your help.
>>
>>
> There are certain latency parameters that appear in the file
> MESI_CMP_directory-L1cache.sm. Those parameter decide communication time
> between the l1 and the l2 cache controllers.
>
> --
> Nilay
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to