Hi Korey,
You're right, that does seem suspicious. However, I've looked into it and
it isn't correct. The squash is instigated from IEW and can be due to
several things - branch misprediction, memory blocking and memory order
violation. The PC field of the squash structure is only set on a branch
misprediction. DPRINTF is reading it in all cases, so it's getting a 0
when it's not valid. Really, DPRINTF shouldn't print this if it's not
valid, so I'll put in a patch to fix that too.
Digging around, I find that my problem instruction is actually squashed by
the ROB later on that cycle. Therefore, I'm wondering whether the fix
should actually be to prevent the freed register from being put on the
freelist and reused immediately the same cycle. That doesn't seem like it
would happen in a real system to me.
Cheers
Tim
On Wed, 04 Aug 2010 23:36:25 -0400, Korey Sewell <[email protected]> wrote:
I havent brushed up on the O3CPU code in awhile but why the 1st thing
that
seems suspicious is "Squashing from PC 0"... How is that happening? Is a
branch at "PC 0" really committing?
On Wed, Aug 4, 2010 at 4:45 PM, Timothy M Jones
<[email protected]>wrote:
Hi folks,
I'm getting a problem when simulating a 2-way SMT on O3CPU and was
wondering if someone can point me to the place that I can go to fix
this.
Here's a severely shortened version of the trace output to show the
problem:
13219941500: system.detail_cpu.commit: [tid:0]: Squashing due to PC 0
[sn:26128044]
...
13219942000: system.detail_cpu.rename: [tid:0]: Removing history entry
with
sequence number 26128107.
13219942000: global: Rename Map: Integer register 32 being set to 58.
13219942000: cpu.freelist: Freeing register 104.
...
13219942000: system.detail_cpu.rename: [tid:1]: Processing instruction
[sn:26128120] with PC 0x10001e5c.
13219942000: global: Renamed reg 10 to physical reg 104 old mapping was
71
13219942000: system.detail_cpu.rename: [tid:1]: Renaming arch reg 10 to
physical reg 104.
...
13219942000: system.detail_cpu.iew: Execute: Processing PC 0x100400c4,
[tid:0] [sn:26128107].
13219942000: global: RegFile: Setting int register 104 to 0x22000428
Basically, commit starts a squash for thread 0. Instruction 26128107
gets
squashed in the rename stage and releases physical register 104. This
gets
mapped in the same cycle to instruction 26128120 from thread 1.
However,
thread 0's instruction still executes and writes to register 104,
meaning
thread 1 gets corrupted data.
The problem is that no-one sets the first instruction's squashed flag.
Can
someone tell me where this should be done (by the rename stage?) and
I'll
write a fix for it.
Cheers
Tim
--
Timothy M. Jones
http://homepages.inf.ed.ac.uk/tjones1
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
--
Timothy M. Jones
http://homepages.inf.ed.ac.uk/tjones1
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
