Computer Architecture · All levels

Memory Locality and Hierarchy Co-Design

Memory Locality and Hierarchy Co-Design — computer architecture for silicon teams.

On-call / interview prompt

Accelerator core utilization is high but system energy per inference misses target. Where do you look first?

diagram
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

Co-design SRAM, cache, prefetch, compression, and tiling policies to minimize expensive off-chip movement.

Mechanism to narrate

  • Section: Accelerator Architectures

  • Primary artifact: Hierarchy locality efficiency report

  • Downstream dependency: NoC sizing, DRAM policy, and thermal compliance.

Staff/principal ownership model

Own Memory Locality and Hierarchy Co-Design 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.

diagram
STAFF ARCHITECTURE REVIEW MEMO — Accelerator Architectures / Memory Locality and Hierarchy Co-Design

1. Current state
   - Failing / watched metric: Hierarchy locality efficiency report
   - 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: Weak locality design causes power blow-ups and bandwidth starvation in field workloads.

4. Regression and signoff
   - Re-run: Hierarchy locality efficiency report
   - Must not regress: NoC sizing, DRAM policy, and thermal compliance.
   - 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

Key takeaways

  • Master Memory Locality and Hierarchy Co-Design through workload metrics, not feature lists.

Architecture deep dive

Accelerators win on locality and bandwidth contracts, not peak OPS alone.

Concept diagram

diagram
ACCELERATOR DATAFLOW

Host CPU ── commands ──► Queue / scheduler
   ▲                         │
   │ completion              ▼
Coherent memory ◄── DMA ── Local SRAM ──► Compute array
                         ▲       │
                         └ tiles ┘

Peak TOPS matters only when data reaches the array at the needed rate.

Metric graph

diagram
UTILIZATION BREAKDOWN

compute active   ██████████████████  58%
DMA wait         ██████████          31%
host sync        █████               15%
cache/coherency  ████                12%
idle bubbles     ███████             22%

Low utilization is usually a system integration problem.

Metrics and artifacts

  • accelerator utilization

  • DMA bandwidth

  • kernel launch overhead

  • coherency invalidation rate

Mini case study

NPU met TOPs target but end-to-end inference slow — DMA and weight fetch dominated. Architecture added on-chip SRAM tile and double-buffering.

Debug branches

  • If util low, check launch overhead and host sync first.

  • If BW high, examine weight layout and sparsity support.

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.