Oh, never mind! I'd misunderstood the difference between members and children in the clock code. I think things are fine as is! I guess I'm still not all the way back from my trip :-).
Gabe On Wed, Aug 7, 2019 at 6:33 PM Gabe Black <[email protected]> wrote: > 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
