I don't agree. There's no reason to force everything in a system to be based off of one clock.
Gabe On 03/31/12 00:10, Andreas Hansson 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
