I made some changes to MESI_CMP_directory.py and those changes are
reflected in the output. The l1 and l2 controllers are now being attached
to ruby instead of system.
Nilay
On Thu, 10 Mar 2011, Nilay Vaish wrote:
I had originally put a print statement in getCCObject(), so using the word
'Creating' might have been mis-leading. For the previous output that I sent,
I had removed that statement. What follows is patch and then the output --
diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.py
+++ b/src/python/m5/SimObject.py
@@ -821,6 +821,7 @@
# necessary to construct it. Does *not* recursively create
# children.
def getCCObject(self):
+ print "Getting %s" % self.path()
if not self._ccObject:
# Make sure this object is in the configuration hierarchy
if not self._parent and not isRoot(self):
@@ -843,8 +844,11 @@
# Call C++ to create C++ object corresponding to this object
def createCCObject(self):
+ print "Creating ", self, " params"
self.getCCParams()
+ print "Creating ", self
self.getCCObject() # force creation
+ print "Done creating ", self
def getValue(self):
return self.getCCObject()
------------------------------------------------------------------
Creating root params
Creating root
Getting root
Done creating root
Creating system params
Getting system.physmem
Creating system
Getting system
Done creating system
Creating system.physmem params
Creating system.physmem
Getting system.physmem
Done creating system.physmem
Creating system.ruby params
Getting system.ruby.network
Getting system.ruby.network.topology
Getting system.ruby.network.topology.ext_links0
Getting system.ruby.l1_cntrl0
Getting system.ruby.l1_cntrl0.L1DcacheMemory
Getting system.ruby
Getting system.ruby.network
--
Nilay
On Thu, 10 Mar 2011, Steve Reinhardt wrote:
Is that it? It seems like there should be more output than from your
previous example, not less...
On Thu, Mar 10, 2011 at 5:36 AM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
Steve, here is the output after putting in the print statements.
Creating root params
Creating root
Done creating root
Creating system params
Creating system
Done creating system
Creating system.l1_cntrl0 params
Nilay
On Wed, 9 Mar 2011, Steve Reinhardt wrote:
It seems odd that it tries to create L1DcacheMemory right after it
creates
system. Can you add print statements like in this patch and see what it
shows?
diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.py
+++ b/src/python/m5/SimObject.py
@@ -843,8 +843,11 @@
# Call C++ to create C++ object corresponding to this object
def createCCObject(self):
+ print "Creating", self, "params"
self.getCCParams()
+ print "Creating", self
self.getCCObject() # force creation
+ print "Done creating", self
def getValue(self):
return self.getCCObject()
On Wed, Mar 9, 2011 at 2:34 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
Creating root
Creating system.physmem
Creating system
Creating system.l1_cntrl0.L1DcacheMemory
Creating system.ruby
Creating system.ruby.network
Creating system.ruby.network.topology
Creating system.ruby.network.topology.ext_links0
Creating system.l1_cntrl0
Creating system.l1_cntrl0.L1DcacheMemory
This is the output I obtained from SimObject.py, clearly there is a
cycle.
Should not the cache controllers be part of ruby, instead of being part
of
system? Once they become part of ruby, it should be possible to traverse
the
controller array and figure out all the caches.
Nilay
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
