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
