Hi Just on inform you. When I am starting the system in detailed mode, the assertion fails for isUncacheable. The error is: gem5.opt: build/ARM/mem/cache/cache_impl.hh:1207: void Cache<TagStore>::recvTimingResp(PacketPtr) [with TagStore = LRU, PacketPtr = Packet*]: Assertion `!tgt_pkt->req->isUncacheable()' failed.
Workaround is: I am using default timing mode to get the checkpoint and then using that checkpoint to start detailed mode. So far it is running fine. ᐧ On Mon, Apr 20, 2015 at 10:47 AM, Davesh Shingari <[email protected]> wrote: > 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] > -- 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
