Controlling A Pipelined Datapath
Uploaded by
Alexander TaylorControlling A Pipelined Datapath
Uploaded by
Alexander TaylorLecture 20
Controlling a Pipelined Datapath
IF: Instruction fetch
0 M u x 1
ID: Instruction decode/ register file read
EX: Execute/ address calculation
MEM: Memory access WB: Write back
Add
4 Shift left 2 Read register 1
Add
Add result
PC
Address
Instruction Instruction memory
Read data 1 Read register 2 Registers Read Write data 2 register Write data
0 M u x 1
Zero ALU ALU result
Address Data memory Write data
Read data
1 M u x 0
16
Sign extend
32
Pipeline registers: Intermediate storage Question: how do we determine the width of the registers?
Step-by-step Execution of lw
Instruction Fetch
Step-by-step Execution of lw
Instruction Decode
Instruction Decode
Step-by-step Execution of lw
lw Execution
0 M u x 1
IF/ID
Add
ID/EX
EX/MEM
MEM/WB
4 Shift left 2
Add
Add result
Instruction
PC
Address Instruction memory
Read data 1 Read register 2 Registers Read Write data 2 register Write data
Read register 1
0 M u x 1
Zero ALU ALU result
Address Data memory Write data
Read data
1 M u x 0
16
Sign extend
32
Instruction Execution
Step-by-step Execution of lw
Memory Access
Step-by-step Execution of lw
Write Back to Register
Alternative Graphical Representation of Pipelines lw sub $10, $20($1) $11, $2, $3
Question: Are there any hazards in the code above?
Time (in clock cycles) Program execution order (in instructions) lw $10, 20($1) CC 1 CC 2 CC 3 CC 4 CC 5 CC 6
IM
Reg
ALU
DM
Reg
sub $11, $2, $3
IM
Reg
ALU
DM
Reg
Controlling a Pipelined Datapath
PCSrc
0 M u x 1
IF/ID
ID/EX
EX/MEM
MEM/WB
Add 4
RegWrite Shift left 2 Add Add result
Branch
Instruction
PC
Address Instruction memory
Read register 1
MemWrite
ALUSrc Zero Zero ALU ALU result
Read data 1 Read register 2 Registers Read Write data 2 register
Write data
MemtoReg Address Data memory Write data Read data 1 M u x 0
0 M u x 1
Instruction 16 [150]
Sign extend
32
ALU control
MemRead
Instruction [2016] Instruction [1511]
0 M u x 1
RegDst
ALUOp
10
Key Aspects to Notice in This Design:
1) Theres no need to have write controls to the PC or to the pipeline registers. 2) Fetch: nothing to control. Same thing done every clock cycle. 3) Decode: nothing to control. Same thing done every clock cycle. 4) Execution: decide how to use the ALU (operands, operation, result) RegDst, ALUOp, ALU Src. 5) Memory access: branch, load and store instructions have different requirements, so one must specify Branch, MemRead, MemWrite 6) Write back: choose what gets written back to the register file (the ALU result or a memory value); the controls are MemToReg and RegWrite. We use the same control lines as before, but group them by pipeline stage.
11
So, what has really changed?
Remember: Each instruction defines what control values are applied. Question: What happens now that I can have up to 5 instructions executing at the same time in the datapath?
WB Instruction M EX WB M WB
Control
IF/ID
ID/EX
EX/MEM
MEM/WB
All control decisions are made during the instruction decoding and are carried forward across stages in the pipeline.
12
PCSrc
0 M u x 1 Control
ID/EX
WB M EX
EX/MEM
WB M
MEM/WB
WB
IF/ID Add
4
RegWrite
Add Add result
ALUSrc
Instruction
PC
Address
Instruction memory
Read data 1 Read register 2 Registers Read Write data 2 register Write data
0 M u x 1
Zero ALU ALU result
Address Data memory Write data
Read data
Instruction16
Sign extend
32
ALU control
MemRead
Instruction
Instruction
0 M u x 1 RegDst
ALUOp
MemtoReg
1 M u x 0
Read register 1
MemWrite
Shift left 2
Branch
13
Work through the example of the execution of five instructions starting in page 471!
14
Data Hazards and Forwarding
Question: What is a data hazard?
sub and or add sw
$2, $12, $13, $14, $15,
$1, $3 $2, $5 $6, $2 $2, $2 100($2)
15
Time (in clock cycles) CC 1 Value of register $2: 10 Program execution order (in instructions) sub $2, $1, $3 IM Reg DM CC 2 10 CC 3 10 CC 4 10 CC 5 CC 6 CC 7 CC 8 CC 9
Reg
and $12, $2, $5
IM
Reg
DM
Reg
or $13, $6, $2
IM
Reg
DM
Reg
add $14, $2, $2
IM
Reg
DM
Reg
sw $15, 100($2)
IM
Reg
DM
Reg
16
Possible solution: Let the compiler resolve the hazard sub
Hardware design: Register writes always happen at the first half of the clock cycle. Register reads always happen at the second half the clock cycle. No hazard for data that is written and read in the same clock cycle.
$2,
$1,
$3
nop
bubble
nop
bubble
and or add sw
$12, $13, $14, $15,
$2, $5 $6, $2 $2, $2 100($2)
Question: What is the drawback of this solution?
17
