Hi again,

Sorry, I misunderstood your initial question. So, if you want to take a
checkpoint without draining the O3 pipe, then you need to get the
architectural state (committed information). Context 0 is ok for
single-core simulation. It seems that readIntReg reads the physical
registers, so be sure to get the already committed ones. It may also
increment the reg file stats.

Regards,

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France


2016-02-23 17:56 GMT+01:00 Felipe Rocha da Rosa <[email protected]
>:

> 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 <http://www.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 you
> Rizwana
>
> 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 Chong
> Boston 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 <http://www.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 Chong
> Boston 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 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
>
> _______________________________________________
> 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

Reply via email to