I just forwarded a proposal that I made a couple of years ago about this. The gist is. ClockedObject derives from SimObject. ClockedObject has a Clock parameter that derives from Parent.any. ClockedObject also has a phase so you can have an offset from the main clock. ClockedObject has some helper functions for calculating the next clock edge and for scheduling clocks in the future (instead of ticks.)
Nate On Sat, Mar 31, 2012 at 12:10 AM, Andreas Hansson <[email protected]> wrote: > Hi Brad (and everyone), > > I think the SimObjects should definitely not have a clock, instead I suggest > we focus the efforts on the MemObjects. > > My idea is the following: > > 1) Make a clock a SimObject and a potential parameter for MemObjects and Ports > > 2) Starting from the lowest level, each port should have the ability to have > a clock (a clock domain crossing is just a module with two ports with > different clocks), but could also use the Parent.any proxy to get the clock > of its MemObject. We could add a check at port binding time that two > neighbours always have the same clock. > > 3) Since the System is a MemObject as well, it could have a default clock > that will now be used everywhere thanks to the Parent.any in all other > MemObjects. > > By making the clocks SimObjects it is also easier to "get" them inside the > simulation and poke around with their settings, e.g. for DVFS. I'd really > like to see this happening within the next few months so let me know if this > proposal sounds good or if there are things you would like to do differently. > > Andreas > _______________________________________ > From: [email protected] [[email protected]] On Behalf Of > Beckmann, Brad [[email protected]] > Sent: Friday, March 30, 2012 11:51 PM > To: gem5 Developer List ([email protected]) > Cc: Thottethodi, Mithuna > Subject: [gem5-dev] Clock Defaults > > Hi All, > > Mithuna Thottethodi recently pointed out that our current methodology for > setting clock defaults is inconsistent and some of the values are > unreasonable. For instance, CPUs set their default clock value > (gem5/src/cpu/BaseCPU.py) to be the same as the global simulation clock, > which is 1 THz (gem5/src/python/m5/ticks.py). Meanwhile, Ruby sets it's > default value to be 1 GHz (src/mem/ruby/system/RubySystem.py). Therefore, > unless your config file overrides these defaults, the CPUs will > unrealistically run at a THz will Ruby drags along running three orders of > magnitude slower (due to instruction fetches, I understand in practice it > isn't quite that bad). It seems unreasonable and confusing for any CPU to be > setting its frequency at 1 THz. However, I'm not sure if setting any clock > defaults in the SimObject .py files is the best idea since it is prone to > user ignorance. > > The idea we are proposing is to not set any clock defaults in the SimObject > .py files and force the configuration scripts to set these values > appropriately. We think this would also be amendable to later on adding a > clock domain feature in gem5 where collections of sim objects can be assigned > to separate domains and support features like DVFS. Would anyone be opposed > to such a change? If not, we can submit a patch for review that accomplishes > the first step (removes Sim Object .py clock defaults) and start working on > the second part. > > Thanks and please let us know what you think, > > Brad > > _______________________________________________ > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
