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
