Computer Architecture · All levels

Cache Debug and Coherency Triage — Extended Case Study

Extended Case Study for Cache Debug and Coherency Triage (Memory Hierarchy).

Extended case study

A review is called because a workload regresses after a Cache Debug and Coherency Triage change.

Background

A stable baseline existed until a Memory Hierarchy change improved one benchmark and regressed a product workload on Coherence replay storm diagnostic report.

Symptoms observed

  • Regression in Coherence replay storm diagnostic report

  • Sim vs silicon disagreement

  • Pressure to revert or ship risk

Investigation timeline

  1. Freeze tags

  2. Reproduce

  3. Cluster

  4. Experiment

  5. Validate

  6. Memo

Root cause

A hidden assumption in Cache Debug and Coherency Triage failed under an unrepresented workload phase.

Fix and validation

  • Reproduce on controlled firmware build with fixed power-state sequence.

  • Capture coherence transaction traces around first replay storm onset.

  • Validate protocol invariants (single owner, ordering, ack completion) against logs.

  • Compare affected and unaffected clusters for state-machine divergence.

  • Deploy minimal fix and rerun power-transition regression plus long soak.

Lessons learned

  • Workload coverage beats clever microarchitecture

  • Every change needs rollback triggers

diagram
CACHE DEBUG TRIAGE
chip_stepping: C0
workload: io_stress_lp_exit
ipc_drop_pct: 31
llc_mpki: 12.3 -> 19.8
coherence_replay_events_per_ms: 142 -> 911
invalidation_broadcast_rate_khz: 18 -> 73
avg_mem_latency_ns: 129 -> 241
action: investigate stale directory state after LP restore; add protocol invariant trace trigger

Architecture deep dive

Cache hierarchy trades area and power for AMAT and bandwidth.

Concept diagram

diagram
MEMORY HIERARCHY

Core
 ├─ L1I / L1D  (cycles: 1-4, tiny, latency critical)
 ├─ L2         (cycles: 8-20, private or cluster)
 ├─ LLC / SLC  (shared, bandwidth + coherency point)
 ├─ NoC        (queueing + arbitration)
 └─ DRAM/HBM   (large penalty, high energy)

AMAT = hit_time + miss_rate × miss_penalty
But senior analysis also asks: MLP, bandwidth, QoS, and tail latency.

Metric graph

diagram
MISS PENALTY WATERFALL

L1 hit          ██  3 cyc
L2 hit          ████████  12 cyc
LLC hit         ███████████████  32 cyc
DRAM miss       ████████████████████████████████████  180 cyc

Small MPKI can still dominate if miss penalty is huge.

Metrics and artifacts

  • MPKI per level

  • L2/L3 bandwidth utilization

  • replacement policy stats

  • prefetch accuracy

Mini case study

Doubling L2 size reduces capacity misses but IPC improves only 3% because conflict misses dominate a shared workload. Fix data layout and false sharing before more SRAM.

Debug branches

  • If MPKI high but bandwidth low, footprint may exceed capacity.

  • If bandwidth saturated, coherency or DMA may be the real limit.

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.