Forwarding and Hazards

Download Report

Transcript Forwarding and Hazards

Forwarding and Hazards
Member
Role
William Elliott
Team Leader
Jessica Tyler Shuler
Wiki Specialist
Tyler Kimsey
Lead Engineer
Cameron Carroll
Engineer
Danielle Turner
PowerPoint Leader*
Chris Smith
Presentation Leader*
Saeed Alshahrani
PowerPoint Team*
Matt Wood
PowerPoint Team*
*Roles change with Phase
Overview
What are Hazards?
 Hazards are problems that occur within the instruction
pipeline of the central processing unit (CPU)
microarchitecture that can potentially result in an incorrect
computation.
 There are several types of hazards
 Structural Hazards
 Data Hazards
 Control Hazards
Block Diagram
Structural Hazards
 When the current instruction cannot execute in the proper
clock cycle because the hardware does not support the
combination of instructions that are set to execute
 These are not a problem in the MIPS architecture, as there is
sufficient hardware to implement everything we need
 The only solution, would they occur, would be to add more
hardware
Data Hazards
 When the current instruction cannot execute in the proper
clock cycle because data that is needed to execute
instruction is not available.
 Load-use data hazard: a specific form of data hazard in
which the data being loaded by a load instruction has not yet
become available when it is needed by another instruction
Read-after-Read (RAR)
 This is a false dependency
 Reading won’t alter the
contents of the register file,
and the registers are read
at different times
MIPS
Pseudo-code
add $t0, $t1, $t2
sub $t4, $t1, $t5
c=a+b
d=a+e
Write-after-Write (WAW)
 This is not a hazard to be
concerned with
 The output of the second
operation in no way relies
on the output of the first
 Output is stored again in
the next pipeline stage,
overwriting the value from
the first instruction
MIPS
Pseudo-code
add $t1, $t2, $t3
add $t1, $t4, $t5
c=a+b
c=d+e
Write-after-Read (WAR)
 This is also not a hazard
 The “sub” instruction reads
in the value of $t3 five
stages before it’s written
into the register file
MIPS
Pseudo-code
sub $t1, $t2, $t3 c = a + b
add $t3, $t4, $t5 b = d + e
Read-after-Write (RAW)
 This refers to a situation where a
previous instruction has not
finished writing a value to
memory before it needs to be
used
 This can occur because of the
pipelined nature of our
processor. Data is written back
to the register file two stages
after the subsequent instruction
needs this information.
 This is known as a true-data
dependency
MIPS
Pseudo-code
add $t1, $t2, $t3 c = a + b
add $t4, $t1, $t5 d = c + e
Data Hazards
True-Data Dependencies
 Stalling – inserts a bubble, or a
nop (no operation) into the
pipeline
 Forwarding – Copies data from
inside the pipeline before it is
written back to the register.
Forwarding Example
add $t1, $t2, $t3
add $t4, $t1, $t5
Forwarding Logic
Selector MUXs
Mux Control
Source
Explanation
ForwardA = 00
ID/EX
The first ALU operand comes from the
register file
ForwardA = 10
EX/MEM
The first ALU operand is forwarded from
the prior ALU result
ForwardA = 01
MEM/WB
The first ALU operand is forwarded from
data memory or an earlier ALU result
ForwardB = 00
ID/EX
The second ALU operand comes from the
register file
ForwardB = 10
EX/MEM
The second ALU operand is forwarded
from the prior ALU result
ForwardB = 01
MEM/WB
The second ALU operand is forwarded
from data memory or an earlier ALU
result
Data Hazards
Load-Use Hazard
 There is a case where forwarding will not solve our problems,
as the load will not resolve until the last clock cycle in the
pipeline, while the subsequent instruction needs the
information in the previous cycle.
 Therefore, we must stall the pipeline in order to let the load
instruction to “catch up”
Load-Use Example
Hazard Detection Unit
Bubble Control Flow Chart
Handling the Bubble
Inserting the Bubble
Control Hazards
 Branch (beq)
 Two paths that can be taken, uses a statement that checks which
branch will be taken.
 (Think of an “if” statement in Java, or C.)
 Jump (j)
 Always “jumps” to a different location in the code.
Control Hazards
Flush Logic
 Because there are two options in a branch, we assume the
branch will not be taken. If the branch is taken we must
remove the instructions that have entered the pipeline.
 We do this with a “flush” where we turn all values in the
pipeline into nop.
Flush Logic
Questions?