Question

I’m trying to understand the basic concepts of hazards in pipelines. I know how pipelines are implemented but I’m not sure how the hazards affect the efficiency of pipelines.

I’ve read about it online but I couldn’t really understand it due to the language complexity used in explaining them. Can anyone explain them in simpler terms?

Example : The effects of Branch behavior ? (couldn’t find a simple explanation with a diagram that illustrates how the hazard works )

Answer 1

I dont think there is much to it. Think about what pipelining is or means or how it makes things faster/better. It is like an assembly line at manufacturing plant. Instead of having a single place where the whole car is built and you have to move the tools and materials to the car and move other tools out of the way you move the car through the plant. Each step along the way one little thing is done.

The branch problem is simple. Say there are 12 instructions in the pipe, some branches wont be determined until the end or near the end of the pipe. If the branch is taken then you have a bunch of instructions in the pipe you are cannot execute, you have to discard them. You restart the pipe with the branch destination and you have to wait a number of instruction cycles to get the pipeline back up to full operation.

And there have been many approaches to solve the problem, some have branch shadows, instructions that execute after a branch no matter what. Others are branch prediction, guessing at what the branch destination might be and independently fetching some instructions from those alternate paths, like the defer slots, you save a couple of cycles perhaps but if/as your pipelines get longer from one generation to the next (without an instruction set change to match) you still have to basically flush the pipe.

I/O is our biggest problem now not the cpu, pipelines were invented to solve a problem when the cpu was the bottleneck. branch prediction for example, causing random looking fetch cycles make the I/O problem worse not better…

The wikipedia link that Simon provided also talks about other hazards like read before write. If the source code says to write a location, then after writing read it back, that is what the code needs to have happen. If the compiler and architecture of the hardware, etc cause that not to happen the way it was written the software can crash/fail. The problem can come from parallel execution, if the read and write are split up into different execution units and the read execution unit has less stuff in it or whatever executes the read before the execution unit with the write happens, there is your problem. This can just as easily happen outside the cpu core but within the memory or cache system as well. The read and write can be on separate paths within the memory controller one causing a cache line read, the other finding its way into the end of the line in a write buffer, and the read can happen first. Writes are usually fire and forget, here is the address, here is the data, and the messenger takes the message and you are done. Just like dropping a package off at FedEx, here is the box with the address, my part is done but the box really doesnt get delivered for days. A read you have to wait for the result to come back, which can be, well IS, significantly longer for the execution unit be it in the cpu or the memory controller. This all has to be managed at the system level, you may solve the read before write problem in the parallel cpu only to have the memory system you tied it to not work as you expected, just because the write instruction hit the memory system before the read you think you have won the battle. This is why solutions like a defer slot often end up being filled with nops. (system engineering when it involves programming languages and humans writing that code needs to include the humans and their way of doing things).

These hazards, esp as described by the wikipedia link

http://en.wikipedia.org/wiki/Hazard_(computer_architecture)

Are cases where pipelining, used to improve the throughput, fails to deliver the right product on the output.

Say your pipeline is automobiles, each step along the assembly line puts one thing on the car, say the windshield or wheels or the engine mated to the chassis, etc. We now have decades worth of “just in time” supply and on that on this assembly line. but there is a natural disaster in some country that affects the supply of blue paint to the world, and the assembly line that produces the doors that feed the assembly line that produces the car has run out of blue doors. What do you do with the blue cars in the line? Not unlike getting a data abort on a read cycle, you have to stop the pipe, call the abort handler and be able to return to execute starting at the affected instruction or the one that follows.

Whatever you can think of that really happens that causes the pipeline design to not work, is a pipeline hazard. Yes, I agree that something in the memory system causing a system level failure is not the pipelines fault and not a pipeline hazard. The same as a compiler bug that put the instructions in the wrong place/order is not the pipelines fault either. System failure, not pipeline failure.