Hi guys, Thanks for the feedback.
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. Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of nathan binkert Sent: 14 September 2012 16:31 To: gem5 Developer List Subject: Re: [gem5-dev] Deferred Python parameter resolution for CPU clock > The idea with Parent is that you would go into the icache and dcache, and > in each of those say: > > self.clock = Parent.clock > > which would set their clock parameters to a proxy object that will wait > until instantiation, then search up the hierarchy for the nearest enclosing > object's clock value. Andreas, I believe that I also sent you code that would turn '2c' into 2 * Parent.clock. Furthermore, I brought this up a month ago: > 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. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
