Sorry to be behind on these threads... but I want to give a big thumbs up to the idea of unifying the port interfaces between Ruby and the classic memory system. Given all the revamping Andreas is doing to the latter, it makes sense to try and fold this goal into his efforts. I'm happy to pitch in and help come up with a satisfactory unified design if needed.
Steve On Thu, May 31, 2012 at 10:36 AM, Andreas Hansson <[email protected]>wrote: > Hi Brad, > > Thanks for the swift response. > > 1) I completely forgot about the C++ side of things, where the memories > are indeed used implicitly through the getPhysMem in the system. The whole > process is rather complicated at the moment, first creating a bunch of > memory controller that are (or not) connected to the classic memory system, > then use their total size to create a bunch of other memory controllers > that live inside Ruby, and finally use both of these during the simulation. > That's what got me all confused. I am tempted to suggest to switch to use a > "total_mem_size" for Ruby, and then instantiate an AbstractMemory in the > RubySystem to use for the backing store. > > 2) I really like the idea of the interface, and I would propose to go with > the "new" ports, i.e. what is used in the updated classic memory system > (with a few more changes to come). If they are not sufficient, then we > should consider changing them accordingly with the new requirements in > mind. The next patch on our list is the separation of a port and an > interface, and that should really simplify any such work. > > Andreas > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Beckmann, Brad > Sent: 31 May 2012 16:39 > To: gem5 Developer List > Subject: Re: [gem5-dev] Memory controller is Ruby systems > > Hi Andreas, > > I'm a bit confused. Physmem (now a simple memory) is still used by Ruby > as a backing store and RubyPort.cc still performs functional accesses on > it. Since Ruby can't fully support functional access this second > "architectural" version of memory is still needed. It is not just a > MemObject used during configuration. Therefore I don't think 1) is a > solution. > > As far as 2) goes, I think it would be best if we came up with an > interface that the memory controllers already used by Ruby can be used by > the classic model. Here at AMD we have several different memory > controllers that tie into the current MessageBuffer interface. Actually we > have a patch that makes that better virtualizes that interface. I have it > on my to do list to post that patch. If you're interested, I'll try to get > that out there soon. > > Brad > > > > -----Original Message----- > > From: [email protected] [mailto:gem5-dev- > > [email protected]] On Behalf Of Andreas Hansson > > Sent: Thursday, May 31, 2012 6:27 AM > > To: gem5 Developer List > > Subject: [gem5-dev] Memory controller is Ruby systems > > > > Hi all, > > > > In our current work on memory controller models I have had another look > at > > the gem5 vs Ruby view of memories, and one thing I stumbled upon is the > > following: > > > > In e.g. simple-timing-ruby.py we create something called physmem (just a > > simple memory) with default parameters, however it is not connected to > > anything and just a child of the system. When we call Ruby.create_system, > > this uses system.memories.unproxy(system) to determine the total physical > > memory size, but that's all. In other words, we create a MemObject, > leave it > > dangling, and then just have it hanging there to represent a scalar. This > > causes the controller to fatal saying it is unconnected (and overall > does not > > strike me as a very good design). > > > > I see two "solutions": > > > > > > 1. Do not instantiate a memory controller and leave it dangling. > Instead > > pass a size parameter to Ruby.create_system and check that > > system.memories is [] > > > > 2. Do it the proper way and connect the memory controllers through > Ruby > > i.e. Ruby replaces the interconnect, but leaves the actual memory > controller > > on the outside (there was a PPT being circulated roughly a year ago with > a > > proposal from Ali and myself to do this). > > > > Can I go ahead and implement 1 as a quick fix? Do you Ruby Ninjas out > there > > see any problems with this? > > > > Thanks, > > > > Andreas > > > > -- 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-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > > > -- 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-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
