Discussion:
[gem5-users] Discussion About Interfacing with McPAT
Yi Shen
2018-07-20 16:04:29 UTC
Permalink
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
Andreas Brokalakis
2018-07-23 13:58:54 UTC
Permalink
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
Post by Yi Shen
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Loading...