This lesson starts at commit c2c6ad9e07ff149a1de3863f1d10db636e966997.

8. Memory

We'll start with a simple implementation of the memory subsystem, which we need for the load and store instructions. There is quite a lot which we'll need to do for this module, so we'll start on familiar ground and take small steps.

We'll start by implement the store instructions, and specifically, the SW (store word) instruction. The familiar ground we're starting from is the decoder; we'll just do what we have done dozens of times before: Add some decoding logic.

The RISC-V docs say this about the store instructions:

Load and store instructions transfer a value between the registers and memory. [...] The effective address is obtained by adding register rs1 to the sign-extended 12-bit offset. [...] Stores copy the value in register rs2 to memory.

We'll use the first operand to store the address and the second operand to store the value. For now, I'll assume that stores are aligned to a multiple of 4 bytes. The RISC-V specification allows raising exceptions for misaligned memory access (but for now, we will stick to implementing aligned stores, and leave exceptions for later).

Now we want to start implementing the OP_SW operation in the execute stage.

Hm, we're a bit stuck here. We want to talk to some kind of memory interface or wrapper, which I'll pompously call "memory subsystem". We'll need to output at least:

• An indicator value to indicate we want to write
• The address to write to
• The value to write

The memory subsystem will be placed outside the core, since there are other components that want to "talk" to the memory. So, I'll make a record for these signals, but place it outside of the core folder.

Now, we want to make a new module for the memory subsystem.

Now, we want to instantiate the mem_subsys module in the top_level, and route the signals from the execute stage to the memory subsystem, crossing the interface of the core module. So, here we go.

Now implementing OP_SW in the execute stage is simple.

Now we need to implement the memory subsystem itself. In the spirit of "doing the simplest thing that could work", we can just make a vector of std_logic_vectors like we did for the registers. Let's make it 4KB big, which means it's 1024 words, since words consists of 4 bytes.

Now, let's write a simple program that increments a counter, and uses the counter as both the address and the value to write. Since the address is in bytes but we're writing words, we'll shift the address to the left by two bits, which makes sure the address is a multiple of 4 so that our stores are aligned.

loop:
sll x2, x1, 2
sw x1, 0(x2)
lw x5, 0(x2)
addi x1, x1, 1
j loop

This assembles to

00209113
00112023
00108093
ff5ff06f

And... This looks good! Our memory gets filled, word by word.

Now, I want to proceed by implementing the LW (load word) instruction. This is somewhat similar to storing a word, in that the execute stage will signal an address to the memory subsystem, and the memory subsystem will act on it.

However, the memory subsystem needs to know if it has to perform a read or a write command. So let's add a type and field for it.

Now, we still need to set the proper command in the execute stage.

We are now ready to start implementing LW. First, we add an operation for it.

We are now ready to decode LW instructions. The address computation is the same as for the SW instruction, but this time we need to set the destination register.

Now we can tell the memory subsystem to read from the execute stage.

We still need to implement reading in the memory subsystem. I'll add an output named res (for "response").

This output needs to be routed back to the core.

Now, we want to route it back to some stage. When the execute stage writes its output, the memory stage is running (for one cycle). At the same time, the memory subsystem is also doing the read. So, the output from the read will not arrive in time for the memory stage; we can only use it in the writeback stage. So, we are not doing anything in the memory stage, except just adding a single-cycle delay to make sure the value that is read from the memory arrives in time for the writeback stage.

Now, as a last step, the execute stage needs to tell the writeback stage that it has to store the response from the memory in the destination register, instead of the result output from the execute stage. For this, I add a use_mem flag to the output of the execute stage. It needs to be routed through the memory stage, so I'll add it to the output of the memory stage as well.

Now, we need to set this flag in the execute stage whenever we perform a read.

Finally, we need to update the writeback stage to actually write back the memory response when the use_mem flag is set.

That's it, I guess? We can adapt our program from before by adding a load of the same address immediately after the store.

loop:
sll x2, x1, 2
sw x1, 0(x2)
lw x5, 0(x2)
addi x1, x1, 1
j loop

This assembles to

00209113
00112023
00012283
00108093
ff1ff06f

So we'll put this in the instruction memory.

When we simulate this... It doesn't work?

After tracing the signals, it becomes obvious we forgot to pass the use_mem flag in the memory stage. We can just update it to also copy this flag:

Actually, since the memory stage does nothing, we can just remove the memory_output_t, since it is exactly the same as execute_output_t. So let's do a bit of cleanup and remove the memory_output_t and associated constants, and replace it by execute_output_t whenever it's used.

The memory stage can now be simplified.

We now want to simulate this. From now on, we'll always want to use top_level_tb.vhd, because just the core is not enough. We might as well delete it to avoid confusion.

If we now simulate for 500ns and watch the x5 register, we can see the successive values getting loaded.

Next, we're going to implement byte and halfword reads, which require us to write only some of the bytes, instead of always the whole 32-bit word.

To support this, I am going to copy and edit some code from AMD's docs, that is supposed to infer a block RAM. This code supports a "write enable" input, which I want to use.

Now, we'll hook up the mem_subsys code to use this bram.

In simulation we see that our memory subsystem works just as before. However, we now have a wea signal that we can use to implement writes that only write some bytes. We want to pass this directly from the execute stage so that we can implement halfword- and byte-sized loads and stores.