Open sporniket opened 8 months ago
The micro sequencer will be designed as the collaboration of several actors in a looping chain :
uCounter
, that will emit the next value of program counter ; uCounter
may be told to either increment the counter, or to change (jump) for a given value. uCounter
MAY supports subroutine, i.e. a jump where the normally incremented value is stored into a local memory before changing to the new value ; then the uCounter
WILL receive a return kind of signal to recall the stored value and use it. uProgram
is just an adressable memory of the appropriate word width and size to contains the program of the sequencer. Each word is an instruction, the address to fetch is given by uCounter
.uDecoder
receive a word from uProgram
and update the output of the sequencer.uSynchronizer
receive flow control data from uDecoder
, maintains some internal state, and receive feedbacks from the controlled system, and emits instruction to uCounter
to fetch the next instruction. uSynchronizer
MAY wait for a feedback specified by flow control data before sending instruction to uCounter
Thus the chain of collaboration is : uCounter
⇒ uProgram
⇒ uDecoder
⇒ uSynchronizer
⇒ uCounter
⇒ ...
In order to boot the chain of collaboration, there will be a Start Unit : uStart
will wait a little time at power on reset, then tell uProgram
to fetch the first instruction (uCounter
starts at 0), initiating the chain.
The chain MAY be stuck when uSynchronizer
is waiting for a given feedback before sending instruction to uCounter
and that feedbacks is late. A Watchdog Unit, uWatcher
will monitor uSynchronizer
at the sign of uDecoder
. If uSynchronizer
is taking too much time, uWatcher
interrupt it and instruct uCounter
to jump to an error routine. The error routine MAY be changed by the decoder following a specific instruction.
The nominal chain of collaboration is : uCounter ⇒ uProgram ⇒ uDecoder ⇒ uSynchronizer ⇒ uCounter ⇒ ...
Meaning that two micro-instructions are at least 4 cycles apart.
When there is no branching, the counter could already be incremented, and the program unit could then already output the next micro-instruction, so that the decoder can consume it any time.
The happy case would then be :
Clock | This micro-instruction | Next micro-instruction |
---|---|---|
0 | uCounter→uProgram | |
1 | uProgram→uDecoder | uCounter++→uCounter |
2 | uDecoder→uSynchronizer | uCounter→uProgram |
3 | uSynchronizer→uCounter | uProgram→uDecoder |
4 | — | uDecoder→uSynchronizer |
Meaning that two micro instructions may be only 2 cycles aparts when there is no branching.
The uCounter may always update to the next value (uCounter + 1) after the cycle where it notify uProgram to latch the value.
Then one cycle later, it notifies uProgram to fetch the next micro-instruction.
Then it is up to uDecoder to assess whether there is branching (conditionnal or unconditionnal) or waiting (requires uSynchronizer). When there is no branching nor waiting, uDecoder MUST notify uProgram that it is ready.
The flow becomes more complex. (to come)
Overview
A micro sequencer is a programmable unit that outputs a set of signals by following a program. As such, it implements an execution loop that involves :
in pseudo code :