Hi Andreas,
I had long thought on this, went through various papers. I came up with a
conclusion that Compound access with miss map paper[1] is best for
implementation of DRAM cache.
The missmap is a bitmap of blocks per page stored with the tag as SRAM and
the complete tag is stored inside the DRAM system.
Storing the details about a tag like the complete tag, location of data,
replacement policy etc. in the DRAM reduce the size of SRAM tag array.
Using the SRAM tag array reduces the miss penalty.
Note that miss map can only provide the information if block exist in DRAM
cache or not but the actually location of data can be given by the location
of the tag in the DRAM.
Compound access means keeping the row buffer open after the tag access for
the data access improving the hit latency.
Here, What we need to implement :
a) Simple Miss map controller (This will be implemented as a Non-coherent
cache )
b) Modification to the DRAM controller
I started up with the miss map controller implementation. I added a master
port (inherited from queued master port) in the conventional DRAM. On miss,
in the miss map, the timing request is forward to this port. But when I do
so, I get the following assertion fail --
gem5.debug: build/ALPHA/mem/packet_queue.cc:66: void PacketQueue::retry():
Assertion `waitingOnRetry' failed
This is for the queue in the master port. I found that when the timing
request is sent through the master port, it sometimes fails to send.
When they are retried, the above error pops in.
The configurations in CacheConfig.py are as follows :
if options.l3cache:
# Provide a clock for the L2 and the L1-to-L2 bus here as they
# are not connected using addTwoLevelCacheHierarchy. Use the
# same clock as the CPUs.
if options.dramcache:
system.l3 = dram_cache(clk_domain=system.cpu_clk_domain)
r = AddrRange(options.l3_size)
system.l3.range = m5.objects.AddrRange(r.start, size = r.size())
system.l3.num_cpus = options.num_cpus
system.l3.num_sets = options.miss_map_num_set
system.l3.miss_map_per_set = options.l3_assoc
system.l3.block_per_page = options.block_per_page
system.l3.blk_size = options.cacheline_size
system.l3.dramClock = options.dram_cache_clock
system.l3.in_addr_map = False
system.l3.statsFile = options.dram_stats_file
else:
print "Invalid L3 Config"
sys.exit(1)
# Provide a clock for the L2 and the L1-to-L2 bus here as they
# are not connected using addTwoLevelCacheHierarchy. Use the
# same clock as the CPUs.
system.l2 = l2_cache_class(clk_domain=system.cpu_clk_domain,
size=options.l2_size,
assoc=options.l2_assoc)
system.tol2bus = L2XBar(clk_domain = system.cpu_clk_domain)
system.tol3bus = L2XBar(clk_domain = system.cpu_clk_domain)
system.l2.cpu_side = system.tol2bus.master
system.l2.mem_side = system.tol3bus.slave
system.l3.cpu_port = system.tol3bus.master
system.l3.mem_port = system.membus.slave
else:
if options.l2cache:
...................................
The membus is SystemXBar.
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
