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
