Is pipeline bubbling only used with RAW data hazards?

Question

I am studying computer science at university and we have an exam, which consists of several problems, one of which has to deal with pipelines.

My understanding is that one effective way to solve data hazards is to use pipeline bubbling - adding NOPs in order to stall the pipeline long enough to finish the operation, from which we will fetch the result.

Where my problem lies is conflicting information, regarding when we use bubbling. My professor's lectures state that bubbling is used to solve data hazards, no exceptions, while Wikipedia states that bubbling is used only with the RAW data hazard.

We have had some examples, which have left me very confused.

For example, we have the following operations:

S1: ADD R2,2,R1 ; R1 = R2 + 2

S2: SUB R1,R3,R4 ; R4 = R1 - R3

S3: MULT R5,3,R3 ; R3 = R5 * 3

S4: MULT R3,2,R3 ; R3 = R3 * 2

I have identified the following data hazards:

1. RAW - S1 and S2, S3 and S4
2. WAR - S2 and S3
3. WAW - S3 and S4

I have been told that I need a minimum of two operations between data hazards, which means that I need to add two NOPs between them.

My question is this - do I add NOPs between the RAW data hazards only (between S1 and S2 and S3 and S4) or do I add two between the WAR hazard as well(S2 and S3)?

Answer 1

The question is not well detailed. Because, without knowing depth of the pipe, ISA, in order vs out order is crucial for the answer. However, to answer the question: RAW hazards can be mostly solved with NOPs (the number of NOPs is dependent on your design of the pipeline, and it is compiler/hardware's responsibility to either to insert bubbles in software or hardware level). However, when you learn about forwarding units, you will understand that most RAW hazards can be easily solved by forwarding the up-coming written value of the register to the next instructions if needed.

Now WAR or WAV hazards can or can not be solved by bubbles. It seems confusing already but the idea of inserting bubbles does not guarantee that S2 will happen to read the "correct" value of R3. That is why general idea is to make sure in hardware level R3 is "saved/remembered" but not written into register file, until S2 is completed. Therefore, we create a new hardware module called hazard unit that deals with these types of problems.