Structural hazards: Question bank — Hardware deep dive

Before diving in, one anchor you will need repeatedly. A structural hazard = two pipeline stages want the same physical hardware in the same clock cycle. Not order of data (Data Hazards), not a branch decision (Control Hazards) — pure resource contention.

Definition Local legend — the 5-stage pipeline

A classic instruction moves through five stages, one per clock cycle. Picture five workers on an assembly line, each doing one job on a passing car:

IF (Instruction Fetch) — read the instruction from memory.
ID (Instruction Decode) — figure out what it means, read source registers.
EX (Execute) — the ALU does the arithmetic/logic.
MEM (Memory access) — read or write data memory (only loads/stores use this heavily).
WB (Write Back) — store the result into a register.

The whole idea (see Pipelining Fundamentals) is that while one instruction is in EX, the next is in ID, the one after in IF, and so on — five instructions overlapping. Look at figure s01 for this overlap, and notice where two of those stages both reach for memory in the same column.

Definition The three symbols in the CPI formula

To read the performance math you need three plain quantities. Anchor them to figure s02, which draws the pipeline timeline with one inserted bubble.

CPI = Cycles Per Instruction — on average, how many clock cycles each finished instruction cost. Ideal = $1.0$ (one instruction finishes every cycle).
$p$ = the probability a hazard occurs per instruction — a fraction between $0$ and $1$ . If one instruction in four collides, $p = 0.25$ .
$s$ = the stall penalty, i.e. how many extra clock cycles (bubbles) each collision forces. A single-port memory clash costs $s = 1$ ; a slow multi-cycle unit can cost more.
$f_{mem}$ = the fraction of instructions that are loads or stores. It's just $p$ for the specific case of the memory-port hazard, since only load/store instructions reach the MEM stage to fight IF for the port.

Formula Why

$CPI_{actual} = 1 + p \times s$ Step 1 — the baseline. With no hazards, one instruction completes every cycle, so the first term is $1$ . Step 2 — count the wasted cycles. Out of every instruction, a hazard strikes with probability $p$ . When it strikes, the pipeline freezes the younger instruction and inserts $s$ bubbles — $s$ cycles doing no useful work. Step 3 — average over all instructions. The expected extra cycles per instruction is (chance it happens) $\times$ (cost when it happens) $= p \times s$ . This is just a weighted average: instructions that don't collide add $0$ , those that do add $s$ . Step 4 — add them. Total cost per instruction = baseline + average stall = $1 + p \times s$ . That's the whole formula: $CPI_{actual} = 1 + p \times s$ For the memory hazard, substitute $p = f_{mem}$ and $s = 1$ to get $CPI_{actual} = 1 + f_{mem}$ .

True or false — justify

A structural hazard can occur even if every instruction is completely independent of the others

True. Structural hazards are about hardware, not data. Five independent instructions can still collide on a single memory port because they occupy different stages simultaneously.

If a pipeline has a structural hazard, it must also have a data hazard

False. They are orthogonal. A memory-port conflict happens regardless of whether the instructions share any register values.

Adding more pipeline stages always increases the chance of a structural hazard

False, not "always". More stages means more instructions in flight, so more opportunities for collision — but the actual hazard depends on how many share a given resource. Deep pipelines with well-separated resources can be hazard-free.

The Harvard architecture completely eliminates the single-memory-port structural hazard

True for that specific hazard. Separate instruction and data memories mean IF (Instruction Fetch) and MEM (Memory access) never fight over one port. Other structural hazards (single ALU, one write port) can still exist — see Memory Hierarchy.

A structural hazard raises the CPI above 1.0

True whenever it actually causes a stall. Each inserted bubble is a cycle where no instruction completes, so

CPI_{actual} = 1 + p \times s > 1

(with

p

the hazard probability and

s

the stall penalty).

Compiler instruction reordering can always remove a structural hazard

False. Reordering only helps when independent instructions exist to move. If two forced-adjacent instructions both need the scarce resource, no schedule avoids it — hardware duplication is the only fix.

A superscalar processor is more prone to structural hazards than a scalar one

True in principle. Issuing several instructions per cycle demands more read/write ports and functional units at once, so Superscalar Processors must add hardware precisely to keep structural hazards away.

Structural hazards can be detected purely at compile time

False in general. Whether two stages actually collide depends on runtime timing (cache misses, variable-latency units), so hardware interlock logic is usually needed to detect and stall.

A stall (bubble) inserted for a structural hazard advances the pipeline's useful work

False. A bubble is a deliberate NOP — it holds later stages idle so the resource frees up. It burns a cycle by design.

If a processor has zero structural hazards, its CPI is guaranteed to be 1.0

False. Data and control hazards can still add stalls. Zero structural hazards only removes one source of CPI inflation.

Spot the error

