Modern SoC Design · Presentation 03

Memory Hierarchy
in ML Accelerator SoCs

SRAM bitcells · Cache design · DRAM fundamentals · DDR5 · LPDDR5/6
GDDR7 · HBM3/3E/4 · CXL memory · Roofline model · Memory-wall analysis
SRAMCache HBMCXL BandwidthLatency RooflineDRAM
Navigate: ← → or swipe  |  Overview: Esc  |  PDF: append ?print-pdf
02

Why Memory Dominates ML Performance

The Memory Wall
Compute throughput has grown at ~3× per generation; DRAM bandwidth grows at ~1.4×. The gap compounds — modern ML accelerators are almost always memory-bandwidth-bound, not compute-bound.
  • Transformer attention: bandwidth scales O(n²) with sequence length
  • LLM auto-regressive decode: each token must reload all model weights
  • CNN inference: activation maps dominate SRAM pressure
  • Sparsity extraction saves FLOPs but not necessarily bytes transferred
  • Quantisation (INT8/INT4) reduces model size — primary memory-wall mitigation
Compute Mem BW Generation Relative Gap
Compute vs Memory Bandwidth Scaling
70%+
of LLM inference time is
memory access, not compute
03

On-Chip SRAM

Bitcell design · 6T / 8T / HD / LP · Voltage scaling · Yield & assist circuits

04

SRAM Bitcell Architectures

Standard 6T Cell
  • 2 cross-coupled inverters (4 transistors)
  • 2 access transistors (pass gates)
  • Read / write share same bitlines → contention
  • Area: ~0.021 µm² at TSMC N3E
  • Used in L1/L2 caches and SRAM cuts
8T Cell (Read-Decoupled)
  • Separate read port (2 extra transistors)
  • Eliminates read-disturb → lower Vmin
  • +20–30% area vs 6T; preferred for L1 data
  • Read SNM independent of cell ratio
HD (High Density) & LP (Low Power)
  • HD: minimum-area, for L3 / LLC / eDRAM pockets
  • LP: wider transistors, higher Vmin margin → retention SRAM, register files
  • ML accelerators use HD for scratchpad (bulk area)
Key SRAM Metrics for ML SoCs
  • Bandwidth: ports × width × frequency
  • Vmin: min voltage for retention & access (power gating depth)
  • Leakage: bitcell × array size – dominates idle power
  • Yield: 6σ targeting, assist circuits (negative BL, WL boost)
~70%
die area in large ML
SoCs is SRAM
<1ns
L1 SRAM cycle
time at 1GHz+
05

SRAM Voltage Scaling & Assist Circuits

At advanced nodes (N5, N3) device mismatch increases dramatically. Bitcell failure rate rises exponentially as supply voltage falls. Assist techniques restore margin:

Write Assist
  • Negative bitline (NBL) pull-down
  • Wordline boost (VWL > VDD)
  • VDD collapse during write
Read Assist
  • Virtual VSS (raised source)
  • Replica bitline sensing
  • Self-timed sense amplifiers
SRAM Compiler & Characterisation
Memory compilers (ARM, Cadence, TSMC internal) generate timing/power models (Liberty) and layout (GDS). Monte Carlo SPICE verifies yield targets across PVT corners. ML SoCs integrate multi-port SRAM cuts (1RW, 2RW, 1R1W) tiled to form large banks.
No assist With assist VDD → low Bit-cell failure rate Vmin new Vmin
Assist circuits lower effective Vmin
50–100mV
Vmin reduction from
write-assist techniques
06

Cache Design

Set-associativity · Replacement · Write policy · Scratchpad vs cache

07

Cache Fundamentals for ML SoCs

Organisation
  • Direct-mapped: simple, fast, high conflict miss rate
  • N-way set-associative: N candidates per set; LRU/PLRU/random replacement
  • Fully associative: maximum flexibility, CAM cost limits size
  • ML: 4–16 way typical for shared L2/L3
Write Policy
  • Write-back + write-allocate: dominant; minimises DRAM traffic
  • Write-through: simple coherency; used for I/O coherent agents
  • Non-temporal stores bypass cache (streaming write)
ML Workload Cache Behaviour
  • Weight matrices: large, streaming access → cache unfriendly
  • Activations: moderate reuse, fit well in scratchpad
  • Attention KV: grows with context length, spills to HBM
  • Hardware prefetch critical: stride, stream detectors
