The log 97. Core state machine develops the idea of the 2 concurrent state machines but something is missing: the FSMs don't allow the core to request new code again. This log 20. Automated upload of overlays into program memory describes a mechanism where the code can request a reload of (new) instructions in program memory, but this is not implemented in the FSM.

The core has evolved since 2018 and the opcode mapping is a bit different, in particular the MOV and CALL opcodes have changed. However, the OVL opcode is still an alias for CALL (whatever) PC.

I have updated the FSM diagrams :

The source code is not updated though.

20200820 : I moved to the FSM one problem I had with the eXecute/Slice units, which is : how to cross the clock domains to send a correctly-timed pulse to the Imem block when writing to the program memory. The FSM can do it, but which ?

(at first) it seems the Instruction FSM is the best place to do it.

The core must be in IDLE state for this to work.

Had I chosen the other FSM, the STOP state would be reached through CLRPC & LOAD, which might be unwanted if one wants to selectively load instructions.

But the Inst FSM grows from 4 to 5 states, which can't fit in 2 bits...

Maybe I can engineer a way to go directly from RESET to STOP...

With a new arc from RESET to STOP that bypasses CLRPC and LOAD, it is now easy to send the WrImem pulse from the core's clock domain, AND the system FSM can be removed from the instruction FSM and still preserve the most fundamental properties.

The trick is simple : at P.O.R. the command register is loaded with "RUN", to get the core running, as it would if there was no system FSM. Then the TAP can take over and send other commands.

The command register could even be loaded on POR depending on the status of one TAP input pins (/WR for example ?) since the TAP pins should have pull-down resistors to prevent spurious behaviours.

The core FSM can still fit in 2 bits and the system FSM in 3 bits.