NIOS II Custom Instruction access to CPU Regs'

The interrupt routine is slow because most of the time the code itself doesn't come out of the instruction cache. And if it is, it is for sure not worst case timing.

Storing and recovering the registers is also slow. Bit can be faster if data cache is available, and because generally interrupts are small and use small data sets, the register contents will still be in the datacache. Do not think internal RAM is a solution for everything. I did some small benchmarks, and it seems to take 3 or more cycles to read a value, around 2 to store one. SO it is not single cycle (if I'm wrong, please let me know).

Also to keep in mind : if interupts are not reenabled, only the first interrupt that comes in will be handled fast. The priority mechanisme is not working in this case (at least not for worst case timing).

So some tips :

1. Do assembler (also for calculating the offset in the function table and to call the function).

2. Figure out when it is possible to reenable interrupts. It takes some time to reenable and disable, but it can save a lot on worst case latency.

3. Use an inner loop (in between register sving and recovering) to do lower priority interrupts that became active when the higher priority interrupt was handled. (So less overhead for saving and restoring, but still the chance for high priority interrupts to come in).

4. Be carefull whith the fast core and data cache. See what can eb cahched or not. Also there seems to be a strange issue when reenabling interrupts and using the fast core. If you ever see some strange effects that go away when the data cache is disabled, let me know, then I know I'm not the only one with this issue, and maybe altera will listen then.

Stefaan.