[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[openrisc] Another issue...



If a branch or jump is executed in the delay slot
ofanother instruction, the address calculation is wrong.

We must either make these instructions illegal, and
throw an exception if they are encountered, (and
turn them into NOP's) or else we must make sure the
address calculation is done properly.

It occurs to me that the real problem is the
architectural simulator is executing in series,
whereas the real RTL code will execute both units
in parallel.

So, in order to fix this problem, I have rewritten
the address calculation schemes wherever I can find
them. Updating of the PC is now delayed until after
the execution stage, and all address calculation
schemes have had the anomolous "-4" factor removed.

The other option was to change the pcnext
address calculation based on whether this was
executed in a delay slot or not. This seemed less
likely to be a real world solution in hardware.

Additionally, an extra register, pcdelay, has
been added. In the pc update routine, this
register is moved into the pcnext register
instead of adding 4. In this sense, the delay_insn
is acting a selector for a mux, deciding whether to
load PC+4 or the calculated effective address into
the pcnext pipeline.

This seems to fix this issue, and does not affect
the reset/exception issue raised previously.

Comments?

Chris
chris@asics.ws