On Mon, Apr 30, 2012 at 7:31 PM, R. Diez <[email protected]> wrote: > 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 can confirm that I see the incorrect PC value ending up in the EPCR register. It's 4 greater than it should be. This is a bug. > > 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. You will need to clear the OV flag in the value in the ESR before you do the l.rfe or it will keep triggering the overflow exception. The address we jump to on l.rfe should be one in the EPCR. It should not be returning to any other address. > > 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? Sorry, wasn't a quick hint. Good work mate, cheers. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
