a structural hazard

Back at the laundromat: suppose you own only one dryer. Most minutes that is fine, but there comes a minute when load 1 wants to keep drying AND load 2 has finished washing and also wants the dryer. They cannot both have it. One must wait. A structural hazard is exactly this — two instructions in different pipeline stages need the same piece of hardware in the same cycle, and there is not enough of it to go around.

The textbook case is memory. In the five-stage pipeline, the IF stage fetches an instruction from memory while, two stages back, a load or store in the MEM stage wants to read or write data memory — both in the same cycle. If the machine has a single, shared memory with one port, those two accesses collide and one must stall. The classic fix is to give the processor separate instruction and data memories (or separate caches), so instruction fetch and data access never fight — this is one reason real chips split their first-level cache into an I-cache and a D-cache, echoing the Harvard architecture. Other structural hazards arise from a register file that cannot read and write in one cycle, or a single shared functional unit.

Structural hazards are the easiest family to design away, because the cure is usually just to add hardware: a second memory port, a duplicated unit, a register file built to do two reads and one write per cycle. That is why well-designed RISC pipelines have essentially no structural hazards — they spend a little extra silicon to remove them entirely. When a structural hazard does remain (often to save area or power), the only recourse is to stall the younger instruction until the resource frees up.