Lab 9 Pipelined hazard resolution
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 lab.
Following completion of this lab you should be able to:
- Implement data hazard resolution in a pipelined processor by employing write-before-read, data forwarding, and stalls.
- Implement control hazard resolution by flushing the pipeline
- Use waveform diagrams to debug a pipelined processor implementation with instructions in all stages of the pipe
- 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 lab.
This lab will all be done in your D-group
repository
1 Run the hazards tests
TODO: some lab worksheet stuff exploring the hazard test bench.
2 Write then read
- Examine the x2 hazards
.asm
file - Examine the
tb_Processor_hazards.v
test bench - Run it, and make a waveform
- Uncomment the write-then-read test in the
- Figure out how to make your reg file write before it reads
- hint: two clocks? Kind of.
3 Data forwarding
- Create forwarding unit
- specs?
- Handle WB -> EX forwarding
- uncomment our test for this
- Handle MEM -> EX forwarding
- uncomment our test for this
4 lw
stall
-
Examine test asm file
test_datahaz_lw.asm
-
Construct a hazard unit module
-
Handle stall when
lw
is in EX and the next instruction will use its rd value (see page 322 in the textbook)- hint: disable writing to the
IF_ID
register and PC when stalling. - hint: need to insert bubble in
ID_EX
(hint: add a flush capability to the stage register that puts all zeroes into its control bits and any instruction data you're carrying) - hint: special case for UJ and U types that follow a
lw
: they don't use register sources!
- hint: disable writing to the
-
Run our tests (
test_lw_stall()
) -
Something about SW tests too
-
TODO: On the worksheet, answer the question about forwarding from
lw
tosw
5 Flushing the pipe
- TODO: On the worksheet, draw a pipeline diagram for the instructions given.
- Examine test asm file
test_ctlhaz_beq.asm
- NOTE: branch writes the PC in the memory cycle (see textbook)
- this means everything following it must be erased.
- Figure out how to insert bubbles as instructions leave the
EX
,ID
, andIF
cycles- hint: use the same trick used to insert a stall to flush
EX_MEM
,ID_EX
, andIF_ID
stage registers while the PC is being written to the branch target by the instruction inMEM
.
- hint: use the same trick used to insert a stall to flush
- Run our tests (
test_beq_flush()
) - Write new tests for jal and jalr and run them.
6 Write and run a bigger test
TODO: tell them to write a test with jumps, returns, arguments. Give them C code or something.
// m and n are variables in memory. Be sure to update them when they change.
// Array A is at x5
int[] A = {1, 2, 3, 4, 5};
int idx = 0;
while(idx < 5) {
A[idx] = A[idx] + 1;
idx = idx + 1;
}
- Write the code for this on the worksheet (and put it in an .asm file in git)
Then, have them run their relprime from previous homework or something.
TODO: Give them an empty tb_Processor_Program.v
file to run an arbitrary program.
7 Design a new instruction
TODO: tell them to design an instruction that will be hard to add to the pipeline
- Invent an instruction that makes relprime run faster (this generally would combine multiple instructions into one new instruction).
- Document the design (in the lab worksheet +10 pts) and explain how you plan to add it to the pipeline
- maybe add a stage to support extra work
- or stall the pipeline
- or add more hardware to existing stages
- implement the design
- Run relprime with your new instruction (you'll have to rewrite relprime)
- Compare the two runtimes (number of cycles for each run)
- Optional: implement it another way too (git branch?)
8 Bonus - add MMIO
TODO: Give them a diagram for MMIO, have them add to pipeline
- And then change the test bench to use IO addresses.
- Give them a test bench for IO
- On the worksheet explain how to modify relprime to use this IO.
Turn It In
Grading Rubric
General Requirements for all Labs:
- fits the need
- discuss performance
- tests for correctness
- iteration and documentation
Fill out the Lab Worksheet
In the worksheet, explain how you satisfy each of these items. Some guidelines:
- None of these answers should be more than 100 words.
- For item 1, ??
- For item 2, ??
- For item 3, ??
- For item 4, ??
Lab 9 Rubric items | Possible Points |
---|---|
Lab Worksheet | 30 |
Write-Then-Read RegFile | 5 |
Forwarding unit | 15 |
lw stall (Hazard Unit) | 15 |
branch/jump flushing | 15 |
New tests | 10 |
New Instruction (impl) | 5 |
Extra points | 5 |
Total out of | 100 |
For extra points, you could:
- Implement your new instruction a second way (add a stage, add stalls, etc) in your pipelined processor
- Document how to resolve hazards your new instruction causes
- Update your assembler to assemble your new instruction
- implement I/O
-
Submit your completed Lab Worksheet to gradescope.
-
Lab code will be submitted to your
D
git repository as new files and committed modifications to the repo we provided you. You must include your name and your teammates' names in a comment at the top of all files you submit.