Hi Debiprasanna, I don’t understand the argument about DRAMSim2. It’s less flexible, and far slower than the gem5 controller. I am fairly convinced you’re best option here is to make this work with the DRAMCtrl.
A non-coherent cache could avoid much of the complication in the existing cache.hh/cc, and I am fairly sure we would be best off spending some more time thinking about the design, and the split between base.hh/cc and cache.hh/cc. It is quite a chunk of work though. Andreas From: gem5-users <[email protected]<mailto:[email protected]>> on behalf of Debiprasanna Sahoo <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Friday, 30 October 2015 at 11:26 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: Re: [gem5-users] DRAM cache instantiation Hi Andreas, Thanks for your reply. I am fine with DRAMCtrl also but right now I am looking to get it working with DRAMSim2 (I think going separate is better in terms to use different functionality in different modules). At this point of time, I am actually interested with the 2nd point which you made i.e. the non-coherent class. Can you give me a pointer of what should be the non-coherent.hh/cc be like or there exist any implementation of the same. I have never worked much on the multicore coherency of cache and hence am not able distinguish which code in cache_impl is for what. I just understood that at two different point request are sent to DRAM array i.e. 1. access function where the request is hit in the cache 2. when it is a fill in recvTimingResp method. (In-fact due to the same I attached the diff in the original mail). I think going by separate non-coherent class is a great idea. I would need some help in designing the same. Thanks, Debiprasanna Sahoo Research Scholar IIT Bhubaneswar On Fri, Oct 30, 2015 at 3:58 PM, Andreas Hansson <[email protected]<mailto:[email protected]>> wrote: Hi Debiprasanna, This sounds like a great addition to gem5! I would suggest a slightly different approach though, that hopefully will solve your problems with DRAMSim2: For the memory controller that holds the DRAM cache data, you can still use an instance of the DRAMCtrl, and to avoid causing problems with the AbstractMemory functionality, simply set in_addr_map to False, and conf_table_reported to False for this controller instance. This will give you an instance of the controller that is invisible in the system memory map. Let me know if you have any issues getting this right. Again, great initiative. Once you’ve got this all working, another aspect that we may want to consider is to not use the cache.hh/cc for the cache tags itself. To allow any line size, and also to avoid all the hassle of the coherency, I think we should create a noncoherent_cache.hh/cc. This new “system cache” would sit after the point of coherency, and not need to be encumbered with any coherency. It would this be far simpler than the existing cache. Andreas From: gem5-users <[email protected]<mailto:[email protected]>> on behalf of Debiprasanna Sahoo <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Friday, 30 October 2015 at 09:36 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: [gem5-users] DRAM cache instantiation Hi all, I am working on instantiating a DRAM LLC (currently just L2) in gem5 classic memory module. I am currently use DRAM cache with SRAM tag array and hence just need the DRAM timing latency rather than fixed hit latency of SRAM. Since instantiating multiple object of DRAMCtrl contributes directly to main memory, I decide to do the following 1. instantiate DRAMCtrl as normal memory controller. 2. Instantiate DRAMSim2 as DRAM l2 cache with another l2 tag cache array by inheriting the same from MemObject rather than abstract memory. Some other minute changes are also there. 3. I connect the tag array to the DRAMSim2 with a non coherent bus using a separate port known as array side port in the DRAM cache 4. I added the code in cache_impl(diff attached) 5. I have asso modified CacheConfig.py accordingly. Every thing seems to be OK. As I start the simulation, I observe that there are transaction on the new bus to the DRAM cache but the simulation hangs after a few transactions. I understand that I am doing some mistake in handling the request which are hit in the cache but unable to figure out what is the bug. I have worked fair bit on DRAM Controllers but this is my first experience with caches in gem5. I have also attached the dot file generated by gem5. Thanks, Debiprasanna Sahoo ________________________________ -- 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. _______________________________________________ gem5-users mailing list [email protected]<mailto:[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.
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
