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