Memory Locality and Hierarchy Co-Design — Review Checklist

Review gate

1. Locality KPIs include bytes/op, not only hit rate.

2. Tile and layout policy validated on representative kernels.

3. Bandwidth headroom tracked for peak and concurrent scenarios.

4. Coherency side traffic measured and bounded.

Smoke check (5 minutes)

• Every checklist item has an owner

• Failed items have owner, mitigation, and decision record

Definition of done for a senior owner

1. The exact workload, model/RTL tag, counter setup, and analysis window are recorded.

2. The primary metric is clean, improved, or accepted as a documented product tradeoff: Hierarchy locality efficiency report.

3. The change is explained by mechanism, not by architecture folklore.

4. Regression coverage includes the obvious downstream domains: NoC sizing, DRAM policy, and thermal compliance..

5. Residual risk has an owner, approval path, and expiration date.

6. The lesson is captured as a methodology guardrail if it can recur.

Smoke check (5 minutes)

• Could another engineer reproduce the conclusion from the notes alone?

• Would you sign this off if the design came from another team?

Review visual

TRADEOFF MATRIX — Memory Locality and Hierarchy Co-Design

+----------------------+----------------------+----------------------+----------------------+
| Option               | Helps                | Can hurt             | Validation needed    |
+----------------------+----------------------+----------------------+----------------------+
| Larger / wider block | peak perf, miss rate | area, power, timing  | workload sweep       |
| Smarter policy       | hit rate, QoS, IPC   | verification risk    | corner cases + PMU   |
| More buffering       | latency tails, stalls| deadlock, leakage    | stress traffic tests |
| Software contract    | locality, ordering   | portability, APIs    | production workload  |
+----------------------+----------------------+----------------------+----------------------+

Senior rule: pick the smallest change that proves or disproves the mechanism.

Architecture deep dive

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

Concept 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

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.

Study notes

Re-read this topic with one concrete workload.