> Steve: Would you suggest that I do this in the BaseCache? Clock = > Parent.clock? That would make the iocache use the system clock (which isn't > necessarily a bad thing). > > Nate: The 2c is a tricky one. I have indeed got your patch, the issue is that > it looks at the clock period at that very time. For all the DVFS work that is > in the pipeline it is crucial to turn 2 * Parent.clock into a relative clock > that is evaluated at run-time rather than design time. As such, the 2c patch > has a very short lifetime. > > Our proposed solution to the DVFS issue is to turn the clock parameter in to > a SimObject instead of a scalar. That way many other objects can point to the > same clock and dynamically determine (or rather update) the clock period when > needed.
I don't see the extra SimObject buying you much (though it's not a big deal to have either) assuming that you still want to support multiples of the clock (Do you? It sure seems necessary to me). If you want multiples, then you still need to use the proxy code or something like it. You'd also likely want to be able to do things like Parent.clock still. My proposal was that we essentially allow the clock to either be a scalar, or another ClockedObject (by doing a bit of hacking on the proxy code). On the C++ side, every ClockedObject would have its own scalar clock, but if we used the proxy code on the python side, then we'd store the pointer and the multiple on the C++ side. Then we could propagate clock changes (with the multiples) around the system whenever they happened. I guess you could put all of the code for multiples and stuff like that into the SimObject with the parameters, but that seems awfully verbose. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
