forked from Github_Repos/cvw
e73e16e57a
The extact problem occurs when a 4 byte instruction startles two cache blocks (or without a cache two ahbi words) and the code jumps to a cache block other than the next cache block. Consider the following sample of code. 0000000000000080 <test_spill>: 80: 42a9 li t0,10 82: 0001 nop 84: 0001 nop 86: 0001 nop 88: 02bd addi t0,t0,15 8a: 00628e33 add t3,t0,t1 8e: 01ce8963 beq t4,t3,a0 <match> 0000000000000092 <failure>: 92: 557d li a0,-1 94: 8082 ret 96: 00000013 nop 9a: 00000013 nop 9e: 0001 nop 00000000000000a0 <match>: a0: 1ffd addi t6,t6,-1 a2: fc0f9fe3 bnez t6,80 <test_spill> a6: 4501 li a0,0 a8: 8082 ret Instructions 0x88, 0x8a and 0x8e are read incorrectly. However once the branch predictor begins to correctly predict the beq at 0x8e the instrution at 0xa0 is loaded incorrectly as the 2 upper bytes of 0x8e and the two bytes of 0x92. This amalgamation causes c.addi at 0xa0 to do something else and the loop never terminates. The button of wavefile wave.do shows the exact problem in the 'icache'. |
||
|---|---|---|
| .. | ||
| wave-dos | ||
| regression-wally.py | ||
| sim-busybear | ||
| sim-busybear-batch | ||
| sim-wally | ||
| sim-wally-batch | ||
| sim-wally-rv32ic | ||
| wally-busybear-batch.do | ||
| wally-busybear.do | ||
| wally-coremark_bare.do | ||
| wally-coremark.do | ||
| wally-peripherals-signals.do | ||
| wally-peripherals.do | ||
| wally-pipelined-batch.do | ||
| wally-pipelined-ross.do | ||
| wally-pipelined.do | ||
| wally-privileged.do | ||
| wave-all.do | ||
| wave.do | ||