Hello Andreas
Thanks a lot. That helped a lot. I implemented the configuration matching
my requirement.
Just one clarification needed. So in the access template in cache_impl.hh I
inserted the following logic:
-----------------------------------------------------------------------------------------------------------------------------------------------------
if (pkt->req->masterId() == 12 && !isTopLevel)
{
pkt->req->setFlags(Request::UNCACHEABLE);
DPRINTF(Cache, "Davesh: Uncacheable set for Master id is %d\n",
pkt->req->masterId());
}
-----------------------------------------------------------------------------------------------------------------------------------------------------
ᐧ
What I am expecting is that whenever request comes from L1 cache with
master id 12, then that request will be uncacheable in L2, i.e. it won't be
allocated a cache line. Is my assumption correct.
Is this what uncacheable does?
And do I need to make these changes other places too i.e. should I make
these request uncacheable everywhere isUncacheable is being checked?
Thanks for your time.
--
Have a great day!
Thanks and Warm Regards
Davesh Shingari
Master's in Computer Engineering [EE]
Arizona State University
[email protected]
On Wed, Apr 15, 2015 at 5:49 PM, Andreas Hansson <[email protected]>
wrote:
> Hi Davesh,
>
> All the classic memory system cache source files are in src/mem/caches,
> and this is also where you can see how the coherency protocol is
> implemented.
>
> Andreas
>
> From: Davesh Shingari <[email protected]>
> Reply-To: gem5 users mailing list <[email protected]>
> Date: Thursday, 16 April 2015 01:24
>
> To: gem5 users mailing list <[email protected]>
> Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
>
> Hello Andreas
>
> Thanks for the reply. It makes much more sense now. Just one
> clarification.
>
> If I understand clearly then you mean that mentioning of PROTOCOL is
> irrelevant, but then how come MOESI gets selected (as you said Classic
> memory model uses it, which file is associated with it). So if I change the
> MOESI protocol files in src/mem/protocol, then the changes won't have any
> effect. Right?
> Can you please tell the file which implements MOESI protocol for ARM
> system.
>
> The reason I am asking is that I am confused because you say:
> "With ARM you should use the classic memory system (in some
> configuration), and thus a MOESI protocol."
> " Since you are not using Ruby the PROTOCOL is irrelevant"
> So I am confused whether MOSEI is used or not? If yes, then which
> associated files implements that, because in build directory I can't see
> any MOESI file.
>
> Thanks a lot for your time.
>
> On Wed, Apr 15, 2015 at 5:03 PM, Andreas Hansson <[email protected]>
> wrote:
>
>> Q1 Since you are not using Ruby the PROTOCOL is irrelevant
>>
>> Q2 As with all gem5 objects there is a Python class (BaseCache.py)
>> instance created. Check out CacheConfig.py and the other config scripts.
>>
>> Q3 I’d suggest to make them uncacheable based on masterId. Note that
>> you need the non-stable gem5 repo to support snooping for uncacheable
>> accesses.
>>
>> Q4 The build/ directory contains all the built files.
>>
>> Andreas
>>
>> From: Davesh Shingari <[email protected]>
>> Reply-To: gem5 users mailing list <[email protected]>
>> Date: Thursday, 16 April 2015 00:52
>> To: gem5 users mailing list <[email protected]>
>> Subject: Re: [gem5-users] ARM - Cache Coherence Protocol
>>
>> Hello Andreas
>>
>> Thanks a lot for prompt reply. Sorry for long list of questions. Please
>> help me in the following related doubts:
>>
>> Q.1
>> For building gem5.opt do we need to provide some specific arguments. I
>> mean that right now by default when I built gem5.opt the default
>> configuration in build_opts/ARM is as follows:
>> TARGET_ISA = 'arm'
>> CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,MinorCPU'
>> *PROTOCOL = 'MI_example'*
>> Do I need to change it to PROTOCOL = 'MOESI_CMP_directory' or PROTOCOL
>> = 'MOESI_CMP_token' ?
>>
>> The reason is that when I built it by default configuration and run the
>> simulation, then in the
>> directory gem5-stable/build/ARM/mem/protocol/L1Cache_Controller.cc file , I
>> see all the transitions associated with MI_example protocol.
>>
>> Q.2
>> From where does L2 cache gets created. When I ran the gem5.opt for ARM
>> with specification of "--caches --l2cache", I could see in config.ini that
>> L2cache was created, but I am confused how was it created as in which file
>> was involved. It will be highly appreciated if you could point out which
>> file does that task:
>>
>> gem5-stable/src/mem/simple_mem.cc
>>
>> gem5-stable/src/mem/cache/base.cc & cache.cc
>>
>> I am assuming that /src/mem/ruby/structures/Cache_Memory.cc won't be
>> used for sure as it doesn't use Ruby.
>>
>> Q.3
>> Can you give any suggestion on how can we bypass request from a L1 cache
>> of a specific processor directly to main memory bypassing L2. I mean
>> suggestion on which file to look for. In x86 system we could have used
>> MachineId to know the requestor and in allocateCacheblock could have
>> bypassed the allocation on basis of l1cache id. Can you provide some
>> pointers in ARM?
>>
>> Q.4 (Not that important)
>> Is there a way to know that the specific file is compiled for the
>> gem5.opt (I know debugger and logs can be used, but is looking into
>> build/ARM/ directory enought to draw conclusions that a file was compiled)
>>
>>
>>
>> On Wed, Apr 15, 2015 at 4:31 PM, Andreas Hansson <[email protected]
>> > wrote:
>>
>>> Hi Davesh,
>>>
>>> With ARM you should use the classic memory system (in some
>>> configuration), and thus a MOESI protocol. There is no need to use Ruby.
>>>
>>> The cache and crossbar models in the classic memory system provide a
>>> very flexible set of components that you can use to build a wide range of
>>> on-chip memory systems.
>>>
>>> Andreas
>>>
>>> From: Davesh Shingari <[email protected]>
>>> Reply-To: gem5 users mailing list <[email protected]>
>>> Date: Wednesday, 15 April 2015 23:45
>>> To: gem5 users mailing list <[email protected]>
>>> Subject: [gem5-users] ARM - Cache Coherence Protocol
>>>
>>> Hi
>>>
>>> In the ARM FS simulation which cache coherence model is used. When I
>>> look at the build_opts/ARM, then I can see Protocol as MI_example. If that
>>> is the one used then how come 2 level cache hierarchy is implemented
>>> (because the MI example has 1 level cache hierarchy)?
>>>
>>> And ARM uses Classic Memory Model instead of Ruby. If yes, then
>>> doesn't it then implements MOESI protocol. if no, then is Ruby supported?
>>>
>>> --
>>> Have a great day!
>>>
>>> Thanks and Warm Regards
>>> Davesh Shingari
>>> Master's in Computer Engineering [EE]
>>> Arizona State University
>>>
>>> [email protected]
>>>
>>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>>> confidential and may also be privileged. If you are not the intended
>>> recipient, please notify the sender immediately and do not disclose the
>>> contents to any other person, use it for any purpose, or store or copy the
>>> information in any medium. Thank you.
>>>
>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>>> Registered in England & Wales, Company No: 2557590
>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>>> 9NJ, Registered in England & Wales, Company No: 2548782
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> [email protected]
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>
>>
>>
>> --
>> Have a great day!
>>
>> Thanks and Warm Regards
>> Davesh Shingari
>> Master's in Computer Engineering [EE]
>> Arizona State University
>>
>> [email protected]
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> Registered in England & Wales, Company No: 2557590
>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> Registered in England & Wales, Company No: 2548782
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
>
> --
> Have a great day!
>
> Thanks and Warm Regards
> Davesh Shingari
> Master's in Computer Engineering [EE]
> Arizona State University
>
> [email protected]
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2548782
>
> _______________________________________________
> 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