"We have two structural hazards because instruction I2 depends on I1's result."

The error is calling a dependency a structural hazard. Depending on a previous result is a data hazard. Structural = shared hardware, not shared data.

"Our pipeline stalls whenever two instructions use the ALU in different cycles, so it's a structural hazard."

Using the same unit in different cycles is exactly what a pipeline is supposed to allow — no conflict. A hazard needs the same cycle. There is no hazard here.

"Adding a second write port to the register file will fix our load-use data hazard."

Wrong hazard. Extra write ports cure a structural write-back collision. A load-use stall is a data hazard and needs forwarding or a stall, not more ports.

"Since we have separate I-cache and D-cache, we can never stall the pipeline."

Separate caches kill one structural hazard (IF vs MEM memory port). Cache misses, data hazards, and control hazards can all still stall the pipeline.

"A structural hazard costs exactly one cycle, always."

The penalty

s

depends on the resource. A single-cycle resource costs one bubble (

s = 1

), but a multi-cycle unit (e.g. a non-pipelined divider) can force several stall cycles (

s > 1

"Using the ALU to compute PC+4 is fine because branches are rare."

PC+4 happens on every instruction fetch, not just branches. Sharing the main ALU for it collides with the EX (Execute) stage constantly — that's why a cheap dedicated PC incrementer is added.

"Structural hazards go away if we just run the clock slower."

A slower clock changes cycle time, not the fact that two stages want one resource in the same cycle. The conflict — and the stall count — is unchanged.

Why questions

Why do designers ever tolerate a structural hazard instead of just duplicating the hardware?

Because duplication costs silicon area, power, and design complexity. In embedded/low-power chips an occasional stall is cheaper than a second memory port or extra ALU.

Why does a single unified memory cause a hazard but split I/D caches don't?

A unified memory has one access port; IF (fetch) and MEM (data access) both want it in the same cycle. Split caches give each stage its own port, so there is no shared resource to fight over.

Why is a structural hazard fundamentally a "hardware count" problem rather than a "program logic" problem?

It arises from having fewer instances of a resource than the number of stages needing it simultaneously. The instructions could be totally logically unrelated — the shortage is physical.

Why can two register reads and one register write usually happen in the same cycle without a hazard?

Because the standard register file is built with 2 read ports and 1 write port. The hardware supplies exactly that combination, so it's provisioned, not contended.

Why does increasing the fraction of load/store instructions raise the stall rate for a single-port memory design?

In the CPI model stalls

= f_{mem} \times s

, where

f_{mem}

is the fraction of load/store instructions. More memory instructions means higher

f_{mem}

, so more cycles where MEM collides with IF over the one port.

Why is "schedule the instructions differently" a limited solution?

It only works when there are independent instructions to reorder around the conflict. Data dependencies and back-to-back resource demands can leave no legal reordering that avoids the clash — a limit tied to Instruction-Level Parallelism.

Why do we insert a bubble on the later stage rather than the earlier one?

The earlier (younger) instruction is the one that can safely wait; letting the older instruction keep its resource preserves correct program order and drains the pipeline forward.

Edge cases

What is the structural hazard situation in a non-pipelined single-cycle processor?

None. With one instruction executing at a time, no two stages overlap, so nothing can contend for a resource. Structural hazards are a pipelining phenomenon — see Pipelining Fundamentals.

If a pipeline is only 2 stages deep, can it still have a memory structural hazard?

Yes, if both stages touch the same single-port memory in one cycle (e.g. fetch + data access). Depth doesn't have to be large — even two overlapping stages sharing one resource suffice.

Zero-load-store program: does a single-port unified memory still cause any structural hazard?

Yes — instruction fetch alone still hits memory every cycle, but with no MEM-stage data accesses there's no second claimant, so in practice no collision occurs. The hazard needs two simultaneous claims.

What happens to CPI in the limiting case where every instruction triggers a one-cycle structural stall?

CPI = 1 + p \cdot s

with

p = 1, s = 1

gives

CPI = 2.0

— the pipeline effectively halves its throughput, doing one useful instruction every two cycles.

Can two structural hazards on different resources stall the same instruction in the same cycle?

The instruction stalls until both resources are free, but a single bubble covers a single cycle; the total stall is the maximum wait, not the sum, if the resources free up in overlapping cycles.

Degenerate case: infinite hardware (a port/unit per stage) — what is the structural-hazard CPI contribution?

Zero. With every stage owning its own dedicated resource, no two stages ever contend, so structural stalls vanish and this term of

CPI_{actual}

drops out entirely.

Recall One-line self-test

A friend says "we got a stall, so it's definitely a structural hazard." What's the missing step? ::: Identify why: shared hardware = structural, waiting on a value = data, waiting on a branch = control. A stall alone doesn't name its cause.