Hi folks. I'm working on making a CPU model out of a black box CPU implementation which doesn't explicitly schedule each of its clock ticks (I assume it does that internally), but does respect a clock which I can adjust.
The existing clock domain mechanism lets a client call into it to see when the next clock edge is, for instance, but doesn't actively tell other entities when its clock rate has changed. In situations where the clock rate isn't polled (ie the one I'm working on), the clock rate could change without the CPU noticing. I see a mechanism in the clock domain classes which sort of already does this, where there can be a source clock and then derived clocks which are notified of input clock changes and can regenerate their output clock rate. Unfortunately, the DerivedClockDomain class assumes that all derived clocks are based on scaling with a simple divider/multiplier (probably mostly true), and doesn't give any way to hook into the clock update propagation mechanism otherwise. What I would like to do is to make the updateClockPeriod function in DerivedClockDomain virtual, and then move the dividing logic into a new, derived (in the C++ sense) class called, perhaps, ScaledClockDomain. Then I could create my own clock domain class who's only purpose would be to let my opaque CPU model know when the clock changes. Since this would change the names of the type of objects in configs, I figured I'd throw out an email letting people know before attempting this change. This would also make a normal method virtual which would add a slight performance penalty when calling it, but since updating frequency/clocking domains probably doesn't happen that often relatively speaking and the overhead would be very small, that seems like a reasonable trade off. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
