> Sounds like the long term solution in this type of situation would be to > pass the latency as a time to the component, and have it derive cycle > counts in the C++ code based on that fixed latency and the current > frequency of the component. I agree. To me, the right solution is to bind the proxy even later. Don't bind it in Python, but rather in C++ so that we can re-bind it in the future. Essentially a clocked object has a period parameter and a parent pointer. If the parent is NULL (no parent), then the concrete period is an absolute period in ticks. If the parent is non-null, then the concrete period is the period parameter multiplied by the parent ticks. If ClockedObjects also had a list of children, then we could traverse the tree of clocked objects any time a clock period was changed and thus be able to deal with DVFS (and the general notion of clock domains) more easily.
> This works, though it's pretty funky in that the clock.period is stored as > a float to represent seconds rather than ticks. It looks like the clock > parameter value doesn't resolve the period ticks until the simulation binds > the tick conversion before instantiating components? Correct. That's because we don't fix the value of a Tick. By convention, it's always been 1 tick == 1 ps, but that can (in theory) easily be changed. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
