It probably means that two objects have pointers to each other as parameters (or more generally there's a cycle). See step 3 here: http://m5sim.org/wiki/index.php/SimObject_Initialization
On Tue, Mar 8, 2011 at 4:27 PM, Nilay Vaish <[email protected]> wrote: > When does the following error occurs? Is it that an object is being > accessed while it is being created? > > > File "/afs/ > cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m5/SimObject.py", > line 834, in getCCObject > raise RuntimeError, "%s: Cycle found in configuration hierarchy." \ > RuntimeError: system.l1_cntrl0.L1DcacheMemory: Cycle found in configuration > hierarchy. > > > -- > Nilay > > > On Tue, 8 Mar 2011, Steve Reinhardt wrote: > > Forgot to mention that this is how we handle registering all the thread >> contexts within a system... you can look at that code (in the CPU models >> and >> in System) for an example. >> >> On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt <[email protected]> wrote: >> >> Sorry I missed this thread... I just read Nilay's response about python >>> issues and he pointed me over here. >>> >>> One thing we should think about is that we really only want the caches >>> within a single system to be flushed at once... I know that it's unlikely >>> that anyone will want to model two systems with detailed memory models at >>> once, and I vaguely recall there were other issues with Ruby not really >>> supporting multiple instances of itself, but I don't want to see us make >>> things less modular than they already are. >>> >>> The m5 idiom for doing this is: >>> - add a parameter to each cache/controller/whatever we want to track like >>> this: >>> system = Param.System(Parent.any, "system object") >>> - add a method to the System object like registerCache(Cache *c) that >>> adds >>> c to the system object's list of caches >>> - Have each cache constructor call p->system->registerCache(this) to >>> register itself >>> >>> Would something like this work for what you're trying to do? >>> >>> Steve >>> >>> >>> On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish <[email protected]> wrote: >>> >>> It seems that this will work out. We can make AbstractController call a >>>> static function of RubyPort class that will add the calling object to >>>> some >>>> list which will be accessed while making functional accesses. As far as >>>> pushing functional access support to Sequencer in to concerned, there >>>> was no >>>> particular reason for that. Since Sequencer handles that timing acesses, >>>> I >>>> thought that should be the file that would contain the code for >>>> functional >>>> accesses. I am fine with functional access code going in to RubyPort. >>>> >>>> -- >>>> Nilay >>>> >>>> >>>> >>>> _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
