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 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
