Hi,
Mark pointed me to 2 patches, which I think have been included in newer
versions of gem5 (I am running an older version), with which the issue of
skidbuffer has been resolved:
http://www.mail-archive.com/gem5-dev@gem5.org/msg03413.html
http://comments.gmane.org/gmane.comp.emulators.m5.devel/1
Hi Mark,
Thanks again for the quick response, really appreciate it. Did you happen
to hit the error of skid buffer size exceeding the max limit, as below:
panic: Skidbuffer Exceeded Max Size
@ cycle 2666580
[skidInsert:build/X86/cpu/o3/rename_impl.hh, line 791]
Memory Usage: 1054688 KBytes
Progr
I believe that all the delays commented out are related to paths not
actually used by any instructions, but they have parameters just defined in
the code "just in case". Perhaps someone with more intricate knowledge of
the O3 CPU model can confirm? (Or I could, you know, read the code)
For a total
Thanks a lot Mark for the super quick response. So I tried out the
suggested changes and my benchmark seems to be running fine. However, have
a couple of questions.
- quite a few of the delay parameters seem to be commented out. Dont we
have to set them as well ?
- The width parameters are indepen
I just did this a few days ago.
Below is a snippet of my config script (you don't even need to recompile!)
Not sure about the commented out forwarding paths. You might have been
getting assert failures if you didn't increase the forwardComSize
and backComSize, which are the size of the "buffers"
Hi,
I want to model deeper pipeline in X86 simulation, around 20-31 stages. The
ISCA tutorial slide mentioned that this could be achieved by adding varying
amounts of delay in between the existing 7 stages in O3CPU.py. However,
when I add some delays, the simulation aborts due to assert failure. H
