Pipeline Hazards

This chapter asks a sharp question: since the two-phase overlap puts two transfers in flight at once, does it create hazards — the data, structural, and control hazards familiar from processor pipelines? The answer is illuminating: AHB avoids all three by construction. It is in-order with a single access path (no data hazards), uses separate address and data buses (no structural hazard from the overlap), and handles the one real control hazard — a transfer pipelined behind one that errors — with the two-cycle error response and an IDLE cancel. Understanding why AHB is essentially hazard-free deepens your grasp of the pipeline and sharpens the contrast with out-of-order interconnects like AXI, which must actively manage hazards. This is an Advanced chapter that ties the module's timing knowledge to a higher-level view.

1. What Is It?

A pipeline hazard is a situation where the overlapping of operations in a pipeline could produce incorrect behaviour if not handled. The classic three (from processor pipelines) are:

• Data hazard — an operation depends on the result of a previous one that has not completed (e.g., a read of a location a previous, not-yet-complete write was modifying).
• Structural hazard — two overlapping operations need the same resource at once.
• Control hazard — an operation was pipelined (speculatively begun) but should not proceed (e.g., behind a transfer that errors).

Because AHB's overlap puts two transfers in flight (one in its data phase, the next in its address phase), each of these could in principle arise. AHB's design avoids all three:

• Data hazards → avoided by in-order, single-path operation. Transfers complete in issue order on one access path, so a read after a write sees the write's result.
• Structural hazards → avoided by separate address and data buses. The overlapping address phase and data phase use different wires, so there is no resource conflict.
• Control hazards → avoided by the two-cycle error response + cancel. When a transfer errors, the pipelined next transfer is cancelled (the master drives IDLE), like a branch-flush.

The essence: AHB is a simple, in-order, two-stage pipeline, and its design eliminates the hazards the overlap could create. This is a deliberate simplicity — AHB does not need the hazard-management machinery (transaction IDs, ordering rules, forwarding) that a more aggressive, out-of-order pipeline requires, because its in-order single-path structure sidesteps the hazards entirely.

2. Why Does It Exist? (Why AHB is hazard-free)

The hazard-freedom exists because AHB's pipeline is deliberately simple — in-order, single-path, two-stage — and that simplicity removes the conditions that create hazards.

Why no data hazards. Data hazards arise when operations can complete out of order or when multiple are outstanding such that a later one might use a stale result. AHB has neither property: it processes one access path at a time, in issue order (chapters 2.5, 5.1). So when a write is followed by a read of the same location, the write's data phase completes before the read's data phase begins (in order, on the same path) — the read sees the write's result. There is no reordering to create a read-before-write hazard, and no outstanding-transaction tracking needed. The in-order single-path design means data dependencies are naturally respected: later transfers see earlier transfers' effects because they happen later, in order. (Caveats: across different subordinates, or with write buffering that completes a write asynchronously, software-visible ordering needs care — but the bus itself is in-order.)

Why no structural hazards from the overlap. A structural hazard would arise if the overlapping address phase and data phase needed the same resource. They do not: the address phase uses the address/control bus and the data phase uses the data bus — separate sets of wires (chapters 2.1, 3.7). So transfer A's data phase (on the data bus) and transfer B's address phase (on the address bus) coexist without conflict. The separate-bus design — chosen partly to avoid turnaround — also prevents the structural hazard the overlap would otherwise create. The overlap is conflict-free precisely because the two phases use different resources.

Why the control hazard is handled. There is one genuine hazard: when a transfer errors, the next transfer's address phase is already on the bus (pipelined) — a transfer was speculatively begun that, given the error, should not proceed. This is a control hazard, analogous to a branch misprediction. AHB handles it with the two-cycle error response (chapter 3.9): the first error cycle warns the manager while the bus is held, giving it the chance to cancel the pipelined next transfer (drive IDLE) before it commits. So the control hazard is resolved by a flush-like mechanism — the wrongly-pipelined transfer is cancelled. This is the one hazard AHB actively manages, and the two-cycle error exists precisely for it.

So AHB is hazard-free because its in-order single-path simplicity removes data hazards, its separate buses remove structural hazards, and its two-cycle-error-plus-cancel handles the one control hazard. The hazard-freedom is the reward of the simple pipeline — and the contrast with complex, hazard-managing pipelines (out-of-order, multiple outstanding) is exactly the AHB-vs-AXI distinction.

