Hi Andrew,
I only used ARM_SE in my daily research work, and they all work fine. It now seems that ARM_FS is the source of error. Your debug trace would be very helpful and I will look into this issue when I have time to do it. Thank you! Best, Xiangyu From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] On Behalf Of Andrew Cebulski Sent: Tuesday, March 13, 2012 9:42 PM To: gem5 users mailing list Subject: Re: [gem5-users] A Patch for DRAMsim2 Integration Here's a summary from running with the printfs showing the reads, writes and receive timings reported by dram.cc for libquantum: reads, writes, receive timings ARM_FS 1486578, 115473, 1605225 ARM_SE 347210, 3002, 350213 FS/SE 4.28, 38.47, 4.58 -Andrew On Tue, Mar 13, 2012 at 11:33 PM, Andrew Cebulski <af...@drexel.edu> wrote: I figured out how to run my benchmark in ARM_SE. First, I had to recompile my benchmark statically linked, since I run it dynamically linked in ARM_FS. I was able to run the statically linked libquantum in ARM_SE with gem5.opt without any errors, the same as your tests. I did look at the committed instruction count within the stats file for the ARM_SE run with the O3 CPU, and it does look accurate. Next, I added this new statically linked libquantum to my disk image to run in ARM_FS with gem5.opt. It failed with the same exact instcount error in base_dyn_inst_impl.hh as with my dynamically linked libquantum benchmark. So it would seem that the problem only occurs in FS, not SE. Now the question is how to go about fixing the issue preventing your integration of DramSim2 from working in ARM_FS... Any ideas? It looks like you have some debugging coded into your dram.cc, but commented out (printf statements). I'll add them back and compare their outputs between ARM_SE and ARM_FS. I might convert them to DPRINTFs too. Do you know how to setup one of your ARM_SE benchmarks to run in ARM_FS? It basically involves putting it into the Gem5 Ubuntu image (i.e. using util/gem5img.py), creating a rcS file, and adding it in Benchmarks.py. This way you can try to reproduce the error in your environment. That would be a good start. -Andrew On Tue, Mar 13, 2012 at 6:08 PM, Andrew Cebulski <af...@drexel.edu> wrote: 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/f3 fdf5da/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
