Control lines can be divided into five groups based on the five stages.
1. IF : Nothing to control.
control signals for reading Instruction Memory
and writing PC are always asserted (1).
2. ID: Nothing to control.
control signal of reading Register File is always asserted (1).
3. EX:
RegDst: select the destination field
ALUOp : 00 lw,
sw
01 beq
10 R-format
11 immediate instructions
ALUSrc: select data for the second input to ALU
4. MEM:
Branch : asserted for branch instruction only, such as beq
MemRead: asserted for lw instruction only
MemWrite: asserted for sw only
5. WB:
RegWrite: asserted for lw and R-format
MemtoReg: select value to write back to Register File
Step 2 : setup the control values. Since pipelining the datapath
does not
change the meaning of control signals, the same control values in
single-cycle MIPS processor can be used. In pipelined datapath, nine
control signals can set to those values for each instruction.
Step 3 : Where to put the control unit?
Since control lines start with the EX stage, the control signals are
needed
to create during ID.
Fig.6.29 shows nine control signals
are used in the last three stages as the
instruction moves down the pipeline.
Pipeline registers have to be extended to include the control lines.
Four
control lines are used in the EX stage. The remaining five control
lines
pass on to the EX/MEM pipeline register. Three are used during the
MEM stage, and the last two are passed to MEM/WB pipeline register
for use in the WB stage. Fig. 6.30 shows
the datapath with control.
lw
$10, 20($1)
sub
$11, $2, $3
and
$12, $4, $5
or
$13, $6, $7
add
$14, $8, $9
This example had been used as one test example in the exercise design
of
pipelined datapath and control.
Figs. 6.31, 6.32, 6.33, 6.34, 6.35 are
multiple clock pipeline diagrams
that show how five instructions go through the
pipelined datapath.
It takes 9 clock to execute 5 instructions. By
examining these five figures
that label the pipeline execution including control,
you could understand
more about pipelined datapath and knows how to
debug your design
in case there are mistakes in your design.
Data Hazards: an instruction depends on the results of a previous instruction
still in the pipeline.
Example 1 :
add
$s0, $t0, $t1
sub
$t2, $s0, $t3
In the example, the second instruction is dependent on the result
in $s0 of the first instruction:
if $s0 = -5 before add
$s0 = 8
after add
then the value 8 should be used in the second
instruction sub.
Time
Execution
Time CC1 CC2
CC3 CC4
CC5 CC6
order
add $s0, $t0, $t1
IF ---ID---EX---MEM--WB
value in $s0 -5 -5 -5 -5 -5/8 8
sub $t2, $s0, $t3 IF ---ID---EX---MEM---WB
For sub instruction, the value in $s0 has to be read in its ID stage
(CC3).
However, the value in $s0 in CC3 is still -5 and not the correct value
8. We can only have the correct value in $s0 at the end of clock 5
(CC5).
Another definition of Data Hazards:
dependencies that "go backward in time" are
data hazards. For example,
in the Example 1, data dependency (data in
$s0) goes backward from
CC5 to CC3.
Software solution:
Compiler can insert two independent instructions
or two "nop" instruction
between add and sub
to make hazard disappear.
add
$s0, $t0, $t1
nop
nop
sub
$t2, $s0, $t3
nop: no operation. In MIPS, "nop" represents
sll $0, $0, 0, which shifts register 0
left 0 bits.