0% found this document useful (0 votes)
6 views4 pages

Ca HW5

The document outlines the design and implementation of various modules in a computer architecture assignment, including components like the adder, ALU, branch predictor, and control unit. It details the functionality and interconnections of these modules, as well as the handling of hazards and data forwarding. Additionally, it discusses challenges faced during the assignment and the development environment used.

Uploaded by

b11902027
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views4 pages

Ca HW5

The document outlines the design and implementation of various modules in a computer architecture assignment, including components like the adder, ALU, branch predictor, and control unit. It details the functionality and interconnections of these modules, as well as the handling of hazards and data forwarding. Additionally, it discusses challenges faced during the assignment and the development environment used.

Uploaded by

b11902027
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Computer Architecture Homework 5

Student: B11902027 陳思瑋

1 Modules
1.1 Adder
The adder takes two 32-bit numbers, add1 i and add2 i, and outputs a 32-bit number, result o,
which is the sum of add1 i and add2 i.

1.2 ALU Control


The ALU Control module takes two inputs: aluop i and instr i. The aluop i signal is set to
112 for I-type instructions, 102 for R-type instructions, 012 for branch instructions, and 002 for load
and store instructions. Meanwhile, instr i represents the instruction bits [31–25, 14–12], totaling 9
bits. The module outputs alucon o, with the corresponding alucon o value for each ALU operation
listed in the following table:

Operation aluop i alucon o

add 102 00002

sub 102 00012

mul 102 00102

and 102 00112

xor 102 01002

sll 102 01012

srai 112 01102

addi 112 01112

lw 002 10002

sw 002 10002

beq 012 10012

Page 1
Homework 5 B11902027 Computer Architecture

1.3 ALU
The ALU uses alucon i, generated by the ALU Control module, to determine the current oper-
ation. Through a series of if-else statements, it processes each operation and outputs the result via
result o. Note that the beq instruction is not handled in this module, as it is managed in the ID
stage.

1.4 Branch Predictor


In this part, aside from clk i and rst i, we have two additional inputs: branch i and alu result i.
We check whether the instruction being processed in the EX stage is a branching instruction using
branch i, and then use alu result i to update the current state of the finite state machine. The
state is stored in the register state[1:0]. Additionally, we output the current branch prediction
through the wire predict o by examining the current state of the finite state machine.

1.5 Control
In this section, we have two inputs: opcode i and NoOp o. There are seven outputs: regwrite o,
alusrc o, aluop o, memtoreg o, memread o, memwrite o, and Branch o.

• For regwrite o, it is set to 02 for the beq and lw instructions, and 10 for all other instructions.

• For alusrc o, it is set to 12 for instructions that include an immediate value. For the remaining
instructions, it is set to 02 .

• For aluop o, it is set to 112 for I-type instructions, 102 for R-type instructions, and 012 or 002
for load and store instructions. Note that for branch instructions, it is ”don’t care” since these
are completed in the ID stage.

• For memtoreg o, 12 is set only for the lw instruction. For all other instructions, it is set to 02 .

• For memread o, 12 is set only for the lw instruction. For all other instructions, it is set to 02 .

• For memwrite o, 12 is set only for the sw instruction. For all other instructions, it is set to 02 .

• For Branch o, 12 is set only for the beq instruction. For all other instructions, it is set to 02 .

Note that when the input NoOp o is 12 , regwrite o, memtoreg o, memread o, memwrite o, and
Branch o are all set to 02 to perform a No-Operation.

1.6 CPU
In this part, we construct the datapath based on the SPEC of lab2. Unlike the datapath in
lab2, the branch predictor is placed in the EX stage. The prediction result is passed to the ID stage
and is also forwarded as the previous prediction to the IDEX pipeline register for detecting incorrect
predictions in the EX stage. A flush signal is provided to the IFID and IDEX pipeline registers to
manage flushes caused by incorrect predictions. Additionally, two new multiplexers are introduced in
the ID stage to handle branching issues.
Furthermore, the program counters for both branch-taken and branch-not-taken situations are
passed to the IDEX pipeline register, allowing for the correction of errors caused by incorrect branch

Page 2
Homework 5 B11902027 Computer Architecture

predictions. If an incorrect prediction is detected in the EX stage, the program counters for branch-
taken and branch-not-taken are sent back to the newly added multiplexer in the IF stage. By utilizing
the aforementioned flush signal, previous prediction, ALU result, and branching signal, we can con-
struct the selector signal for the two newly added multiplexers.

