I'm starting to update and refine the architecture of the Y8, by making a separate unit, that will hopefully be more flexible.

Uusally, each unit will receive the required parts of the instruction word and decode the necessary signals. This is very easy with a clean RISC processor, which could be described as a "distributed decoding" architecture.

In practice, there are other constraints as well. 

• Structure and layout: the decoding gates often "break" the bitslice-like layout
• Management of fanout: some bits from the instruction word might need appropriate decoding and buffering with a global scope
• Sequencing and states: there has to be somewhere to store information about what the processor is doing, for example with the LDCx instructions and the computed writes to PC, which require more than one clock cycle.
• Power consumption reduction: reduce the current by toggling bits only when necessary.

That last argument convinced me about this new unit because optimising toggles requires a global perspective that each individual unit can't have. The current instruction word also needs to be latched for the multi-cycles operations (such as LDCx).

The decoder is a strip of logic gates that propagates bits from the instruction word, parallel to the bitslices, and decodes and spreads control signals in a "fishbone" pattern (perpendicular to the bitslices).

This increases the complexity of the clock and timing because performance dictates that the units must get their respective instruction bits directly from the program memory.

• If the instruction must go through a DFF, the value is delayed by one clock cycle and throughput/execution speed is hit...
• Going through a transparent latch saves time but increases the sensitivity to timing anomalies. A multi-cycles clock becomes necessary.

One solution though is to store the last instruction and combine it with the new instruction with one or two logic layers at most. It might not work for most control signals and it could generate some spikes, which I'm indeed trying to avoid (because they eat power).

I'm also considering adding transparent latches at the data inputs of the ALU.

But before I can add the latches, I have to take the control logic out of the units.