Computer Architecture · All levels

Hazards and Forwarding Networks — Worked Example

Worked Example for Hazards and Forwarding Networks (Pipeline Fundamentals).

Scenario

A product workload exposes a Hazards and Forwarding Networks issue late in architecture review.

Timeline

Metric fails at review meeting
Engineer captures metric report, trace snippet, and workload phase
Root cause traced to incorrect assumption from prior stage
Minimal architecture change or policy experiment applied and documented
Workload regression matrix re-run on the tagged model

Outcome

Architecture decision accepted with documented metric movement, risk, and validation proof.

Senior debrief

After solving the example, write the debrief a lead would expect: what changed, why it worked, what could regress, and what permanent methodology update prevents recurrence.

diagram

STAFF ARCHITECTURE REVIEW MEMO — Pipeline Fundamentals / Hazards and Forwarding Networks

1. Current state
   - Failing / watched metric: Hazard stall + forwarding correctness dashboard
   - Workload / benchmark / trace: <fill before review>
   - Model tag, RTL tag, simulator version, PMU setup: <fill before review>
   - Scope: core, cache level, NoC path, coherency domain, accelerator, or SoC budget

2. Root-cause hypothesis
   - Most likely mechanism: <name pipeline/cache/NoC/coherency/perf mechanism>
   - Competing hypothesis: <name the second plausible cause>
   - Evidence still missing: <counter, trace, waveform, model sweep, or workload slice>

3. Proposed action
   - Minimal reversible change: <microarchitecture, policy, sizing, traffic, or software contract change>
   - Expected improvement: <metric delta>
   - Regression risk: Incorrect hazard handling can create low-frequency silent data corruption that escapes directed testing.

4. Regression and signoff
   - Re-run: Hazard stall + forwarding correctness dashboard
   - Must not regress: Compiler scheduling assumptions, DV reference model alignment, and post-silicon debug time are directly impacted.
   - Decision owner: architecture owner

Before / after metric graph

diagram

METRIC TREND GRAPH — Hazards and Forwarding Networks

IPC / throughput
  ^
  |                  target
  |                 ─ ─ ─ ─ ─ ─ ─
  |            ● after bounded fix
  |         /
  |    ● baseline
  |  /
  |● failing run
  +---------------------------------> experiment index
    bad tag       hypothesis        accepted fix

Readout rule:
  - one dot is not a conclusion
  - compare against same workload, seed, model tag, and counter setup
  - explain why the fix moved the metric, not just that it moved

Architecture deep dive

Pipeline depth and width are bets on branch predictability and cache behavior.

Concept diagram

diagram

PIPELINE VIEW

Fetch ──► Decode ──► Rename ──► Issue ──► Execute ──► Memory ──► Commit
  │         │          │          │          │          │          │
  ▼         ▼          ▼          ▼          ▼          ▼          ▼
I-cache   decode     ROB/RS     wakeup     ALU/BR     LSU       retire
miss      bubbles    full       select     latency    miss      bandwidth

Every pipeline discussion should name where bubbles enter and where they retire.

Metric graph

diagram

STALL STACK EXAMPLE

cycles (%)
frontend       ██████████████  28
branch         ████████        16
backend        ████████████    24
memory         █████████       18
retire/other   ██████          12

Read this before saying "make the pipe wider."

Metrics and artifacts

IPC/CPI breakdown
stall cycles by stage
branch mispredict rate
frontend vs backend bound

Mini case study

IPC drops after widening decode but branch-heavy workload shows frontend stalls unchanged. The correct read: backend was not the bottleneck — branch prediction and fetch bandwidth need investment first.

Debug branches

If IPC flat after deeper pipeline, check branch MPKI and cache miss stalls.
If hold timing fails on critical path, architecture may need shorter pipeline stage — link PD.

Senior review question

Ask: what single metric would prove this concept is working or failing on your workload?

Key takeaways

Connect every architecture claim to a workload and measurable metric.
State verification and PPA impact before proposing design changes.

Common pitfalls

Feature-driven design without MPKI/IPC/bandwidth evidence.
Ignoring coherency and NoC traffic in cache and accelerator sizing.

Study notes

Re-read this topic with one concrete workload.

Practice this lesson