Pipeline Hazards Let's put some instructions through the pipeline, and see what happens... addi $1, $2, 17 _ _ _ _ _ add $3, $4, $5 _ _ _ _ _ lw $6, 100($7) _ _ _ _ _ sw $8, 200($9) _ _ _ _ _ That all looks fine... What sorts of things can go wrong? Let's just put a whole bunch of addinstructions in a row, and think about it. add $1, $2, $3 _ _ _ _ _ add $4, $5, $6 _ _ _ _ _ add $7, $8, $9 _ _ _ _ _ add $10, $11, $12 _ _ _ _ _ add $13, $14, $1 _ _ _ _ _ (data arrives early; OK) add $15, $16, $7 _ _ _ _ _ (data arrives on time; OK) add $17, $18, $13 _ _ _ _ _ (uh, oh) add $19, $20, $17 _ _ _ _ _ (uh, oh again) These are examples of data hazards. Defining hazards The next issue in pipelining is hazards. A pipeline hazard refers to a situation in which a correct program ceases to work correctly due to implementing the processor with a pipeline. There are three fundamental types of hazard: data hazards, branch hazards, and structural hazards. Data hazards can be further divided into Write After Read, Write After Write, and Read After Write hazards. Structural Hazards These occur when a single piece of hardware is used in more than one stage of the pipeline, so it's possible for two instructions to need it at the same time. So, for instance, suppose we'd only used a single memory unit instead of separate instruction memory and data memories. A simple (non-pipelined) implementation would work equally well with either approach, but in a pipelined implementation we'd run into trouble any time we wanted to fetch an instruction at the same time a lwor swwas reading or writing its data. In effect, the pipeline design we're starting from has anticipated and resolved this hazard by adding extra hardware. Interestingly, the earlier editions of our text used a simple implementation with only a single memory, and separated it into an instruction memory and a data memory when they introduced pipelining. This edition starts right off with the two memories.
has intentionally blurred sections.
Sign up to view the full version.