Hi Andreas, I completely agree with what you say on your argument on DRAMSim2 but at this point of time, I just want to keep the two things separate and in-fact with DRAMSim2 I have already managed to get it working from DRAM side (I dont want to roll back this effort right now and start with DRAMCtrl). The issue I am currently facing is with the tag part in the cache code.
I have observed after my integration that the DRAM side receives the request and responds to it. But after receiving the response from DRAM cache array, I am unable to handle it in the cache tag array and hence the CPUs stall after having 1 hit in the DRAM cache. Regarding non-coherent cache, I agree that it is quite a work to deal with, but the design should be made simple and easy to understand. Anyways let me think some more into this. Thanks, Debiprasanna Sahoo Research Scholar IIT Bhubaneswar On Fri, Oct 30, 2015 at 7:25 PM, Andreas Hansson <[email protected]> wrote: > 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]> on behalf of Debiprasanna > Sahoo <[email protected]> > Reply-To: gem5 users mailing list <[email protected]> > Date: Friday, 30 October 2015 at 11:26 > To: gem5 users mailing list <[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]> > 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]> on behalf of Debiprasanna >> Sahoo <[email protected]> >> Reply-To: gem5 users mailing list <[email protected]> >> Date: Friday, 30 October 2015 at 09:36 >> To: gem5 users mailing list <[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] >> 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
