Hi Yi Shen, there are a few things to consider here. First, gem5 and McPAT work on different levels. gem5 does not include and circuit information nor anything else beyond architectural stuff. On the other hand McPAT requires information that gem5 is simply not in a position to provide. That is why you have basic templates. They are used to provide the information that is missing from gem5 and that there is no point in leaving at "default value". For example, what is considered the default value of the implementation technology of a chip? What is the default value of the process? What is the default value of an implementation style? These are things that you consider when using a template. If you are trying to model an embedded low-power processor, it is different than a high performance part.
Apparently, if certain "default" values work for you, then it is ok. If you want to avoid templates, then you can use certain inputs (e.g. when calling your conversion program, a user can specify this kind of information). Furthermore, you should consider that certain parts of information may not be applicable. For example, when we were writing such a conversion tool, one of the struggles was to make sure that the default assumptions of both tools were a match. gem5 may assume a certain structure of memory hierarchy that McPAT may not (example: minimum size of a cache or even the presence of a cache) and also gem5 may or may not report certain values depending on the simulation type. So if you leave default values without having a template to specify certain things and force them on your own, things may break and the value of the final results will be questionable. Best, Andreas On Fri, Jul 20, 2018 at 7:04 PM, Yi Shen <yi.sh...@mail.mcgill.ca> wrote: > Hi all, > > > > I am thinking about writing a inclusive template that could effectively > translate gem5 output to McPAT input. The idea is simple. This template > includes all McPAT inputs and how to get them from gem5 outputs > (config.json & stats.txt) as well as the xml structure. And every CPU core > is treated as heterogeneous. For one gem5 simulation, the gem5 output may > not contain all inputs to McPAT. And a good parser would be able to parse > all available gem5 outputs to McPAT and leave the missing pieces default. > > > > But since everyone is working with templates, I am suspicious if this idea > legit. Is there any caveat prevents people from implementing such an > one-for-all template? What would be foreseeable difficulties apart from the > sheer labor? > > > > By the way, I am not sure if I should send this email to gem5-dev. This > email seems very different from other stuffs there. > > > > Thank you, > > Yi Shen > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
