Siyue Zhang
Figure 4: Testbench for the RAM and Decoder
"01011" after 200ns, "01100" after 220ns,
"01101" after 240ns, "01110" after 260ns,
"01111" after 280ns;
The result of running the testbench for ROM is shown in figure 3. As
we can see from the result, the output of the RAM is exactly the initial
value corresponding to their addresses, so that we prove our ROM entity
is correct.
3 DECODER AND RAM
3.1 Design of Decoder
Decoder can break the long 32-bit instructions into short pieces and each
piece of instruction is the required component to feed to the ALU and
the RAM. The format of these instructions is as follows: The first 6 bits
identify the opcode; The next 5 bits identify first source register; The next
5 bits identify second source register; The next 5 bits identify destination
register; The final 11 bits are unused. So the design of the decoder is
simply reassigning the instruction, and we also need to add pipeline and
let the decoder breaks one instruction every clock cycle.
process (clk)
begin
if (rising_edge(clk)) then
opcode <= instruction(31 downto 26);
address1 <= instruction(25 downto 21);
address2 <= instruction(20 downto 16);
address3 <= instruction(15 downto 11);
end if;
end process;
3.2 Upgrade ROM to RAM
Comparing to ROM, RAM can be changed by user and have both read
and write ports. Therefore we simply add a newline of code on the ROM:
process (clk)
begin
if (rising_edge(clk)) then
ram_data( CONV_INTEGER(address3) ) <= din;
end if;
end process;
where the ”din” is the data you want to store in the RAM, and address
tells the RAM where do you want to save the data.
3.3 Testing the RAM and Decoder
To test the correctness of RAM and decoder, we use a series of
instructions: r2=r4+r5, r3=r4+r5, r3=r1+r2:
3