Hi all:
I'm having fun once again while running my modified test suite against
the CPU bundled with ORPSoC V2.
I'm testing the range exception with this pseudo-instruction:
l.add, 0x40000000, 0x40000000
That translates to the following instruction:
3080: e0 85 30 00 l.add r4, r5, r6
Given the values in the R5 and R6 at that point in time, the instruction
sets the overflow flag, and, because the SPR_SR_OVE flag is also set, it
generates a range exception.
I added an l.nop trace inside the corresponding exception handler, and
or1ksim sets SPR_EPCR_BASE correctly with the address of the offending
instruction (3080). However, the Icarus Verilog simulation of the or1200
core bundled with ORPSoC V2 sets SPR_EPCR_BASE to the next address
(3084). That's not right, is it?
Anyway, the exception handler patches the offending exception, replacing
it with an "l.nop 0", and or1ksim continues the test suite execution
without problems with instruction l.rfe (Return From Exception).
However, the ORPSoC simulation does not, it enters an infinite range
exception loop at that address (3084).
I wonder what I'm doing wrong. I hope instruction l.rfe works properly
in the or1200 CPU. I wonder whether the overflow flag has remained set
and is triggering another exception immediately. Or maybe the
instruction patching is not working correctly, but even if it didn't, as
the address is wrong, it should carry on at the next instruction after
l.add. Or maybe l.rfe is compensating by decrementing the address before
carrying on execution, and is trying l.add again. I thought the
instruction cache might be intefering, so I disabled it, to no avail. I
also added code to also replace the instruction before and after l.add
with l.nop too, and that didn't work either.
So it looks like I need to keep looking, but before I invest more time,
can anybody give me a quick hint on this subject?
Thanks,
rdiez
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
