# Lab 3 Report
112550019 謝嘉宸 112550047 徐瑋晨
## Introduction

In this lab assignment, our objective is to implement datapath as well as complete the control unit entries, or implement logic for generating remaining control outputs using the cs register for each RISC-V instruction in a single-cycle processor. Our overall approach is study the diagram and figures provided and simultaneously reference the code provided by the TAs to derive the remaining code.

## Design

We referenced the given figure, and the code skeleton provided for further insight.

### Datapath

#### Mux

We change the output of MUX by different input signals from ```pc_mux_sel```. If ```pc_mux_sel``` is ```pm_p```, then it indicates that the current operation is PC increment. If ```pc_mux_sel``` is ```pm_j```, then the instruction is a jump instruction. Same logic for ```pm_b``` (Which is a branching instruction) and ```pm_r``` (Which is JALR (jump register) instruction)

#### Register File

For connecting inputs to ports in Register File, we referenced the given figure, and added ```inst_rs1``` to address 1, and ```inst_rs2``` to address 2.

#### Operand 0 Mux

We change the output of operand 0 MUX by different input signals from ```pc_mux_sel```. If ```pc_mux_sel``` is ```am_rdat```, then it indicates that the current operation uses output of bypass mux for rs1. Same logic for ```am_pc``` (Which lets current PC go through), ```am_pc4``` (Which lets PC+4 go through), ```am_0``` (Which lets constant 0 go through), ```am_x``` (Which lets "don't care" term go through)

#### Operand 1 Mux

We change the output of operand 1 MUX by different input signals from ```pc_mux_sel```. If ```pc_mux_sel``` is ```bm_rdat```, then it indicates that the current operation uses output of bypass mux for rs2. Same logic for ```bm_shamt``` (Which uses shift amount), ```bm_imm_u``` (Which uses U-type immediate), ```bm_imm_sb``` (Which uses SB-type immediate), ```bm_imm_i``` (Which uses I-type immediate), ```bm_imm_s``` (Which uses S-type immediate), ```bm_0``` (Which uses constant 0), ```bm_x``` (Which uses "don't care" term)

#### Branch Condition Logic

For this, we reference the given TODO instructions and compare ```rf_rdata0``` and ```rf_rdata1``` based different branching instructions. We were especially careful on handling signed and unsigned comparisons.

#### Send out memory request

For this, we referenced the given figure and observed that the results of ALU should be inputted in the data memory, while `rf_rdata1` only supplies store data; loads are written via the data memory response path.

#### Muldiv Result Mux

We decide where to put the Muldiv result based on the input signal ```muldiv_mux_sel```. For ```mdm_l```, it means we should put the result into the lower 32 bits of the register. For ```mdm_u```, it means we should put the result into the upper 32 bits of the register.

#### Execute Result Mux

This Mux is aimed at deciding which result from ALU and Muldiv should be let through. Similarly, the decision is also influenced by the control signal ```execute_mux_sel```. If it equals ```em_alu```, then the results from ALU gets outputted; if it is ```em_md```, then the results from Muldiv gets outputted.

#### Data memory subword adjustment mux

This Mux decides the position in which to write the value. The decision is influenced by ```dmem_mux_sel```. The control signals represent different datatypes, and we place the values into the register in different positions based on datasize, and also decide whether to add the signed bit.

#### Writeback Mux

It is aimed at deciding which values to write back to the register file. If control signal ```wb_mux_sel``` is ```wm_alu```, then it writes back the result from ```execute_mux_out```.If control signal ```wb_mux_sel``` is ```wm_mem```, then it writes back the result from ```dmemresp_mux_out```

### Control Unit

To tackle this objective, we referenced the RISC-V instruction manual and simulated the instructions flowing thorough the Datapath to gain more insight on how each control signal might react to each instructions.

#### I-type and R-type Instructions
All I‑type and R‑type instructions assert their validity bit and leave jumps, branches, and memory operations disabled so that the PC simply advances by four. Both kinds feed the ALU from the register file (so `amux = am_rdat` and `rs1_en = y`), omit any multiply/divide unit involvement (`md_fn = md_x`, `md_en = n`), send the ALU output straight through the execute multiplexer (`ex_muxsel = em_alu`), and write the result back into the register file (`wb_muxsel = wm_alu`, `rf_wen = y`, `rf_wa = rd`). The only real difference is in how the second operand is chosen and whether a second register operand is enabled: I‑types use an immediate (`op1_muxsel = bm_imm_i`) or, for shifts, the shift amount (`op1_muxsel = bm_shamt`) with no second register (`rs2_en = n`), whereas R‑types take both operands from registers (`op1_muxsel = bm_rdat`, `rs2_en = y`).

