Day 47: Structural hazards and the hazard-detection unit
Structural hazards and the hazard-detection unit
A structural hazard is a resource conflict: two instructions want the same hardware in the same cycle. Classic example — a single memory port that both IF (fetch) and MEM (load/store) need. ChipX avoids it with separate instruction and data memories (a Harvard-style split), and a register file that writes in the first half of a cycle and reads in the second. Recognizing and designing away structural hazards is part of the datapath plan.
Tying it together is the hazard-detection unit: each cycle it checks for the load-use case (stall one cycle), drives the forwarding unit for data hazards, and triggers flushes for taken branches. It's a compact controller — comparisons of register fields plus a little state — sitting beside the datapath, deciding *stall / forward / flush* every cycle.
This is the full control story
By now you have the complete picture of a real pipeline's control: forwarding for most data hazards, one stall for load-use, flush for taken branches, and a structural-hazard-free datapath by design. Annotate all of it on your paper design — Days 43–47 are exactly the diagram the roadmap ships, and the thing you'll translate to RTL in Stage 2.
Key terms
- Structural hazard
- Two instructions needing the same hardware resource in the same cycle.
- Harvard split
- Separate instruction and data memories, avoiding the IF/MEM port conflict.
- Hazard-detection unit
- The controller deciding each cycle whether to stall, forward, or flush.
- Write-first register file
- A register file that writes in the first half-cycle and reads in the second to avoid a same-cycle conflict.
Ship for Day 47
How does ChipX avoid the classic structural hazard between instruction fetch and data memory access?
