Computer Architecture · All levels

Hazards and Forwarding Networks — Interview Drills

Interview Drills for Hazards and Forwarding Networks (Pipeline Fundamentals).

Interview drills

Practice aloud for Pipeline Fundamentals → Hazards and Forwarding Networks. Use METRIC → HYPOTHESIS → FIX → REGRESSION.

Why can an aggressive forwarding network still hurt performance?

diagram

[INT][ARCH][TOPIC]

Q: Why can an aggressive forwarding network still hurt performance?

A:
Extra mux levels and control complexity can lengthen critical paths, forcing lower frequency or added stages that erase bubble savings.

FOLLOW-UP TRAP: Assuming forwarding is always net-positive.

How do you separate true RAW hazards from false dependencies?

diagram

[INT][ARCH][TOPIC]

Q: How do you separate true RAW hazards from false dependencies?

A:
Use physical register tags and rename map history to verify whether source and destination refer to the same live version.

FOLLOW-UP TRAP: Reasoning only from logical register names.

What evidence is required before removing a stall rule?

diagram

[INT][ARCH][TOPIC]

Q: What evidence is required before removing a stall rule?

A:
Proof from trace/property checks that no stale operand can be consumed plus benchmark data showing meaningful CPI improvement.

FOLLOW-UP TRAP: Removing stall based on one microbenchmark.

10+ year interview answer bar

At senior/principal level, the interviewer is testing ownership judgment more than vocabulary. Answer Hazards and Forwarding Networks through failure mode, evidence, tradeoff, and release decision.

You inherit a late-stage Hazards and Forwarding Networks failure one week before release. What do you do in the first hour?

diagram

[INT][ARCH][STAFF]

Q: You inherit a late-stage Hazards and Forwarding Networks failure one week before release. What do you do in the first hour?

A:
Freeze the workload/model/RTL tag, name the failing metric (Hazard stall + forwarding correctness dashboard), confirm counter setup, cluster the issue by structure or workload phase, assign the first experiment, and publish a validation/owner plan before changing architecture.

FOLLOW-UP TRAP: Jumping directly to a larger cache, wider pipe, or extra NoC link without preserving evidence.

When would you stop trying to improve Hazards and Forwarding Networks and escalate?

diagram

[INT][ARCH][STAFF]

Q: When would you stop trying to improve Hazards and Forwarding Networks and escalate?

A:
Escalate when the remaining risk crosses ownership boundaries, consumes shared margin, changes signed-off assumptions, or threatens Compiler scheduling assumptions, DV reference model alignment, and post-silicon debug time are directly impacted.. Bring exact report lines and options, not vague concern.

FOLLOW-UP TRAP: Escalating without data or continuing alone after a cross-team decision is needed.

Whiteboard diagram to draw

diagram

VISUAL MODEL — Pipeline Fundamentals / Hazards and Forwarding Networks

        workload / trace
              │
              ▼
   metric symptom (Hazard stall + forwarding correctness dashboard)
              │
              ▼
     likely microarchitectural mechanism
              │
      ┌───────┼────────┐
      ▼       ▼        ▼
  pipeline  memory    fabric/coherency
  stalls    misses    queues / ordering
      │       │        │
      └───────┼────────┘
              ▼
        bounded design change
              │
              ▼
   validation workload + PPA regression

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