As far as I can tell, the source of the instruction count problem either is restricted to FS (don't know if restricted to ARM), varies with environment setup or is caused by the cross-compiled binary file. I'm doubtful of the latter two since I've run with various benchmarks in gem5.fast to completion, and they have been within 10% of the committed instructions that the benchmarks have run on physical hardware (as measured with valgrind...same binary files).
At this point, it would be helpful to know if anyone else has run a benchmark with your patch on ARM_FS (or other arch) successfully. Luckily, you have made it very easy to test since it replaces the old DRAMMemory object. Otherwise, I'll continue debugging this and emailing the list with questions as I go. Is it possible for this assertion to only occur in ARM_FS, not ARM_SE, with the same benchmarks? I require full-system, so I haven't tested ARM_SE. If my benchmarks pass with ARM_SE in gem5.opt, that should narrow the source of the problem down. Thanks, Andrew On Tue, Mar 13, 2012 at 4:30 PM, Rio Xiangyu Dong <riosher...@gmail.com>wrote: > I use gem5.opt, and never see this error.**** > > ** ** > > *From:* gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] *On > Behalf Of *Andrew Cebulski > *Sent:* Tuesday, March 13, 2012 12:12 PM > > *To:* gem5 users mailing list > *Subject:* Re: [gem5-users] A Patch for DRAMsim2 Integration**** > > ** ** > > Did you ever get this error building gem5.debug on revision 8643? > > -----**** > > ** ** > > cc1plus: warnings being treated as errors > In file included from build/dramsim2/SystemConfiguration.h:42:0, > from build/dramsim2/MemorySystem.h:42, > from build/ARM_FS/mem/dram.hh:42, > from build/ARM_FS/mem/dram.cc:39: > build/dramsim2/PrintMacros.h:49:0: error: "DEBUG" redefined > <command-line>:0:0: note: this is the location of the previous definition > > ----- > > The DramSim2 repo has the same file: > https://github.com/dramninjasUMD/DRAMSim2/blob/master/PrintMacros.h **** > > > The solutions seems to be adding "#undef DEBUG" right before it gets > defined. I can't find where it's getting declared initially though... > Doing a grep of the gem5 src and ext repo's for a DEBUG define come up > empty. Commenting out all defines of DEBUG in PrintMacros.h still results > in the redefine message...**** > > ** ** > > I have two versions of gcc readily available (4.5.0 and 4.5.3), and I get > it on both.**** > > ** ** > > -Andrew**** > > On Tue, Mar 13, 2012 at 1:56 PM, Andrew Cebulski <af...@drexel.edu> wrote: > **** > > Hi Xiangyu,**** > > ** ** > > I just started looking into this some more. So at first I thought it > was due to updating to a more recent revision, but then I went back to > revision 8643, added your patch, built and ran....and now get the error > with it too (when running ARM_FS/gem5.opt). I"m testing now to see if an > update to SWIG might have resulted in this error, maybe someone on the > mailing list would know if that's possible. The difference is 1.3.40 vs. > 2.0.3, both of which are supported according to the dependencies wiki page. > **** > > ** ** > > Just for completeness, here's the error from revision 8643:**** > > build/ARM_FS/cpu/base_dyn_inst_impl.hh:149: void > BaseDynInst<Impl>::initVars() [with Impl = O3CPUImpl]: Assertion > `cpu->instcount <= 1500' failed. **** > > ** ** > > I also removed all the changes I've added for my research from the > test with revision 8643 and your patch, aside from adding a new rcS file > and the cross-compiled binary to the disk image for Libquantum (SPEC > CPU2006). Note that I use CodeSourcery for cross-compiling.**** > > ** ** > > I have not tried running with gem5.debug, so I will be doing that > today. Maybe this is an assertion that is occurring due to an > optimization. That would mean it wouldn't be triggered in gem5.debug since > it runs without optimizations. Have you tested all debug, opt and fast > with your tests?**** > > ** ** > > Thanks,**** > > Andrew**** > > ** ** > > On Tue, Mar 13, 2012 at 1:37 PM, Rio Xiangyu Dong <riosher...@gmail.com> > wrote:**** > > Hi Andrew,**** > > **** > > I didn’t see this error in my simulations. May I ask which gem5 version > you are using? I find some of the latest code updates do not comply with my > changes. I am still using the DRAMsim2 patch on Gem5 repo8643, and have run > all the runnable benchmarks in SPEC2006, SPEC2000, EEMBC2, and PARSEC2 on > ARM_SE.**** > > **** > > Thank you!**** > > **** > > Best,**** > > Xiangyu**** > > **** > > *From:* Andrew Cebulski [mailto:af...@drexel.edu] > *Sent:* Thursday, March 08, 2012 6:52 PM**** > > > *To:* gem5 users mailing list**** > > *Cc:* riosher...@gmail.com; sa...@umich.edu**** > > > *Subject:* Re: [gem5-users] A Patch for DRAMsim2 Integration**** > > **** > > Xiangyu,**** > > **** > > I've been having an issue recently with the number of instructions I've > been seeing committed to the CPU (I have a separate thread on this). It > turns out the issue seems to be coming from this patch you created to > integrate DramSim2 with Gem5. Unfortunately, I've been running with > gem5.fast, not gem5.opt. So up until now, I haven't been seeing > assertions. I thought I'd run it with gem5.opt or debug back in December, > but I must not have. My runs on the Arm O3 cpu fails with this assertion: > **** > > **** > > build/ARM/cpu/base_dyn_inst_impl.hh:149: void > BaseDynInst<Impl>::initVars() [with Impl = O3CPUImpl]: Assertion > `cpu->instcount <= 1500' failed.**** > > **** > > Have you seen similar results? Is this count how many instructions > are currently being processed by the cpu? My initial guess is that memory > instructions being sent to DramSim2 are getting counted as committed > regardless of whether they are mispredicted (and rerun). Any suggestions > on where to insert DPRINTFs, or use current ones, to find out if this is > what is happening?**** > > **** > > Ali helped me earlier with getting the checker and some debug flags to > track earlier. I currently have traces with debug flags Exec, ExecAsid and > DynInst. I just need to know what to search for in them for useful info.* > *** > > **** > > Thanks,**** > > Andrew **** > > **** > > On Sun, Dec 18, 2011 at 5:04 PM, Dong, Xiangyu <riosher...@gmail.com> > wrote:**** > > Thanks. Actually I only tested it on ARM_SE and ARM_FS. Let me know if > it also works for other processors.**** > > **** > > In addition, I actually made more modification on the DRAMsim2 side. > Maybe the most important one is that I changed the way how DRAMsim2 reports > latency/bandwidth statistics. DRAMsim2 reports all the statistics after > every EPOCH, and then resets all the numbers. For Gem5 users who are only > interested in the statistics over the entire simulation time, you might > want to change the codes in DRAMsim2/MemoryController.cpp and make similar > changes like what I’ve done (that’s NOT in the patch since it’s more > DRAMsim2-related).**** > > **** > > Best,**** > > Xiangyu**** > > **** > > *From:* gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] *On > Behalf Of *Andrew Cebulski > *Sent:* Sunday, December 18, 2011 6:38 AM > *To:* gem5-users@gem5.org > *Subject:* Re: [gem5-users] A Patch for DRAMsim2 Integration**** > > **** > > Thanks for the integration patch Xiangyu! I'll let you know if I come > across any bugs.**** > > **** > > -Andrew**** > > **** > > **** > > Date: Sun, 18 Dec 2011 01:48:58 -0800 > From: "Dong, Xiangyu" <riosher...@gmail.com> > To: "gem5 users mailing list" <gem5-users@gem5.org> > Subject: [gem5-users] A Patch for DRAMsim2 Integration > Message-ID: <001201ccbd6a$45102210$cf306630$@gmail.com> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > > I have a Gem5+DRAMsim2 patch. I've tested it under both SE and FS modes. > I'm willing to share it here. > > > > For those who have such needs, please go to my website > www.cse.psu.edu/~xydong <http://www.cse.psu.edu/%7Exydong> to download > the patch and test it. To enable > DRAMSim2, use se_dramsim2.py script instead of se.py (for FS, you can > create > by yourself). The basic idea to enable the DRAMsim2 module is to use the > derived DRAMMemory class instead of PhysicalMemory class. > > > > Please let me know if there are bugs. > > > > Thank you! > > > > Best, > > Xiangyu Dong > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://m5sim.org/cgi-bin/mailman/private/gem5-users/attachments/20111218/f3fdf5da/attachment.html > >**** > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users**** > > **** > > ** ** > > ** ** > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