Scratchpad vs Hardware Cache
  • Scratchpad (SPM): software-managed SRAM, explicit DMA
  • Predictable latency; no tag overhead; zero conflict miss
  • Most ML NPUs use SPM + small hardware cache for CPU code
  • Google TPU: 8 MB on-chip SRAM scratchpad per chip
08

The ML Accelerator Memory Pyramid

Register File L1 Cache / SPM 32–256 KB · ~1 ns L2 Cache / Large SPM 256 KB–8 MB · ~5 ns L3 / Shared LLC 8–512 MB · ~20 ns HBM / GDDR / LPDDR 16 GB – 3+ TB · ~100 ns · TB/s CXL / Far Memory · NVMe ~10 TB/s ~5 TB/s ~2 TB/s ~1 TB/s ~3.35 TB/s <200 GB/s
Capacity vs Bandwidth Tradeoff
Moving down the pyramid: capacity grows by 100–1000× per level; bandwidth drops by 2–10×; latency increases by 5–100×.
ML mapping principle: Hot activations & accumulation buffers → SPM/L1. Weight tiles & KV-cache → L2/LLC. Full model & long-context → HBM. Cold model shards, checkpoints → CXL/NVMe.
1000×
latency ratio: register
file → HBM
09

DRAM Fundamentals

1T1C cells · Bank organisation · Timing parameters · DDR evolution

10

DRAM Architecture & Timing

1T1C Bitcell
  • One access transistor + storage capacitor (~10–30 fF)
  • Much smaller than SRAM — enables GB-scale density
  • Charge leaks → periodic refresh required (64ms / bank)
  • Destructive read → sense amp must rewrite
Bank & Rank Organisation
  • DRAM row = 8–16 KB; entire row activated per access
  • Row buffer (open-page policy): hit/miss/empty
  • Multiple banks allow pipelining (bank-level parallelism)
  • DDR5: 8 banks × 4 bank groups per die; 32 banks per rank
Key Timing Parameters
ParamMeaningDDR5 ~
tRCDRAS→CAS delay (row activate)14 ns
CLCAS latency (read cmd→data)14 ns
tRPRow precharge time14 ns
tRASRow active minimum time33 ns
tFAW4-activate window15 ns
tREFIRefresh interval per row3.9 µs
ML Scheduler Implications
Memory controllers for ML SoCs use bank-aware scheduling and row-buffer locality policies to maximise page-hit rate on weight matrix streaming patterns. DRAM ECC (on-die ECC + SECDED at interface) adds latency but is mandatory at datacenter.
11

DDR5 & LPDDR5/6

DDR5 — Server & Workstation
  • Data rates: 4800 – 8800 MT/s (JEDEC); 2× sub-channels (32-bit each)
  • On-die ECC: 1-bit error correction per 128-bit burst
  • Decision feedback equalisation (DFE) at receiver
  • Power management: PMIC on DIMM, 1.1 V VDD
  • ~89.6 GB/s peak per channel (DDR5-8800)
  • ML server: 8 × DDR5 channels = ~700 GB/s (Intel Gaudi 3)
LPDDR5 / LPDDR5X / LPDDR6
  • Edge AI SoCs: Apple M-series, Qualcomm Snapdragon, MediaTek Dimensity
  • LPDDR5X: 8533 MT/s; Apple M4 Pro ~273 GB/s, M4 Max ~546 GB/s, M3 Ultra ~800 GB/s (unified)
  • LPDDR6: 10.67–14.4 Gbps (JEDEC JESD209-6, Jul 2025); dual sub-channel, 32 B access granularity, enhanced security
  • Deep power-down, partial array self-refresh → edge efficiency
  • Package-on-package (PoP) or co-packaged with SoC die