3. Mental Model

Model AHB's hazard-freedom as a single-lane drive-through where cars are served strictly in order.

In a single-lane drive-through (one access path), cars are served strictly in the order they arrive (in-order). So there is no chance a later car gets its order before an earlier one (no data hazard — if car 2 depends on car 1's order being done, it is, because car 1 went first). The order-taking window and the pickup window are separate (separate buses), so taking car 2's order while car 1 picks up its food causes no conflict (no structural hazard). And if car 1's order fails (errors), the attendant tells car 2 — who had just started ordering — to hold off (cancel via IDLE) before car 2 commits (control hazard handled). The single lane, strict ordering, and separate windows make the whole thing orderly and hazard-free; the only active handling is telling the next car to stop when the current one fails.

Watch a read-after-write to the same address (the canonical data-hazard test) come out correct:

The model's lesson: single lane, strict order, separate windows — orderly and hazard-free. The waveform shows read-after-write to X returning the written value D, because the write completed before the read's data phase (in-order). No reordering means no data hazard; the only thing AHB actively does is cancel a transfer behind an error.

4. Real Hardware Perspective

In hardware, AHB's hazard-freedom comes from the absence of the structures that create hazards, plus the one mechanism (two-cycle error) for the control hazard.

For data hazards, the key hardware fact is that AHB has no out-of-order machinery and no multiple-outstanding tracking: there is one access path, and transfers happen in issue order. So a subordinate processes accesses to its locations in the order they arrive, meaning a write's effect is in place before a subsequent read of the same location's data phase. There is no need for forwarding (bypassing a not-yet-written result) or hazard detection logic, because the in-order completion guarantees the dependency is satisfied by ordering. This is dramatically simpler than a CPU pipeline's hazard unit — AHB simply does not have the conditions that require one.

For structural hazards, the hardware fact is the separate address and data buses (chapters 2.1, 3.7). The overlap (A's data phase + B's address phase in one cycle) uses two distinct wire sets, so there is no shared resource for them to contend over. If AHB had used a single shared bus for both address and data, the overlap would create a structural hazard (both transfers wanting the one bus), and the pipeline would not work — which is part of why the buses are separate. So the separate-bus design is what makes the overlap structurally conflict-free in hardware.

For the control hazard, the hardware mechanism is the two-cycle error response (chapter 3.9) and the master's cancel. When a subordinate errors, the first error cycle (ERROR with HREADY low) gives the master a cycle to react while the bus is held; the master, seeing the error, drives the next (already-pipelined) transfer to IDLE — cancelling it. So the wrongly-speculated transfer is flushed before it commits, exactly as a branch misprediction flushes the speculatively-fetched instructions. This is the one piece of active hazard management in AHB, and the two-cycle error exists for it. In hardware, the master's error-handling logic implements this cancel.

The hardware contrast that makes this vivid: an out-of-order interconnect (AXI) does have the structures that create hazards — multiple outstanding transactions, out-of-order completion — so it needs hazard-management machinery: transaction IDs to track and order responses, ordering rules to define what is guaranteed, and more. AHB, being in-order and single-path, needs none of this. So the hardware difference is stark: AHB's simplicity buys hazard-freedom at the cost of concurrency; AXI's concurrency requires active hazard management. This is the AHB-vs-AXI tradeoff seen through the lens of hazards.

5. System Architecture Perspective

At the system level, AHB's hazard-freedom means simpler reasoning about ordering — but with important caveats around multiple subordinates and buffering that software must respect.

For accesses to a single subordinate, AHB's in-order guarantee means ordering is simple: accesses take effect in issue order, so a write followed by a read of the same location returns the written value. So software writing to and reading from a single subordinate (a memory, a peripheral) can rely on program-order semantics on the bus — no surprises from reordering. This simplicity is a real benefit: AHB's in-order nature makes the common case (ordered accesses to a subordinate) behave intuitively, without the ordering subtleties of out-of-order systems.

The caveats are where system-level care is needed. Across different subordinates, or with write buffering (the bufferable attribute, chapter 3.6) that completes a write asynchronously, software-visible ordering can be looser than strict program order — a buffered write may complete after a subsequent access, and accesses to different subordinates may not have a defined relative completion order beyond the bus's in-order issue. So while the bus is in-order, the system (with buffers and multiple subordinates) may require barriers or careful ordering for cross-subordinate dependencies. This is the system-level nuance: AHB's bus-level in-order simplicity does not by itself guarantee all system-level ordering once buffering and multiple targets are involved.

The control-hazard handling (error-cancel) is a system-level robustness feature: it ensures that when an access errors, a speculatively-pipelined following access does not erroneously commit. So the system's error handling is clean — an error cleanly stops the pipeline rather than letting a wrong access through. This matters for correctness when errors occur (a fault, a protection violation): the two-cycle error + cancel ensures the error is contained and the next access is not wrongly performed. So at the system level, AHB's hazard handling contributes to clean error semantics.

The broadest system-level point is the hazard-free-by-simplicity character of AHB, contrasted with AXI. AHB's in-order single-path design makes it simple to reason about and verify (few hazards to consider), at the cost of the concurrency that would require hazard management. AXI's concurrency (multiple outstanding, out-of-order) delivers higher performance but requires the system to reason about ordering, IDs, and hazards explicitly. So the choice between AHB and AXI is, in part, a choice between hazard-free simplicity and hazard-managed concurrency — and understanding AHB's hazard-freedom clarifies exactly what AXI's complexity buys. This is the system-level framing the chapter delivers.

6. Engineering Tradeoffs

AHB's hazard-freedom is a consequence of its simplicity, and the tradeoffs are about simplicity versus concurrency.

• In-order single-path (hazard-free) vs out-of-order (concurrent). AHB's in-order single path avoids data hazards entirely, making it simple to reason about and verify, at the cost of concurrency (one access path, no multiple outstanding). Out-of-order, multiple-outstanding designs (AXI) achieve concurrency but must manage data hazards with IDs and ordering rules. The trade is hazard-free simplicity versus hazard-managed concurrency — the core AHB-vs-AXI distinction.
• Separate buses (no structural hazard) vs shared (cheaper, but hazardous). Separate address/data buses prevent the overlap's structural hazard, at the cost of more wires. A shared bus would be cheaper but could not support the overlap (structural hazard). AHB spends the wires to make the pipeline work — the same trade as elsewhere.
• Two-cycle error (control-hazard handling) vs single-cycle. The two-cycle error response handles the control hazard (cancel the pipelined transfer) at the cost of a cycle on errors. A single-cycle error could not give the cancel opportunity. AHB pays the cycle (errors are rare) for clean control-hazard handling.
• Simplicity vs performance. Overall, AHB trades the performance of a concurrent, hazard-managing pipeline for the simplicity of a hazard-free in-order one. For its target (moderate-bandwidth embedded), this simplicity is the right choice — less logic, easier verification, intuitive ordering. Where concurrency is needed, AXI's added complexity (and hazard management) is justified.

The throughline: AHB's hazard-freedom is the dividend of a deliberately simple in-order, single-path, separate-bus pipeline, with the one control hazard handled by the two-cycle error. The tradeoff is concurrency: AHB forgoes it to stay hazard-free and simple, while concurrent interconnects accept hazard-management complexity for performance. Understanding this is understanding why AHB is easy and where its ceiling is.

7. Industry Example

Trace AHB's hazard-freedom through scenarios, and the one hazard it handles.

• Read-after-write, single subordinate (no data hazard). A processor writes a value to a memory location, then reads it back. The write's data phase completes (storing the value) before the read's data phase begins, because AHB is in-order on a single path. So the read returns the written value — the dependency is satisfied by ordering, with no forwarding or hazard logic. This is the common case, and it "just works" because of in-order completion.
• The overlap, no structural hazard. While the write's data phase is happening, the read's address phase is on the bus (the overlap). They coexist without conflict because the write data is on HWDATA and the read address is on the address bus — separate wires. No structural hazard; the overlap is conflict-free by the separate-bus design.
• A transfer behind an error (the control hazard, handled). A processor issues an access that errors (say a protection violation), with another access already pipelined behind it. The two-cycle error response warns the processor in the first error cycle; the processor cancels the pipelined next access by driving IDLE. So the access behind the error does not wrongly commit — the control hazard is handled by the cancel, like a branch-flush. This is the one hazard AHB actively manages, and it ensures clean error semantics.
• The cross-subordinate caveat. Now a processor writes to subordinate A (a buffered region) then reads from subordinate B, depending on the write having completed. Because the write to A may be buffered (completing asynchronously) and B is a different subordinate, the read from B might proceed before the write to A actually lands — a system-level ordering subtlety the bus's in-order property does not by itself resolve. The fix is a barrier or making the write non-bufferable where ordering matters. This shows the caveat: bus-level in-order does not guarantee all cross-subordinate ordering.
• The AXI contrast. On an out-of-order AXI fabric, the read-after-write and ordering scenarios would require transaction IDs and ordering rules to manage — the hazards AHB avoids by being in-order are present in AXI and must be actively handled. So the same scenarios that "just work" on AHB require explicit ordering machinery on AXI. This is the concrete payoff of AHB's hazard-free simplicity — and the cost (no concurrency) that pushes high-performance systems to AXI's managed complexity.

The scenarios show AHB's hazard-freedom in action: read-after-write ordered by construction, the overlap conflict-free by separate buses, the error control-hazard handled by cancel — with the cross-subordinate/buffered caveat as the one place system-level care is needed.

8. Common Mistakes

9. Interview Insight

This Advanced topic tests whether you understand why AHB is hazard-free and the contrast with concurrent interconnects.

The answer that lands names the three classes and AHB's avoidance, plus the AXI contrast: "The phase overlap puts two transfers in flight, which could create the classic hazards, but AHB avoids all three by construction. Data hazards — it's in-order on a single path, so transfers complete in issue order and a read sees a prior write; no reordering, no hazard. Structural hazards — the overlapping address and data phases use separate buses, so no resource conflict. Control hazards — when a transfer errors, the next is already pipelined, so the two-cycle error response lets the master cancel it with IDLE, like a branch-flush. So AHB is essentially hazard-free because it's a simple in-order pipeline — unlike AXI, which is out-of-order with multiple outstanding transactions and must manage hazards with IDs and ordering rules." The by-construction avoidance and the AXI contrast are the senior signals.

10. Practice Challenge

Reason from the in-order, single-path, separate-bus design.

1. Name the three hazard classes and, for each, how AHB avoids it.
2. Explain read-after-write. Why does a read after a write to the same location see the written value, with no data hazard?
3. The overlap. Explain why the overlapping address and data phases do not create a structural hazard.
4. The control hazard. Describe the one genuine hazard and how the two-cycle error handles it.
5. Contrast with AXI. Explain why AHB is hazard-free by construction while AXI must manage hazards.

11. Key Takeaways

• The phase overlap puts two transfers in flight, but AHB avoids the classic pipeline hazards by construction.
• Data hazards → avoided by in-order, single-path operation — transfers complete in issue order, so a read sees a prior write; no forwarding or hazard-detection logic needed.
• Structural hazards → avoided by separate address and data buses — the overlapping phases use different wires, so no resource conflict.
• The one genuine hazard is a control hazard — a transfer pipelined behind one that errors — handled by the two-cycle error response plus the master cancelling with IDLE (a branch-flush analogue).
• AHB's hazard-freedom is the dividend of a simple in-order pipeline — it needs none of the hazard-management machinery (IDs, ordering rules) that out-of-order interconnects require.
• Caveat: bus-level in-order does not guarantee all system ordering — across different subordinates or with buffered writes, software may need barriers. This is the AHB-vs-AXI simplicity/concurrency tradeoff seen through hazards.

12. What Comes Next

You now understand why AHB's pipeline is hazard-free. The final Module 5 chapter brings the timing knowledge together as a reading skill:

• 5.7 — Phase Waveform Interpretation (coming next) — reading the two-phase pipeline straight off a waveform, applying the diagonal-read, the one-cycle lead, and control/data alignment — closing the module.

To revisit the pipeline structure and the mechanisms that avoid hazards, see The Two-Phase Pipeline, HWDATA & HRDATA (separate buses), and HRESP (two-cycle error). For the concurrency AHB forgoes, see Why AXI Exists. For the broader protocol map, see the AMBA family overview.