I think both symmetric and asymmetric systems need to be configurable. The latter is going to become more and more common in the future.
Thanks, Ali Sent from my ARM powered mobile device On May 30, 2012, at 3:42 PM, Gabriel Michael Black <[email protected]> wrote: > I'd like to see things still architected primarily around Cores (which is a > better name, I think) than CPUs and for CPUs to be a configuration > convenience primarily used at the python level. We don't want to force people > into having CPUs set up in a particular way or with particular components by > baking certain flavors of them into the rest of the simulator, but the idea > in general seems pretty reasonable. Or in other words, I'd like to see this > make things easier for the 90% who have normal looking CPUs while not making > things any harder for the 10% who have some wacky scratch pad memory or an > asymmetric cache hierarchy or an L2 on the CPU or whatever. > > Gabe > > Quoting nathan binkert <[email protected]>: > >> I like the idea. Can we rename BaseCache to Cache while we're at it? >> I'm not going to volunteer, but the best way to make this work IMHO is >> to write a script that does the searching/replacing and make that one >> patch on its own. Then create another patch that fixes up any >> mistakes. This serves two purposes. First, you can just drop the old >> patch and regenerate it whenever you update your script, and second, >> all we need to do is review your script and the second patch. We've >> done this sort of thing many times in the past and to be honest, it's >> not that hard. The hardest part is dealing with the fact that scripts >> and stat names end up getting affected. >> >> Nate >> >>> I am sure there are lots of ideas and opinions about the modelling of a >>> core vs CPU vs cluster, and I am keen to know how people feel about doing >>> some major re-naming and introduce some new levels of hierarchy in the >>> world of gem5 models. >>> >>> For a number of reasons (e.g. performance-monitoring, power modelling, >>> trace playback, etc) the current gem5 notation of a CPU is a bit >>> misleading, as it is actually only a core. Additionally, the separation of >>> core and caches complicates modelling of aspects that span the entire CPU >>> (core + caches), for example for the performance-monitoring. There have >>> also been examples in the past on the user and dev list of questions like >>> "how do it get a pointer to my L1", for very similar reasons. >>> >>> I am sure there are more reasons than I have listed here, and I would like >>> to propose a transition to a more well-defined hierarchy of core(s), CPU(s) >>> and clusters. A starting point would be to rename CPU -> core throughout >>> the codebase. After that we could introduce a SimObject CPU that would >>> include core(s) and L1(s), and also have getters for the latter. The next >>> level again would be a cluster, containing CPU(s) and caches. >>> >>> This change also needs to be coupled with updates to how cores are >>> enumerated, numbered, initialised, modelling of power states, etc. >>> >>> Ideas, feedback, and volunteers are appreciated :-) >>> >>> Andreas >>> >>> >>> -- 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 >> > > > _______________________________________________ > 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
