The Control Unit

Every RISC-V instruction is 32 bits long. The fields of the instruction are always located at the same positions, independent of the instruction format:

This regularity is a big advantage: the register file can already read rs1 and rs2, while the control unit is still decoding the instruction - even if it later turns out that one of them is not needed.

The control unit mainly looks at the lowest 7 bits, the opcode. For our minimal subset these are:

The fields funct3 and funct7 distinguish instructions with the same opcode, e.g. add from sub. We will need them later for the ALU control.

The following picture shows our complete single-cycle CPU. It extends the data path from the last post by the control unit, the ALU control, the immediate generator and three multiplexers. The control signals are drawn in blue: they leave the control unit on the right and are drawn at their destinations as short stubs with the same names, so the picture stays readable.

Instruction memory and data memory are two separate memories here. This is necessary, since within a single clock cycle we have to read an instruction and access the data memory.

Now we can determine for every instruction which value each control signal must have. This table is the heart of the control unit:

The X stands for "don’t care": for sw and beq the value of MemToReg does not matter, because RegWrite = 0 and nothing is written into the register file anyway. Such don’t cares give us freedom to make the logic smaller.

Let’s go through the rows:

The ALU from part 1 is controlled by the signals Ainvert, Binvert and Operation. Together they form 4 control bits. For our instructions we need:

The ALU control generates these 4 bits from the 2-bit ALUOp of the main control and, for R-type instructions, from funct7 (only bit 30 of the instruction matters) and funct3:

Why two stages? The main control only has to make a rough decision ("address calculation", "comparison" or "look at funct"), and the ALU control does the fine decoding. Both blocks remain small, and each of them has only a few inputs. This principle of multi-level decoding keeps the logic small and fast.

Some instructions contain a constant (immediate). The immediate generator extracts it from the instruction bits and extends it to 32 bits. Depending on the format, the bits are located at different positions:

That looks a bit confusing at first, but it has a reason: wherever possible, a bit of the constant is located at the same position in all formats. And the sign bit is always inst[31]. This way the sign extension can start immediately, before the format is even known.

For branches, the lowest bit imm[0] is always 0, since branch targets are always at an even byte address. It is therefore not stored in the instruction at all - this doubles the range of the branch.

The sign extension fills the upper bits with copies of the sign bit. This way, a negative offset like -8 remains negative after the extension (two’s complement says hello).

For a branch the ALU computes rs1 - rs2. Its Zero output is 1, if the result is 0 - i.e. if both registers are equal. At the same time, the second adder calculates the branch target PC + offset. The multiplexer in front of the PC is controlled by:

\[PCSrc = Branch \cdot Zero\]

Only if the instruction is a branch and the registers are equal, the branch target is loaded into the PC. In all other cases the PC simply moves on to PC + 4.

Let’s follow the instruction lw x5, 8(x6) through the picture above:

All of this happens within one clock cycle, as pure combinational logic. Only with the next rising clock edge, the new values are taken over: the register file writes x5, and the PC takes over PC + 4. This is exactly the behaviour of the D-flipflops from the post about clocks and registers.

Our example program from the RISC-V post uses two instructions which our minimal CPU cannot execute yet: addi and bne. Let’s extend the CPU - this shows nicely how the control unit grows with the instruction set.

With these extensions, our CPU can now execute the example program. The program is located from address 0x00 on:

The control signals for the instructions used:

And this is what happens clock cycle by clock cycle:

After 33 clock cycles the counting is done, and the CPU circles in the endless loop at address 0x18. In clock cycle 6, for example, the ALU computes 1 - 10 = -9, so Zero = 0. Since inst[12] = 1 for bne, Zero ⊕ inst[12] = 1, and with Branch = 1 we get PCSrc = 1: the PC jumps back to 0x14 + (-8) = 0x0C.

If you want to see this live, load the program into the simulator Ripes and select the single-cycle processor: there you can watch the control signals switch from instruction to instruction.

Our CPU works - but it is not fast. The clock period must be long enough for the slowest instruction. With typical example values (as used by Patterson and Hennessy) we get:

The clock period is therefore 800 ps, determined by lw - even though a beq would be done after 500 ps. Every instruction "waits" for the slowest one.

This is where the series ends for now - but this is exactly where computer architecture really starts. Here are the most important next steps, which you will find in the literature:

If you want to build the CPU yourself, a hardware description language and an FPGA are the next step. The author has written some posts about getting started with FPGAs.

From the first logic gate to a CPU that runs a program: this was the path of this series. In part 1 we got to know the combinational building blocks - gates, boolean algebra, adders and the ALU. In part 2 the memory was added - flipflops, registers, memory and state machines - and finally all of this was combined into a working RISC-V CPU.

Further reading:

(Created with Claude AI)