Hi,To surpass this problem, I create my context saver functions by accessing
the C++ objects using this method to access one integer
register.getContext(0)->context->readIntReg(faultRegister)I`m assuming that if
I use only one core will be only the context 0 (zero), that`s correct?Also, I
suppose that the registers that I`m reading are the same on
/src/arch/arm/intregs.hh.
enum IntRegIndex{ /* All the unique register indices. */ INTREG_R0,
INTREG_R1, INTREG_R2, INTREG_R3, INTREG_R4, INTREG_R5,
INTREG_R6, INTREG_R7, INTREG_R8, INTREG_R9, INTREG_R10,
INTREG_R11, INTREG_R12, INTREG_R13, INTREG_SP = INTREG_R13,
INTREG_R14, INTREG_LR = INTREG_R14, INTREG_R15, INTREG_PC =
INTREG_R15,...
About the switch, I will work on that in the next days thank you for the
possible solution.
Thanks every one.
Best regards, Felipe Rocha da Rosa,PhD Student - PGMICRO - UFRGS,frdarosa.com
Date: Thu, 18 Feb 2016 18:01:53 +0100
From: [email protected]
To: [email protected]
Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error
Hello,
Maybe this workaround could work for you: simulate until the bench ends, switch
to the atomic CPU and take a checkpoint.
The switch from detailed to atomic works (my gem5 version: 11153:20bbfe5b2b86).
You'll probably need to modify configs/common/Simulation.py to do that.
Hope it helps and boa sorte,
--
Fernando A. Endo, Post-doc
INRIA Rennes-Bretagne Atlantique
France
2016-02-12 1:27 GMT+01:00 Felipe Rocha da Rosa <[email protected]>:
Hello,Thank you for replying. I saw a old email about that, but I didn't know
if was fixed or not.My idea is not fast forward the execution of a given
application. Instead, I will change slightly some parameters for each one. Then
comparing the two executions (using the OoOmodel) using the checkpoints
information at the end to capture the behavior though some scripts I have. I
don't want to restore this checkpoints only collect the data, like register
state, PC and mainly the memory dump. The checkpoint could be at any moment
during the simulation, and I'm just considering at the end of the execution to
simplify the question.
At the current moment, I'm trying to use the checkpoint without the drain
function and appears to work for my purposes. But I still wondering I it never
drains out. I change some parameters into the drain function without success.
Best regards, Felipe Rocha da Rosa
Date: Thu, 11 Feb 2016 08:34:37 -0500
From: [email protected]
To: [email protected]
Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error
Hello Felipe,
I am not sure if I understand your use case completely. I had similar problem
with creating checkpoints with detailed mode CPU right after boot. From the
discussion on the mailing list, IIRC checkpoint functionality is not tested for
ARM detailed CPU as part of Gem5 regression tests, so I think I can say that
it's not guaranteed to work. In my case, I just create checkpoint with atomic
boot and restore with detailed CPU.
I am curious, how does creating checkpoint at the end of application execution
helps?
Thank youRizwana
On Wednesday, February 10, 2016, Timothy Chong <[email protected]> wrote:
Hi,
For me personally, it took me a couple days before I realized that gem5 system
does not end whatsoever when there is a scheduled event. In other words, if you
keep on scheduling things, (calling schedule inside your wakeup function
without any condition), the system never ends.
Not sure if that’s your case.
Best,Timothy ChongBoston University
Le Feb 10, 2016 à 3:07 PM, Felipe Rocha da Rosa <[email protected]> a
écrit :
Hi,
Yes I`m adding a new module (but I schedule events by the number of
instructions using self.system.cpu[0].scheduleInstStop for exemple), however
this problem is occurring in the "clean" gem5 from the repository (stable or
not). The checkpoint never returns from the drain call.
Best regards,
Felipe Rocha da Rosa
Best regards, Felipe Rocha da Rosa,PhD Student - PGMICRO - UFRGS,frdarosa.com
From: [email protected]
Date: Wed, 10 Feb 2016 13:44:57 -0500
To: [email protected]
Subject: Re: [gem5-users] Checkpoint in detailed cpu causing error
Hi,
I had problems that sound very similar to your case just a couple days ago. Did
you happen to have to write a module yourself? or did you have to call «
schedule » inside your module in order to tick your own clock?
Thanks,Timothy ChongBoston University
Le Feb 10, 2016 à 1:31 PM, Felipe Rocha da Rosa <[email protected]> a
écrit :
Hi!
I'm trying to execute several slightly different executions of the same
application using the Detailed (DerivO3CPU) CPU mode and compare then. For the
purpose, my idea was executing the application and create a checkpoint at the
end. However, the checkpoint is never complete. I trace the cause to the drain
function in gem5-stable/src/python/m5/simulate.py, where the simulator is
called again and so remaining in the loop forever. My question is if I can
comment/change this line and do not perform the drain() without changing the
final results.
def drain(root): # Try to drain all objects. Draining might not be completed
unless # all objects return that they are drained on the first call. This
# is because as objects drain they may cause other objects to no # longer be
drained. def _drain(): all_drained = False dm =
internal.drain.createDrainManager() unready_objs = sum(obj.drain(dm) for
obj in root.descendants()) # If we've got some objects that can't drain
immediately, then simulate if unready_objs > 0:
dm.setCount(unready_objs) #WARNING: if a valid exit event occurs
while draining, it will not # get returned to the user script
exit_event = simulate() while exit_event.getCause() != 'Finished
drain': exit_event = simulate() else:
all_drained = True internal.drain.cleanupDrainManager(dm) return
all_drained
all_drained = _drain() while (not all_drained): all_drained =
_drain()
def checkpoint(dir): root = objects.Root.getInstance() if not
isinstance(root, objects.Root): raise TypeError, "Checkpoint must be
called on a root object." drain(root) memWriteback(root) print
"Writing checkpoint" internal.core.serializeAll(dir) resume(root)
Command:./build/ARM/gem5.opt ./configs/example/se.py -c queens -o 10
--cpu-type=detailed --caches --l1i_size=32kB --l1i_assoc=4 --l1d_size=32kB
--l1d_assoc=4 --l2_size=512kB --l2_assoc=8 --checkpoint-at-end
Thanks in advance!
Best regards, Felipe Rocha da
Rosa_______________________________________________gem5-users mailing
[email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list
[email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users_______________________________________________gem5-users
mailing
[email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
