On Fri, Mar 11, 2011 at 2:27 PM, Beckmann, Brad <[email protected]>wrote:
> > > 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. > > > > I think Steve's short-term solution is a good one. However I'm not sure if > Ruby always using ports would solve thr problem. The connections that Nilay > is trying to set up, a system-level list of all caches and memory objects, > are not real. It is completely fake. I'm not sure that ports really fit > that model. Instead, it seems like the crux of the problem is that we want > to set up this this list in C++ because it doesn't make sense to explicitly > set up these connections in the python file. I'm not sure if there is a > perfect solution. > That's not quite what I meant... I think the current solution for building the fake list of of caches is fine, and I don't mean we should use ports for that. However, it looks like part of the reason that we've induced a cycle is because the linkage from the network links to the cache controllers is also done via parameters. My point was that if we used ports rather than params to connect caches & controllers to the network, then this cycle would not have come up to begin with. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
