Hi Andreas Thanks a lot. I found and applied the patches. Thanks again for your help. ᐧ
On Mon, Apr 20, 2015 at 5:52 AM, Andreas Hansson <[email protected]> wrote: > Hi Davesh, > > There is a whole bunch of patches related to uncacheable accesses that > you will need. Just have a look at the patches I have posted in the last > three weeks. > > Andreas > > From: Davesh Shingari <[email protected]> > Reply-To: gem5 users mailing list <[email protected]> > Date: Saturday, 18 April 2015 02:35 > > To: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] ARM - Cache Coherence Protocol > > Hello Andreas > > Is the changelist on > https://www.mail-archive.com/[email protected]/msg14217.html , the one > you are talking about? > > Can I just update these changes on the gem5 dev downloaded code setup? > ᐧ > > On Thu, Apr 16, 2015 at 7:20 PM, Davesh Shingari <[email protected] > > wrote: > >> Hello Andreas >> >> Thanks for prompt reply. Can you please let me know what you mean by "You >> should only ever have to do this in the L1 (or the LSQ)" ? >> My implementation is for L2 cache line i.e. when cache line request comes >> from L1 cache corresponding to Master Id of 12. >> >> I know the implementation is brittle and is temporary. I will be >> modifying it to make it stable and configurable. >> >> On Thu, Apr 16, 2015 at 6:21 PM, Andreas Hansson <[email protected] >> > wrote: >> >>> Hi Davesh, >>> >>> Conceptually it looks ok (but rather brittle using a number like >>> that). You should only ever have to do this in the L1 (or the LSQ). >>> >>> Also, for this to work, you need the patches for uncacheable access >>> that are currently on the review board. I’m hoping they can be pushed in >>> the next week or so. >>> >>> Andreas >>> >>> From: Davesh Shingari <[email protected]> >>> Reply-To: gem5 users mailing list <[email protected]> >>> Date: Thursday, 16 April 2015 16:07 >>> >>> To: gem5 users mailing list <[email protected]> >>> Subject: Re: [gem5-users] ARM - Cache Coherence Protocol >>> >>> 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 >>>> >>> >>> >>> >>> >>> -- 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] >> > > > > -- > 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]
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
