Hazards and Forwarding Networks

On-call / interview prompt

A forwarding optimization removed 2 cycles from producer-consumer latency in simulation, but silicon shows sporadic wrong results under vector workload bursts. Where do you start?

ARCHITECTURE ANALYSIS CHAIN

1. METRIC     — IPC, CPI, MPKI, bandwidth, latency, queue depth, stall cycles
2. HYPOTHESIS — microarch or system cause ordered by likelihood
3. EXPERIMENT — trace, PMU counter, simulation, or RTL probe
4. CHANGE      — pipeline, cache, NoC, or memory hierarchy adjustment
5. VALIDATION  — workload replay, regression suite, PPA impact

Topic overview

Design and debug RAW/WAR/WAW hazard handling plus forwarding paths that reduce bubbles without violating timing or formal correctness.

Mechanism to narrate

• Section: Pipeline Fundamentals

• Primary artifact: Hazard stall + forwarding correctness dashboard

• Downstream dependency: Compiler scheduling assumptions, DV reference model alignment, and post-silicon debug time are directly impacted.

Staff/principal ownership model

Own Hazards and Forwarding Networks as a product architecture decision, not a page of notes. A senior architect names the metric, the mechanism, the cross-team dependency, and the smallest evidence-producing experiment.

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

Sub-lessons in this topic

1. mechanism — Mechanism

2. inputs-outputs — Inputs & Outputs

3. reports — Reports & Metrics

4. debug-playbook — Debug Playbook

5. worked-example — Worked Example

6. pitfalls — Pitfalls & Red Flags

7. interview — Interview Drills

8. checklist — Review Checklist

9. theory-deep-dive — Theory Deep Dive

10. design-space — Design Space Exploration

11. case-study-expanded — Extended Case Study

12. step-by-step-walkthrough — Step-by-Step Walkthrough

13. comparison-matrix — Comparison Matrix

14. software-programmer-view — Software / Programmer View

15. silicon-ppa-impact — Silicon & PPA Impact

Related topics

• RTL scoreboard design

• OoO dependency handling

• SoC validation playbooks

Key takeaways

• Master Hazards and Forwarding Networks through workload metrics, not feature lists.

Architecture deep dive

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

Concept 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

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.