Stalling and Flushing in MIPS Piplining

Question

I am learning MIPS data path with piplining and I am a little confused in the following two things?

How do we perform Stall in MIPS data path?

What is the difference between Stall and Flush?

Here is the data path:

Answer 1

A pipeline "stall" simply means that the values flowing through the pipeline are not valid, because the current operation needs a data value that is still propogating through the pipeline. This is normally implemented by a special bit that flows through the pipeline along with the rest of the control fields that inhibits updating any permanent state (register and memory write operations). The control logic at the head of the pipeline recognizes when these data dependencies occur, and sets/resets that bit accordingly, and repeats the same operation when/until the required data is available.

The forwarding logic can eliminate many potential stalls by "short circuiting" the normal pipeline delays and providing results from within the pipeline at the point where they're needed.

A pipeline "flush" is required whenever global state information needs to be changed that will affect the processing of all instructions. You can think of it as a stall that lasts for the full depth of the pipeline. All pending operations are completed before any new operations are launched into the pipeline. "Global state" would include things like the program counter or cache/MMU settings.

One significant cause of a pipeline flush is any conditional branch. Until the control logic knows which way the branch is going to go, no new instructions can be processed. Many methods have been invented to mitigate the effects of conditional branches, including "branch delay slots" that are filled with instructions that get executed regardless of the branch direction and "speculative execution" that executes instructions on one or both of the potential branch paths (sometimes combined with "branch prediction" logic), with the results later discarded for the path not taken.

Sometimes, no hardware support for data dependencies is implemented at all, and the burden is entirely on the compiler to schedule operations, inserting NOPs where necessary, to avoid them. Interestingly, this was the approach used by the first versions of the MIPS architecture, but later implementations have introduced hardware support.

Answer 2

It's curious you should ask this about the MIPS in particular. MIPS stands for Machine without Interlocking Pipeline Stages - which is to say, it was designed to prevent pipeline stalls completely. Even the flush required while branching was optimized away by implementing a delay slot, which means the instruction following a branch will be executed whether or not the branch was taken. If I'm not mistaken, there was also a memory load delay slot, which meant the instruction right after a load could not access the result from the load. If a stall was really necessary (presumably because of a high latency memory load), the control unit would simply have to feed NOPs through the pipeline.

In principle, pipeline stalls can be performed by lowering clock enable for the registers at some pipeline stages, and flushes (invalidations) by masking write enables (rendering the instructions in the pipeline ineffective).