Thanks for your reply, Avadh! Based on my knowledge to the source code, the checker will be executed through the execute_checker() call in commit stage and it seems to me the execution of the checker is in the critical path of PTLsim simulation. However, as you had mentioned that the checker is run "in parallel" to simulated CPU Context, does this mean that the checker runs in a separate thread which parallel the PTLsim execution? If so, where does MARSS create the checker threads?
Thanks again for your kindness! Teng-Feng 2010/12/28 avadh patel <[email protected]> > On Mon, Dec 27, 2010 at 4:10 AM, Teng-Feng Yang <[email protected]>wrote: > >> Hi~ >> >> What is the purpose of the checker called by the commit stage in >> ooopipe.cpp? >> It seems that it switches back to the QEMU and functionally simulate the >> checker_context, but I don't understand what to check via this checker. >> >> Checker is a CPU Context that is run in parallel to simulated CPU Context > and after every instruction commit they both are compared for simulator's > correctness. This checker context is run in QEMU and it runs only in User > mode simulation. I use this checker to find bugs in simulator CPU model > that breaks the simulation correctness and crash the simulator. Though > checker doesn't run all the time so it not useful to find bugs in Kernel > mode. > > This happens only when '-enable-checker' option is set. > > >> Here is another question. >> It seems to me that during the simulation process of marss, it is ok to >> switch between functional simulation (QEMU) and detail simulation (PTLsim) >> only if we manage to provide the right context and call setup_xxx_switch >> between them. >> Is this correct? >> >> Yes. One more thing to add here, you have to make sure that simulator > model is not in partial commit mode. For example, if its simulating x86 > instruction that has 4 uops and in cycle-1 2 uops are committed then you > can't change to QEMU mode untill rest of the uops in that instruction are > committed. If you look at the code you might find a variable > 'handle_interrupt_at_next_eom' which indicates that after next x86 > instruction commit there is an interrupt pending so don't start committing > other instruction because we might switch to QEMU mode. > > - Avadh > >> Any help would be grateful! >> >> Thanks again for the great simulator >> >> Teng-Feng >> >> >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> > -- Teng Feng Yang Research Assistant of Director. P.C. Yew Parallel Processing Laboratory Institute of Information Science Academia Sinica, Taiwan Tel: 886-2-27883799#1676 E-mail:[email protected] <e-mail%[email protected]>
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
