Practical 8 Pipelined Memory, Branches, Jumps

Objectives

This section is not a list of tasks for you to do. It is a list of skills you will have or things you will know after you complete the practical.

Following completion of this practical you should be able to:

Add instructions to the implementation of a pipelined processor
Trace code as it executes through a simulated pipelined processor
Use waveform diagrams to debug a processor implementation
Use verilog test benches and a testing framework to test a processor implementation

Guidelines

Because you will be iteratively adding functionality to one processor module, we strongly recommend that you periodically add and commit your progress to git as a backup.

Your Tasks

Follow this sequence of instructions to complete the practical. This practical will all be done in your practical-pipe repository

1 Add lw and sw to your processor

Trace both lw and sw on the datapath diagram on the worksheet. You should also indicate the relevant control signals being passed through the pipe, in addition to highlighting data wires.
Add any new traced wires to verilog datapath. You should probably use the "B" ports on the memory module to implement the MEM stage, rather than adding a second memory module.
Add the newly required control signals (or connect them). Don't forget the mux in the WB stage!
Look over the provided tests in test_pipe_mem_nohaz.asm, use this file to generate a .txt file to input into memory using your assembler.
Fill in the testing plan for one of the provided test instructions on the worksheet. Write a second entry in the testing plan for a test of your own devising. (You do not need to add this test to the actual test file, just add it to the worksheet.)
Run the provided memory tests by uncommenting the call to test_mem_type_nohaz() in tests tb_Pipe.v.

2 Add `lui` to your datapath

The rest of these entries follows the same pattern as lw/sw above, see that entry for details.

Trace on dp diagram (add any new wires)
Add any new traced or drawn wires to verilog datapath
- specifically watch out for what goes back into the register file
Add control (or connect it)
Write tests (uncomment the call to test_lui_nohaz() and read through its implementation in tb_Pipe.v, assemble the provided test_pipe_lui_nohaz.asm file with your assembler, and use it).
- Write an additional test (which may require you to create another .asm file and assemble it).
- Add test descriptions to the Testing Plan for one existing test, and a test of your own design.

3 Add Branches

Trace beq on the datapath
- NOTE: the diagram provided and the tests in your repo have the branch logic in Memory stage. In class we optimized performance by putting the branch logic in the Instruction Decode stage. You may implement it either way, but if you choose to optimize like we did in class modify the datapath drawing to show the modification.
- NOTE for the future: If you leave the branch decision in the Memory stage, during the next practical you will need to flush three invalid instructions from the pipeline. This is acceptable, but will be more work in the future when you do hazard detection.
- If you choose to implement branch detection in Decode, you will need to modify the tests for branches.
Implement beq
- hint: need a mux as input to the PC
Add control
Run beq test we gave you
implement bne, blt, and bge (hint: similar modifications to single-cycle)
Run other branch tests we gave you. Add tests to the branches testing plan as described on the worksheet.

4 Add `jal`

Trace the jal instruction on the datapath (in the worksheet), adding any hardware needed to make jal work.
Implement DP + control
- hint: datapath is a little like lui
- hint: input to PC is same as branch
- hint: linking is a bit hard, you might need to keep newPC in your pipeline stage register until WB.
Test (run tests we gave you). Add a test to the jal/jalr testing plan as described on the worksheet.

5 Add `jalr`

Trace the jalr instruction on the datapath (in the worksheet), adding any hardware needed to make jalr work.
Implement DP + control
- hint: addr calculation is just like lw/sw
- need to add to the PC input mux (new source)
Test (run tests we gave you). Add a test to the jal/jalr testing plan as described on the worksheet. Add a description of a test of your own design.

6 Write and run a bigger test

On the worksheet create a test plan entry that will test all the RISC-V instructions work in the same program, rather than one at a time.

Hint: if you need to space instructions out, put independent instructions between the two that caused a dependency. You do NOT want to introduce hazards. You can add zero to itself as a nop instruction:

  xori x2, x3, 4   # F D X M W
  add  x0, x0, x0  #   F D X M W
  add  x0, x0, x0  #     F D X M W
  add  x0, x0, x0  #       F D X M W
  addi x1, x2, x2  #         F D X M W (x2 is put in the reg file while this is getting fetched)

On the worksheet, answer the question to explain why the tests in this practical have no dependencies.

Turn It In

Grading Rubric

General Requirements for all Practicals:

The solution fits the need
Aspects of performance are discussed
The solution is tested for correctness
The submission shows iteration and documentation

Fill out the Practical Worksheet

In the worksheet, explain how you satisfy each of these items. Some guidelines:

None of these answers should be more than 100 words. Unless otherwise noted.

Practical 8 Rubric items	Possible Points
Practical Worksheet	45
Memory insts	15
LUI	5
SB-Types	15
JAL	10
JALR	10
Total out of	100

Submit your completed Practical Worksheet to gradescope.
Practical code will be submitted to your practical- pipe git repository as either new files or committed modifications to the repo. You must include your name and your teammates' names in a comment at the top of all files you submit.