Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
11Activity
0 of .
Results for:
No results containing your search query
P. 1
Pipeline Hazards Part 2

Pipeline Hazards Part 2

Ratings:

4.0

(1)
|Views: 610|Likes:
Published by BravoYusuf
1. Structural Hazard
2. Data Hazard
3. Control Hazard

Detection and Stalls also included in this document.
1. Structural Hazard
2. Data Hazard
3. Control Hazard

Detection and Stalls also included in this document.

More info:

Published by: BravoYusuf on Oct 21, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/19/2012

pdf

text

original

 
CS-421 Parallel Processing BE (CIS) Batch 2004-05Handout_6.2
Page - 1 - of 3
Pipeline Hazards (Part –
II
)
The previous handout (Handout_6.1) described
data hazards
involving only R-type instructions. Now we examine
data hazards involving loads/stores
.
StoresCase-ICase-IIRemarks
 
Each MIPS instruction writes to at most one register. This makes the forwarding hardwareeasier to design, since there is only one destination register that ever needs to be forwarded.
 
Forwarding is especially important with deep pipelines like the ones in all current PC processors.
Loads
Consider the following sequence of instructions:
 
The data to be
load 
ed doesn’t come from memory until the
end 
of cycle 4.
 
But the
and 
needs that value at the
beginning 
of the same cycle!
 
CS-421 Parallel Processing BE (CIS) Batch 2004-05Handout_6.2
Page - 2 - of 3
o
 
This is a “true” data hazard—the data is not and cannot be available when weneed it.
 
The easiest solution is to
stall
 the pipeline.
 
We could delay the
and 
instruction by introducing a one-cycle delay into the pipeline,sometimes called a
bubble
.
 
 Notice that we’re
 still using forwarding 
in cycle 5, to get data from the MEM/WB pipelineregister to the ALU.
 
Clearly without forwarding, we’d have to stall for 
two
cycles to wait for the
lw
instruction’swrite-back stage.
 
In general, you
can always stall to avoid hazards
 —but dependencies are very common in realcode, and stalling often can reduce performance by a significant amount.
 
If we delay an instruction, we’ll have to delay the following one as well.
 
One way to
implement a stall
is to force the two instructions after 
lw
to pause and remain intheir ID and IF stages for one extra cycle.
 
This is easily accomplished.
 
Don’t update the PC, so the current IF stage is repeated.
 
Don’t update the IF/ID register, so the ID stage is also repeated.

Activity (11)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Divya Sree liked this
BravoYusuf liked this
cris89 liked this
mrlog1 liked this
Roms Senpai liked this
radiancez liked this
Tuuba Karakas liked this
gloveguard liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->