On Fri, Mar 11, 2011 at 6:57 AM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
> On Thu, 10 Mar 2011, Nilay Vaish wrote: > > 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 >> >> > Steve asked where exactly is the cycle coming from. Here is the explanation > -- system.ruby needs a pointer to the network object. The network object > needs topology pointer, which further needs the link pointers. Each link > connects two nodes. So again it needs pointers to those, in this case the > external link 0 needs pointer to the cache controller. The cache controller > needs pointers to cache memories that it is managing. Earlier cache memories > were created just from cache configuration parameters. But now I added that > pointer to RubySystem is required for construction of cache memory object. > This led to a cycle in the dependence graph. Thanks for the explanation... I was expecting to see a loop on L1DcacheMemory like before and I missed the one on system.ruby.network. In the short run, I think the easiest way to break the cycle is to have the network take the RubySystem object as a parameter instead of the other way around, then add a registerNetwork() callback on RubySystem to let the network give the system its pointer. In the long run, looking around a bit, it's not clear that RubySystem really needs the network pointer... it's just used for a few things like resetting stats and printing configs that should be subsumed by equivalent m5 mechanisms (if they're not already), and to provide a global pointer via RubySystem::getNetwork() that a few other objects use to extract global network characteristics (like virtual channel count) that should probably be handled by providing those characteristics directly to those objects. That's a bigger change though that I'm guessing you don't want to tackle right now. Finally, it occurs to me that we avoid these issues to some extent in the classic m5 memory hierarchy by using ports rather than parameters to set up inter-object connections; maybe we should consider extending or adapting that model to Ruby someday. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