StandardPeak RateBW / chVoltageTarget
DDR5-64006400 MT/s51 GB/s1.1 VServer
DDR5-88008800 MT/s70 GB/s1.1 VServer
LPDDR5X8533 MT/s68 GB/s1.05 VEdge
LPDDR614.4 Gbps~115 GB/s0.8–1.05 VEdge, AI
Why not DDR for large ML SoCs?
DDR bandwidth per pin is lower than HBM/GDDR because it operates at lower data rates and uses narrower interfaces (64/72 bits per channel vs HBM's 1024-bit stack interface). PCB routing limits channel count.
16×
More bandwidth pins
HBM vs DDR5
12

GDDR7 — Graphics & Edge Inference

GDDR7 Architecture
  • Up to 32–36 Gbps per pin (JEDEC JESD239); PAM3 signalling replaces NRZ
  • 32-bit bus per die; multiple dies per package (256-bit typical for GPUs)
  • NVIDIA RTX 5090: 28 Gbps × 512-bit = 1.79 TB/s peak
  • On-die ECC; improved thermal design vs GDDR6X
  • Lower power per bit than GDDR6X despite higher rate
GDDR7 vs GDDR6X
  • PAM3: 3 levels, encoded for ~1.5 bits/symbol (lower SNR penalty than PAM4)
  • ~1.6× bandwidth improvement per pin
  • Lower supply voltage: 1.1 V → 1.0 V
  • Better signal integrity with DFE + CTLE
When to use GDDR7
  • Desktop GPU / workstation ML
  • Cost-sensitive inference accelerators
  • Scenarios where HBM interposer cost is prohibitive
  • Lower capacity ceiling vs HBM (24–32 GB max)
GDDR6 512 GB/s GDDR6X 1 TB/s GDDR7 1.79 TB/s HBM3E 3.35 TB/s * Typical flagship config GDDR: 512-bit bus HBM3E: 6-stack H200 / 8-stack B200
36 Gbps
GDDR7 peak pin rate
(JEDEC JESD239)
13

High Bandwidth Memory

HBM3 · HBM3E · HBM4 · TSV stacking · Thermal challenges

14

HBM Architecture — TSV Stacking & Interface

3D DRAM Stacking via TSV
  • 4–16 DRAM dies stacked on base logic die; 55 µm TSV pitch (HBM3)
  • 1024-bit wide interface per stack → massive BW at low per-pin rate (~2 Gbps)
  • Eliminates PCB routing: SoC + HBM on shared silicon interposer (CoWoS-S)
  • Base die: PHY, voltage regulation, RAS (repair / redundancy)
  • Pseudo-channel architecture: 2× 512-bit channels per stack
HBM3
  • 6.4 Gbps/pin
  • 819 GB/s per stack
  • 16–24 GB capacity
  • NVIDIA H100 SXM (5 active stacks)
HBM3E
  • 9.6 Gbps/pin
  • 1.23 TB/s per stack
  • 24–36 GB capacity
  • NVIDIA H200, B200, B300; AMD MI325X, MI350X, MI355X
HBM4
  • 8 Gbps/pin (JEDEC JESD270-4, Apr 2025)
  • Up to 2 TB/s per stack
  • 2048-bit interface
  • Vendor parts 10–11+ Gbps; mass production Q1 2026
DRAM Die 4 DRAM Die 3 DRAM Die 2 DRAM Die 1 Base Logic Die (PHY) TSVs (1024-bit bus) µ-bumps to interposer
4.8 TB/s
H200 aggregate HBM3E
(6 stacks × 0.8 TB/s)
15

HBM Thermal, Power & Packaging

Thermal Challenges
  • HBM stacks: 85–150 W aggregate per GPU package
  • Heat must flow laterally through silicon interposer to SoC cooler
  • Limited thermal conductance through µ-bump array
  • Junction temperature limit: 85°C (DRAM junction), throttling above
  • Thermal interface material (TIM) between die top and lid critical
HBM Interposer & Packaging
  • CoWoS-S: SoC + HBM stacks on passive Si interposer (TSMC)
  • CoWoS-L: larger interposer enables more HBM stacks (H100 SXM)
  • Samsung HBM-PIM: Processing-in-Memory (GEMV in base die)
  • SK Hynix GDDR-in-HBM: HBM4 aims for 3D integration with SoC
HBM4 — Next Generation
  • 2048-bit interface per stack (2× HBM3)
  • Target: 2 TB/s per stack, 4+ TB/s aggregate
  • Hybrid bonding to SoC die (eliminates interposer for some configs)
  • Sub-1 pJ/bit target vs ~3 pJ/bit for HBM3E
  • SK Hynix, Samsung, Micron all in qualification (2025–26)
ProductHBMStacksAgg BWCapacity
NVIDIA H100 SXMHBM353.35 TB/s80 GB
NVIDIA H200HBM3E64.8 TB/s141 GB
AMD MI300XHBM385.3 TB/s192 GB
Google TPU v5eHBM2e41.6 TB/s16 GB
16

CXL Memory & Memory Pooling

CXL.mem · Type 3 devices · Memory disaggregation · Fabric switches

17

CXL Memory Expansion & Pooling

CXL.mem — Memory Semantic Protocol
  • CXL 2.0+: Host-managed Device Memory (HDM) — CPU can directly load/store
  • Latency: ~150–250 ns (PCIe 5/6 + CXL device latency) vs ~80 ns for local DDR5
  • Bandwidth: up to ~128 GB/s per PCIe 5.0 ×16 link; PCIe 6 doubles this
  • Type 3 device: dedicated memory expander (no compute) — MemVerge, Samsung CMM-H
  • Type 2 device: compute + memory coherent (e.g. GPU with CXL)
Memory Disaggregation for ML
  • LLM models exceed single-node HBM capacity (e.g. 1.8T param model = 3.6 TB)
  • CXL fabric switch: multiple hosts share a pool of DDR5/HBM memory modules
  • Near-memory compute in CXL device reduces data movement
  • CXL 3.0/3.1: peer-to-peer coherency; CXL 3.2 (Dec 2024) adds CHMU, Meta-bits, enhanced TSP; CXL 4.0 (Nov 2025) on PCIe 7.0 PHY
Software Stack
  • Linux NUMA: CXL memory appears as NUMA node; numactl placement
  • Tiered memory: hot pages on DRAM, cold pages on CXL (TPP kernel feature)
  • PyTorch / CUDA Unified Memory: transparent CXL integration in progress
Host A (GPU) HBM 192 GB Host B (GPU) HBM 192 GB CXL 3.x Fabric Switch PCIe 6 ×16 links CXL Memory Pool DDR5 / HBM CXL Type 3 2–8 TB pooled CXL.mem
8 TB
CXL pool per fabric switch
shared across multiple hosts
18

Roofline Model — Visualising Memory Bottlenecks

Roofline Fundamentals
  • Arithmetic Intensity (AI): FLOPs per byte of DRAM traffic
  • Memory-bound: Performance = AI × Peak_BW   (left of ridge)
  • Compute-bound: Performance = Peak_FLOPs   (right of ridge)
  • Ridge point: AI = Peak_FLOPs / Peak_BW
Typical AI Workloads
OperationArithmetic IntensityBound
GEMM (large batch)100–1000 FLOP/BCompute
GEMV (batch=1, LLM decode)0.5–2 FLOP/BMemory
Attention (prefill, long ctx)20–80 FLOP/BMixed
Elementwise (ReLU, layernorm)<1 FLOP/BMemory
FlashAttention (fused)↑ 10–50×Compute
Compute Roof BW Roof Arithmetic Intensity (FLOP/B) → Performance → GEMV Attn GEMM Ridge
Roofline: performance vs arithmetic intensity
Key insight: LLM decode (batch=1) operates at <2 FLOP/B — always memory-bound. Batching raises AI and shifts the operating point right toward the compute roof.
19

Memory Technology Bandwidth Landscape

Bandwidth at three scopes — on-chip (per-SM / per-tile), per-package (all DRAM stacks aggregated), and off-package (per link). Colour-coded by memory family: register file / SRAM / HBM / GDDR / LPDDR / DDR / CXL.

On-chip — per SM / per tile
Register File (per SM)
~10+ TB/s per SM
L1 SRAM / SPM (per tile)
~5 TB/s per tile
Per package — all DRAM aggregated
HBM4 (8 stk)
~16 TB/s (Rubin target, 2026)
HBM3E (8 stk)
~8 TB/s (B200 / B300)
HBM3E (6 stk)
~4.8 TB/s (H200)
HBM3 (5 stk)
~3.35 TB/s (H100 SXM)
GDDR7 (512-b board)
~1.79 TB/s (RTX 5090)
LPDDR6 unified (1024-b @ 14.4 Gbps)
~1.8 TB/s (projected M-Ultra class)
LPDDR5X unified (1024-b @ 6.4 Gbps)
~800 GB/s (Apple M3 Ultra)
DDR5 (8-channel socket)
~700 GB/s (Gaudi 3 host)
LPDDR6 mobile (4ch × 128-b)
~230 GB/s
LPDDR5X mobile (4ch × 128-b)
~136 GB/s
Off-package — per link
CXL 3.x (×16, per dir)
~128 GB/s per link
Reading the chart: scopes are not interchangeable. Per-tile SRAM figures apply inside one SM/tile; per-package DRAM figures sum across all stacks/channels on the package; CXL is quoted per x16 link, per direction. Compare within a scope, not across.

Takeaway: On-chip SRAM delivers 10–100× more bandwidth per tile than any off-chip DRAM per-package aggregate. The ML SoC architect's core challenge is staging data across this hierarchy — prefetching weights, double-buffering activations, and fusing operations to maximise locality.
100×
SRAM bandwidth
advantage over HBM
20

Memory Systems in Production ML SoCs

NVIDIA H100 / H200
  • L1: 256 KB / SM; L2: 50 MB shared
  • HBM3 (H100 SXM): 5 active stacks (6 sites; H100 NVL enables all 6 for 96 GB), 3.35 TB/s, 80 GB
  • HBM3E (H200): 6 stacks × 24 GB, 4.8 TB/s, 141 GB
  • HBM3E (B200 / B300): 8 stacks, 8 TB/s, 192 GB / 288 GB
  • NVLink 4: 900 GB/s bidirectional
  • Transformer Engine: FP8 weight loading
AMD MI300X
  • 3.5D: 8× XCDs (CDNA3 compute) hybrid-bonded onto 4× IODs; 8× HBM3 stacks on interposer
  • 192 GB HBM3; 5.3 TB/s aggregate
  • Infinity Cache: shared L3 across dies
  • AMD's answer to fitting large LLMs per node
Google TPU v5p
  • HBM2e: 95 GB, 2.76 TB/s per chip
  • Software-managed SPM: no hardware cache
  • XLA compiler handles all prefetching
  • ICI (Inter-Chip Interconnect): 4.8 Tbps mesh
Apple M3 Ultra (Edge Inference)
  • LPDDR5X: 192 GB unified memory, 800 GB/s
  • No discrete DRAM boundary — CPU/GPU/ANE share
  • ANE: 32-core Neural Engine (~36 TOPS; 2× M3 Max), 48 MB system-level cache
  • Enables 70B parameter LLM on-device
21

Memory Optimisation Techniques

Software / Algorithmic
  • Quantisation: INT8/INT4 halves/quarters weight traffic
  • FlashAttention: fused kernel, O(n) HBM reads vs O(n²)
  • KV cache compression: grouped-query, multi-query attention
  • Paged attention (vLLM): non-contiguous KV pages
  • Tensor parallelism: shards weights across HBM stacks
  • Weight streaming: offload to CPU DDR, fetch on demand
Hardware / Microarchitecture
  • Prefetch engines: stride / stream / PC-based
  • Double buffering: overlap compute with DMA
  • Memory-side cache: near-HBM SRAM tag buffer
  • Compressed sparse format: NVIDIA A100 2:4 sparsity
  • Near-memory compute: PIM in HBM base die
  • Bank interleaving: distribute weight rows across banks
Co-design principle: Compiler (XLA, TVM, Triton) must be memory-hierarchy-aware — tile sizes, prefetch distances, and fusion decisions should be tuned to the specific SRAM capacity and HBM bandwidth of the target SoC.
22

Summary

On-Chip SRAM
6T/8T bitcells, assist circuits, HD vs LP flavours. ~70% die area in large ML SoCs. Vmin engineering enables power gating.
Cache & Scratchpad
Hardware cache vs software SPM tradeoffs. ML NPUs favour SPM + DMA for predictable latency and zero tag overhead.
HBM Family
1024-bit TSV interface, 3.35–4.8+ TB/s aggregate. HBM4 targets 2 TB/s/stack with hybrid bonding to SoC.
CXL Memory
Disaggregated pooling for TB-scale LLMs. ~150–250 ns latency; PCIe 6 to ~256 GB/s per link.
The Unifying Principle: ML SoC memory architecture is a bandwidth optimisation problem across five decades of capacity. The roofline model quantifies where each operator sits; the solution space spans bitcell design, packaging, compiler fusion, and algorithmic compression.
Up Next in the Series
  • 04 · High-Speed SerDes & I/O
  • 05 · AI / ML Accelerator Architectures
  • 06 · SoCs for ML Inference
References
  • JEDEC: JESD79-5 (DDR5), JESD235 (HBM3), JESD239 (GDDR7)
  • Patterson & Hennessy, Computer Architecture, 6th ed.
  • Williams et al., "Roofline," CACM 2009
  • Dao et al., "FlashAttention-2," ICLR 2024
  • NVIDIA H100/H200 Architecture White Papers
  • AMD MI300X Architecture Guide, 2024
  • SK Hynix HBM3E & HBM4 Product Briefs
  • CXL Consortium: CXL 3.2 (Dec 2024) / CXL 4.0 (Nov 2025) Specifications
Modern SoC Design · Presentation 03

Memory Hierarchy
in ML Accelerator SoCs

Part of an open series exploring modern SoC design end-to-end.
All presentations available at brendanjameslynskey.github.io/SoC

SRAMCache HBM3/3E/4CXL RooflineDDR5 GDDR7LPDDR5/6
Navigate: ← → or swipe  |  Overview: Esc  |  PDF: append ?print-pdf to URL