Recall that our 5stage MIPS pipeline is sometimes referred t

Recall that our 5-stage MIPS pipeline is sometimes referred to as a “scalar” pipeline since at most one instruction can occupy any stage at one time. Which of the following types of hazards would this pipeline never experience and why?

a) Resource Hazard
b) Data Hazard
c) Control Hazard
d) Branch Hazard

Solution

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 lw or sw was 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. Also, the first Sparc implementations (remember, Sparc is almost exactly the RISC machine defined by one of the authors) did have exactly this hazard, with the result that load instructions took an extra cycle and store instructions took two extra cycles.

Data Hazards This is when reads and writes of data occur in a different order in the pipeline than in the program code. There are three different types of data hazard (named according to the order of operations that must be maintained): RAW A Read After Write hazard occurs when, in the code as written, one instruction reads a location after an earlier instruction writes new data to it, but in the pipeline the write occurs after the read (so the instruction doing the read gets stale data). WAR A Write After Read hazard is the reverse of a RAW: in the code a write occurs after a read, but the pipeline causes write to happen first. WAW A Write After Write hazard is a situation in which two writes occur out of order. We normally only consider it a WAW hazard when there is no read in between; if there is, then we have a RAW and/or WAR hazard to resolve, and by the time we\'ve gotten that straightened out the WAW has likely taken care of itself. (the text defines data hazards, but doesn\'t mention the further subdivision into RAW, WAR, and WAW. Their graduate level text mentions those

Control Hazards: This is when a decision needs to be made, but the information needed to make the decision is not available yet. A Control Hazard is actually the same thing as a RAW data hazard (see above), but is considered separately because different techniques can be employed to resolve it - in effect, we\'ll make it less important by trying to make good guesses as to what the decision is going to be. Two notes: First, there is no such thing as a RAR hazard, since it doesn\'t matter if reads occur out of order. Second, in the MIPS pipeline, the only hazards possible are branch hazards and RAW data hazards.