1.7 Forwarding
In this module, we check whether data forwarding is needed from the MEM stage or the WB stage
to the EX stage. Specifically, we determine if the registers being operated on in the EX stage match
those in the MEM or WB stages for both rs1 and rs2. If they match and the register in the MEM or WB
stage is being written to, it indicates the need for data forwarding.
Note that if data forwarding is required from both stages, priority is given to forwarding from the
MEM stage over the WB stage. This is because the value produced by the MEM stage will overwrite the
one in the WB stage. If data forwarding is not needed, the output will be set to 002 . If data forwarding
is required from the MEM stage, the output will be set to 102 , and if it is needed from the WB stage, the
output will be set to 012 . Referring to the pseudo code provided in the SPEC will help implement
this part effectively.

1.8 Hazard Detection


In this part, we need to tackle two kinds of hazards: data hazard and control hazard.

• Data Hazard: A data hazard occurs when a register is used immediately after a load instruc-
tion. To detect this type of hazard, we check if the register referenced by rs1 and rs2 in the ID
stage is the same as the register used in the load instruction in the EX stage. If this condition is
met, we will take the following actions:

– Set NoOp o to 12 to perform a No-Operation.


– Set Stall o to 12 to stall the values held in the IF/ID pipeline register.
– Set PCWrite o to 02 to prevent changing the value of the program counter, effectively
allowing the instruction to be retried.

If we don’t detect a data hazard, we will set NoOp o, Stall o, and PCWrite o to 02 , 02 , and 12 ,
respectively.

• Control Hazard: A control hazard occurs when the condition of the branch instruction, beq
in this assignment, is met. In my implementation, the control hazard is not detected using the
hazard detection unit, but it is mentioned here for simplicity. The following are the steps for
checking and tackling the control hazard:

– Checking if a control hazard occurs: Using the Equal module and the output Branch o
from the control unit to check if a control hazard occurs. If the values stored in the registers
rs1 and rs2 are the same, and the value of Branch o is 12 , then a control hazard occurs.
– Tackling the control hazard: We use the output value of the IMMED GEN module to
change the value of the PC. Additionally, we set the input wire flush i to 12 to flush the
already fetched instruction stored in the IF/ID pipeline register.

Page 3
Homework 5 B11902027 Computer Architecture

1.9 IMMED GEN


In this module, we generate the immediate value for each operation by checking the input
instruct i and referring to the table in the SPEC. The immediate value is then output to immediate o.

1.10 MUX32
For MUX32, we check the input alusrc i to determine the value to output through output o. If
alusrc i is 02 , then output o will take the value of input0 i; otherwise, if alusrc i is 12 , output o
will take the value of input1 i.

1.11 MUX32 2
The MUX32 2 is a multiplexer with three input data lines. By checking the value of the input wire
alusrc i, we select the corresponding input data to output through output o. When the value of
alusrc i is 002 , 012 , and 102 , we select the first, second, and third input data to output, respectively.

1.12 Pipeline Registers


We have four pipeline registers in total: IF/ID, ID/EX, EX/MEM, and MEM/WB. In these pipeline
registers, several inputs from the previous stage are passed to the later stage. When the clk i is at a
positive edge, the values of the wires are transferred to the later stage. Additionally, when the rst i
is at a negative edge, all values are reset to 0. Note that for the ID/EX pipeline register, we have two
special inputs, Stall i and flush i, to handle hazards. When Stall i is set to 12 , we do not change
the values in the pipeline register. On the other hand, if the value of flush i is set to 12 , we flush
the values stored in the pipeline register, meaning we set the values in the register to 0.

2 Difficulties
2.1 Naming wires and registers
There are numerous wires and registers in this assignment, which often caused confusion. In
the end, I decided to add a suffix to each wire and register to indicate which pipeline register they
originated from. The downside of this method is that the names of the variables become very long.

2.2 Constructing the data path on my own


Since no datapath was provided in this lab, I spent some time struggling to construct the datapath
on my own. Although it was frustrating, I personally view this experience as a valuable opportunity
to practice and ensure that I truly understand how all the components in the CPU we constructed
work.

3 Environment
• Operating System: MacOS Sonoma version 14.6.1

• Compiler: Icarus Verilog version 12.0

Page 4

You might also like