You know, after writing that all out, I think maybe it would be better to have a generic ClockWatcher interface where something (anything) could watch a clock source and be notified of period updates. The DerivedClockDomain would implement that interface, but then so could my CPU. That would avoid having an awkward sort ClockDomain but not really class which would be just to hijack the clock watching ability of the DerivedClockDomain.
I think that would also avoid having to rename anything, since even though the DerivedClockDomain makes some overly simplifying assumptions (clocks only go slower and in integer ratios), it wouldn't make any less sense if the update mechanism was changed. I'll go ahead and do things that way. Gabe On Wed, Aug 7, 2019 at 6:26 PM Gabe Black <[email protected]> wrote: > 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
