This lesson starts at commit d20e09da83bc7dac0d753d0a4db9a9ce99c50327.

4. Execute and writeback stage

To recap, we have

1. A fetch stage (which is a temporary hack that should be re-done, but for now it allows us to keep making progress).
2. A decode stage, which only decodes the ADDI instruction.

The goal for this lesson is to actually execute the ADDI instruction and write the result back to the target register. Naturally, this requires changes to the execute and writeback stages.

From the execute stage, we want to return the result from the operation, and the destination register.

We want to pass this on to the writeback stage, but the memory stage is inbetween, still. We'll adapt the memory stage to just copy the input.

Now, we still need to provide the actual implementations in the execute and writeback stage.

In the execute stage, we want to ignore inactive signals and invalid instructions (we will need to handle invalid instructions some day, but today is not that day). For invalid or inactive instructions we'll simply output the default output. To signal "we don't need to write to a register", we simply set the destination register to 0, because in RISC-V the first register, x0, always holds zero, and it cannot be overwritten. We'll need to handle this in the writeback stage.

Now, we're ready to actually handle the addition operation in the execute stage.

We can make the "this should never happen" a bit more robust by making it an assertion.

If we test this in simulation, we see the correct values for result and destination_reg show up in the writeback stage.

However, the writeback stage itself doesn't do anything. We run into a problem here; In the last lesson we put the registers in the decode stage, so we don't have access to them from the write stage...

Like I mentioned last time, one solution is to make a module for a register file, that the decode stage and the writeback stage can both talk to. However, I don't really like making an additional module, and instead I'll opt to merge the writeback stage and the decode stage into a single module, which I'll simply call decode_write. I will adapt the decode module and delete the write module (which was only a placeholder anyway).

So, the core module will need to route the output of the memory stage back to the decode stage, which will then handle writing the final value to the destination register.

First, I'll rename decode.vhd to decode_write.vhd and delete write.vhd.

Then, I'll make the decode_write module take the output from the memory stage.

Now, it's relatively easy to perform the write to the destination register.

If we simulate this for 70 ns and observer the input to the write stage and the x1 register, we see the following waveforms.

This looks good; The value 0x7b (which is 123 in hex) gets written to the x1 register. We have implemented our first RISC-V instruction, and it looks like it's being executed correctly! You can give yourself a pat on the back, this is a nice milestone!

When you're done celebrating, let's try another test case, that increments the x1 register twice in a row. That is, let's execute

ADDI x1, x1, 1
ADDI x1, x1, 1

Again using this sweet online RISC-V assembler, we see that ADDI x1, x1, 1 assembles to 00108093. We put this instruction in our instruction memory twice.

Now we run the simulation again for 70 ns, observing the input for the write stage, and the value of the x1 register.

We can see that in the fifth and sixth cycle, a write to the x1 register happens (destination_reg is set to 1). However, the value of result, which is written to the register, should be 2 the second time. So, we have a bug.

What is going on? When the second ADDI x1, x1, 1 instruction arrives in the decode stage, the value of the x1 is read as 0, since the instruction before it has not yet finished executing.

This phenomenon where one instruction needs the result of an instruction before it that has not yet finished, is known as a read-after-write hazard. In pipelined processors, you need to track these dependencies, and wait until all the dependencies have finished executing. The cycles where the processor is waiting are called "pipeline bubbles" or "pipeline stalls". In our case, these manifest as cycles where the output of a stage has the is_active set to 0.

So the proper solution is to keep track of the number of instructions in the pipeline that write to every register. However, I don't feel like doing that at this point. Instead, I am going to do something much simpler for now: Let the fetch wait until the previous instruction has finished. This is potentially much slower than doing the proper solution, but I really want to get a simple processor working before spending a lot of effort to pipeline it.

So, what we can do is add an output pipeline_ready to the write stage, that will be set to 1 for a cycle whenever an active instruction finishes. This signal will then be fed back to the fetch stage, and a new instruction will only be fetched when this signal is 1.

For this, first we need to propagate the is_active signal all the way to the write stage.

With that done, we "loop" the signal back around as pipeline_ready from the write stage back to the fetch stage, and only fetch if it's 1. We initialize the value to 1 in the output of the write stage to not get in a "deadlock", with the pipeline waiting for an instruction, and the fetch unit waiting until an instruction finishes.

With this change, we see the value of x1 settles on 2, after 100 ns.

So, now we can also execute multiple successive ADDI instructions.

While we have only implemented a single instruction, it is worth realizing that implementing more instructions is relatively easy, since most of the "infrastructure" is there. To illustrate this, let's implement the ADD instruction, which is similar to ADDI but operates on two registers instead of a register and an immediate value.

That's it! Many other instructions operate on two operands and write the result to a destination register; these are very easy to implement (although for most of them we do need to implement a new operation in the execute stage).

Instructions that are very different (like memory operations, or control flow operations) will be a bit more work, but even so, it's a lot less than the work we've already done at this point.

In the next lesson we'll look at actually running our design on the Mimas A7 dev board.