Flags, PC, IO ports and interrupts

A project log for YGREC8

A byte-wide stripped-down version of the YGREC16 architecture

Yann Guidon / YGDESYann Guidon / YGDES 02/15/2018 at 04:120 Comments

Interrupt handling should be seriously considered because we'll need them one day or another. This means that the complete state of the core must be saved and restored by suitable hardware and software.

Overall, this means that the very first IO port addresses are reserved for core functions. There are 4 registers that can be written from the core's internal state, as provided by the entity's ports (PC+1, A1, A2 and flags are available outside of the datapath because they are required for the debug system). So far the map is :

Saving A1 and A2 directly with dedicated hardware saves one or two cycles of latency and some precious bytes) when servicing IRQs but can also make the core harder to route... So they might be simple registers (which saves a MUX as well as the required wires). Or they can be "shadow" registers, written everytime the corresponding A register is being written (but the value goes through the RESULT bus, while the OUT bus is connected to DST, so it's awkward and would increase the overall electrical activity of the circuit, which is less good for power draw).

One nice side-effect is : this avoids creating an opcode for RTI (ReTurn from Interrupt) because it is detected by the following conditions : OPCODE=OUT (5 bits), IMM8=0 (8 bits), and DST[0]=1 (1 bit). 14 bits are easy to check in the pipeline.

The other nice aspect is that this mechanism is entirely optional : it can be disabled/removed if IRQs are not supported by the core.