Although something here still needs to be virtual... Gabe
On Wed, Aug 7, 2019 at 6:49 PM Gabe Black <[email protected]> wrote: > 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
