DenseChip

Computer Architecture · All levels

Pipeline Fundamentals

Senior-level pipeline fundamentals for CPU and accelerator teams: stage partitioning, hazard control, branch behavior, and production debug methodology.

Section goal

Turn pipeline tradeoffs into measurable IPC, latency, and power decisions that survive implementation and silicon bring-up.

Mechanism to narrate

  • A good pipeline is not just high frequency; it is stable under real data, control, and memory dependencies.

  • Every stage move must be justified with measurable effects on CPI stack, bubble rate, and recovery latency.

  • Use PMU + waveform correlation to separate front-end starvation from execute or memory bottlenecks.

Senior course bar for this section

  • Every topic should end with an architecture decision, not only concept recall.

  • Every fix should state expected metric movement and likely regression surface.

  • Every open assumption should have an owner, tag, and review date.

  • Every recurring issue should become a methodology guardrail or checklist item.

  1. pipeline-stages/ — Pipeline Stage Partitioning

  2. hazards-and-forwarding/ — Hazards and Forwarding Networks

  3. branch-prediction-basics/ — Branch Prediction Basics for Throughput

  4. pipeline-debug/ — Pipeline Debug in Silicon Bring-up

Related topics

Key takeaways

  • Staff-level pipeline ownership means proving mechanism with counters and regression evidence, not intuition.

  • Microarchitectural fixes must include a rollback plan and explicit downstream verification impact.

Section 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.

Practice this lesson