The namespacing issue should be fixed in the next version. One of the biggest changes I've made is to get rid of all of the global fields and put all of the configuration variables into a config struct. This also enables one to instantiate heterogeneous instances of DRAMSim2 (which was not previously possible because of the global variables). These options can be overridden by passing an std::map of options, through an ini file, or kept as the compiled defaults.
I'll add a unique ID for transactions that can be queried. As far as implementing flow control on return requests, do you have any thoughts as the best way to do this? Would it be easiest to simply allow GEM5 to call into DRAMSim2 and ask if any requests are waiting to be returned? Or have the completion callback return a boolean value of whether the response has been accepted by GEM5 (and keep it buffered in DRAMSim2 if GEM5 returns false and try again next cycle)? I'll investigate how hard it would be to implement non-BL-sized requests and doing channel interleaving outside of DRAMSim2 (I suspect the latter might be fairly simple). -Paul On Mon, Nov 25, 2013 at 1:14 PM, Andreas Hansson <[email protected]>wrote: > Hi Paul, > > My pleasure. I figured it was about time, although I firmly believe that > the integrated DRAM controller model (SimpleDRAM) removes much of the need > :-). > > When it comes to changes, have a look at the patch, and you will see a > number of things that say something along the lines of “DRAMSim2 does not > enable us to do X, hence we have to do Y”. Most importantly: 1) put > everything in a namespace to avoid clashes, 2) enable flow control on > responses, 3) add some form of tagging to enable us to not assume FIFO for > requests to the same address (or merge them somehow), 4) add getters for a > param struct to figure out what DRAMSim2 has been initialised to look like, > 5) add support for splitting system requests that are not BL x width sized, > 6) allow a multi-channel system to be created with a crossbar/interleaving > outside DRAMSim2 (in SimpleDRAM this is achieved by making it aware of the > # channels, to “prune” those bits in the decoding). > > I am crossing my fingers and hoping that the availability of good DRAM > controller models will make some Ruby developer take the plunge and split > the directory controller and memory controller model in Ruby so that the > “normal” gem5 controllers (DRAMSim2 included) can be used in those > configurations as well. > > Let me know if you want to discuss any of these topics further. > > Andreas > > From: Paul Rosenfeld <[email protected]> > > Reply-To: gem5 users mailing list <[email protected]> > Date: Monday, 25 November 2013 10:45 > > To: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] DRAMSim2+GEM5 Error > > Hi Andreas, > > Thanks for writing this patch. I'm in the process of making some changes > to the DRAMSim2 interface that will eventually be going into the master > branch and be breaking the current API. Since I'm already breaking the API, > if you have any ideas for changes that would make it easier to integrate > DRAMSim2 with GEM5, I'll do my best to try to implement them. > > Thanks, > Paul > > > On Mon, Nov 25, 2013 at 8:59 AM, Andreas Hansson > <[email protected]>wrote: > >> Hi, >> >> I suggest you have a look at http://reviews.gem5.org/r/2087/ >> >> In contrast to earlier attempts I’ve seen, this patch properly >> integrates DRAMSim2 as a type of memory in gem5. >> >> All you have to do is follow the instructions in the patch. >> >> Andreas >> >> From: Xing Niu <[email protected]> >> Reply-To: gem5 users mailing list <[email protected]> >> Date: Sunday, 24 November 2013 23:20 >> To: "[email protected]" <[email protected]> >> Subject: [gem5-users] DRAMSim2+GEM5 Error >> >> Hi, I want to use DRAMSim2+GEM5, and the patch of Xiangyu Dong is >> used. Dong only supplies the se_dramsim2.py, but I want to use the FS >> mode. >> >> I modified the fs.py, only adding one sentence below >> >> test_sys.physmem = DRAMMemory(range=AddrRange("512MB")) >> >> the following error occured. >> >> xniu@hec-53:~/gem5_parsec1/gem5$ ./build/ALPHA_FS/m5.opt >> configs/example/fs_dramsim2.py -t >> >> gem5 Simulator System. http://gem5.org >> gem5 is copyrighted software; use the --copyright option for details. >> gem5 compiled Nov 24 2013 17:37:01 >> gem5 started Nov 24 2013 23:20:56 >> gem5 executing on hec-53 >> command line: ./build/ALPHA_FS/m5.opt configs/example/fs_dramsim2.py -t >> Global frequency set at 1000000000000 ticks per second >> warn: This is an integrated DRAMsim v2 module >> CPU Clock = 2000MHz >> Memory Bus Clock = 666MHz >> Memory Capacity = 512MB >> info: kernel located at: >> /mnt/common/xniu/parsec/m5_system/binaries/vmlinux >> Listening for system connection on port 3456 >> 0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 >> 00:00:00 2009 >> Error connecting port system.membus.port to <orphan PhysicalMemory>.port >> Traceback (most recent call last): >> File "<string>", line 1, in <module> >> File "/mnt/common/xniu/gem5_parsec1/gem5/src/python/m5/main.py", line >> 356, in main >> exec filecode in scope >> File "configs/example/fs_dramsim2.py", line 219, in <module> >> Simulation.run(options, root, test_sys, FutureClass) >> File "/mnt/common/xniu/gem5_parsec1/gem5/configs/common/Simulation.py", >> line 235, in run >> m5.instantiate(checkpoint_dir) >> File "/mnt/common/xniu/gem5_parsec1/gem5/src/python/m5/simulate.py", >> line 79, in instantiate >> for obj in root.descendants(): obj.connectPorts() >> File "/mnt/common/xniu/gem5_parsec1/gem5/src/python/m5/SimObject.py", >> line 972 , in connectPorts >> portRef.ccConnect() >> File "/mnt/common/xniu/gem5_parsec1/gem5/src/python/m5/params.py", line >> 1473, in ccConnect >> [el.ccConnect() for el in self.elements] >> File "/mnt/common/xniu/gem5_parsec1/gem5/src/python/m5/params.py", line >> 1395, in ccConnect >> peer.simobj.getCCObject(), peer.name, peer.index) >> File "/mnt/common/xniu/gem5_parsec1/gem5/src/python/m5/SimObject.py", >> line 943 , in getCCObject >> raise RuntimeError, "Attempt to instantiate orphan node" >> RuntimeError: Attempt to instantiate orphan node >> >> >> Thanks in advance, >> Xing >> >> >> >> -- 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
