Guoqiang,
STATIF_AF and DYNAMIC_AF are directly from Wattch, and I did not do
anything special with these when I integrated it with Opal. I vaguely
remember the distinction being static vs. dynamic power. I haven't
looked/used the power code in a long time, but I believe I always ran with
DYNAMIC_AF.
The best way to debug segfaults is to hook up gdb to the running
process, or run with gdb from the beginning of the simulation, after
calling opal0.init() and ruby0.init() (e.g. after symbols are loaded).
Luke
On Fri, 18 Apr 2008, Guoqiang Yang wrote:
Hi Serkan Ozdemir,
Thanks for the reply, but I have commented out that line. So the zeros
have nothing to do with the clear of access counter. I suspect it is all
about the way that I generate the power consumption for that specific unit.
Yep, I met the same problem and I think it is the code problem. And you
have to debug it yourself, now I have changed the code kind of a mess, I
can NOT find exactly which part really solved this problem. But I kind
of remember it has something to do with the System static object
pointer, also, something to do with assertion.
I also hope I could get more discussion about whether I'm doing the
right thing or not. And the way that GEMS guys tread "STATIC_AF" and
"DYNAMIC_AF" for those "current_UNIT_NAME_power_cc3" is different, and I
would like someone to make this part a little bit more clear.
Many thanks,
Guoqiang Yang
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}