#### Load and Store Instructions
Loads and stores follow the same basic pattern for address calculation—`val = y`, no jumps or branches, `amux = am_rdat`, `rs1_en = y`, `op1_muxsel = bm_imm_i`, `alu_fn = alu_add`—but differ in whether they drive or consume data from memory. Loads disable the second register file port (`rs2_en = n`), set the memory operation to load (`mem_op = ld`), choose the data‐memory mask (`dmm`) and width (`ml`), and then route the memory result to the register file (`wm_mem = y`, `wb_muxsel = wm_mem`, `rf_wen = y`). Stores enable the second port to supply store data (`rs2_en = y`), set `mem_op = st`, and leave all writeback signals off (`wm_x`, `rf_wen = n`).

#### Jump Instructions
Jump instructions also set `val = y` but activate the jump enable bit (`j_en = y`) and select between PC‑plus‑immediate (`pm_j` for JAL) or register‑plus‑immediate (`pm_r` for JALR) as the next PC. Both use the ALU to form the link address by adding four to the PC (`amux = am_pc4`)—JAL does so without reading a register (`rs1_en = n`, `op1_muxsel = bm_0`), while JALR reads its base register (`rs1_en = y`, `op1_muxsel = bm_imm_i`)—and then write that link back into the register file (`wb_muxsel = wm_alu`, `rf_wen = y`, `rf_wa = rd`).
#### Branching Instructions
Conditional branches leave `j_en` off but encode their test in the branch‑select field (`br_sel`), feed both registers through the ALU with `alu_fn` set to XOR for equality or to the appropriate less‑than test, and choose the branch target vs. PC + 4 via `pc_muxsel = pm_b` when the condition is met. Since they never touch memory or write back results, the execute multiplexer is diverted (`ex_muxsel = em_x`) and all writeback and memory enable signals remain off (`wm_x`, `rf_wen = n`, `mem_op = nr`).
#### Muldiv Instructions
Multiply‑and‑divide instructions turn on their `val` bit without enabling jumps or branches, take both operands from registers (`amux = am_rdat`, `rs1_en = y`, `op1_muxsel = bm_rdat`, `rs2_en = y`), and hand off computation to the MD unit by setting `md_fn` to one of the multiply or divide codes and `md_en = y`. The execution multiplexer selects the MD result (`em_md`), and the output is treated like any ALU result for writeback (`wb_muxsel = wm_alu`, `rf_wen = y`, `rf_wa = rd`) while memory remains untouched.
#### Parse remaining output control signals
Finally, the 34‑bit control word is simply sliced into fields that drive all of these decisions. After decoding the branch test into a single “need_branch” signal, the top two bits choose between PC + 4, a branch target, or a jump. The next groups of bits directly wire operand multiplexers and function codes into the ALU and MD units. Memory controls follow, with bits for read/write, width, and response routing, and the final bits steer writeback selection, register‑file enable, and destination register address.
## Testing Methodology

For testing, we simply wrote one assembly code for each instruction to check whether each instruction will be handled properly. For R-type and I-type instructions, we design the problems and prepare correct results in advance so that when our implementation code gives the result, we can determine whether the instructions are handled correctly.

For B-type instructions, we simply make all the branch conditions to be true and let those instructions branch to the pass label to demonstrate the instruction handled correctly. Therefore, we can determine whether our designs are correct by checking the results.

For instructions `j` and `jr`, we check whether the jump work correctly(jump to the correct position of the code), and for the `jalr`, we modified the provided code `riscv-jal` and check both the `rd` value and the position jumped to.

## Conclusion

In this lab, we have successfully implemented the datapath and control unit of a single-cycle processor. Particular insights are gained through observing the given figures and the skeleton code. We now possess verilog level understanding of how single-cycle processor works and have learned alot from assigning values to unit control table. We believe this will be a solid foundation on which we can rely on in our future hardware-oriented endeavours.