Short summary of all special cases in the CPU:

1) RAM read is not allowed after RAM write, it will always read the data
from the previous write address

2) RAM read address is ONLY prf[15]. RAM addresses are BYTE addresses. It
is possible to read in 8/16/32 bit mode, but writing is always 32 bit.

3) After modifying prf[15] (ALU instruction or LRC/SRC), the next RAM read
will still use the old value of prf[15]

4) RAM or Local IO read data can be only PRF

5) MUL, MUL32, MUS, MUS32 need 2 clocks, the target for 31..0 bits can be
only PRF[0]..PRF[7], the target for the bits 63..32 is prf[13] (MUL/MUS).
If the next instruction writes to some other PRF this is OK. If the target
for bits 31..0 is the same as the target of the next instruction, the OR
of both input data will be stored. If the instruction is MUL/MUS and the
target of the next instruction is prf[13], then the division high word
will be stored in prf[13] (has higher priority).

6) DIV needs 18 (?) clocks. Use the division busy flag (d) and conditional
jumps on it.

7) Access to the global IO. Writing is simple, but you have to check
before if the previous transaction initiated by the same CPU is finished
(bus flag). Reading is more complicated - the LGA/LGI/LGC make a request
to read from some location and select one of the two destination register.
When the bus flag is cleared, the result can be read through the local IO
(0x300 or 0x301). LRC uses prf[14] as address. To conventions is to
use the reg0 (0x300) in normal programs and reg1 (0x301) in IRQ routines.

8) Kreg is a way to extend the range of immediate data in the
instructions. With IEXT 17-bits [28:12] will be temporary stored and sign
extended. Until the next IEXT, SGI, MVI, CPI instruction this temporary
K-register will be not changed. The first following SGI, MVI, CPI
instruction will use the K-register to extend the 12-bit immediate data to
32 bit and will clear the K-register! So, if you need only 12-bit data,
you don't need to initialize the Kreg with 0. Be aware when using
interrupts!

9) Have a fun with our (C)RISC CPU core!

-- last modified: 11:46 / 08 Apr 2003 / V.Angelov