SSD Controller Architecture
The ASIC at the center of an enterprise SSD: what blocks it contains, why the compute complex looks the way it does, and how the physical constraints of 16 NAND channels + DRAM + PCIe shape the die.
!!! info "Where to find real block diagrams"
Controller vendors publish **logical block diagrams** in product briefs. They do **not** publish floorplans — the physical layout is a trade secret, and die shots of storage controllers are far rarer than for CPUs or GPUs.
The single most useful public document is the **[Marvell Bravera SC5 product brief](https://www.marvell.com/content/dam/marvell/en/public-collateral/storage/marvell-ssd-mv-ss1331-1333-product-brief.pdf)**, which shows a labeled block diagram of a real 16-channel enterprise controller. Everything on this page can be read against it. Full source list in [§10](#10-references).
1. The Canonical Block Diagram
Every enterprise NVMe controller, regardless of vendor, decomposes the same way.
┌──────────────────┐
HOST ══════════════│ PCIe Gen5 PHY │ ← SerDes, x4 or dual x2
│ + Controller │
└────────┬─────────┘
│
┌────────▼─────────┐
│ NVMe Front End │ ← queues, doorbells,
│ (host interface)│ namespaces, SR-IOV,
└────────┬─────────┘ admin/IO command parse
│
┌────────────────────────────┼────────────────────────────┐
│ │ │
┌───────▼────────┐ ┌─────────▼─────────┐ ┌─────────▼────────┐
│ SECURITY │ │ COMPUTE COMPLEX │ │ DMA ENGINES │
│ ISLAND │ │ │ │ │
│ │ │ Cortex-R cores │ │ Host ↔ buffer │
│ • Root of Trust│◄───────►│ running the FTL, │◄──────►│ buffer ↔ NAND │
│ • Secure Boot │ │ media mgmt, host │ │ │
│ • AES-256 │ │ interface │ └──────────────────┘
│ • TCG Opal │ │ │
│ • Attestation │ │ + TCM (ITCM/DTCM)│
└────────────────┘ │ + SRAM w/ ECC │
└─────────┬─────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
┌────────▼────────┐ ┌─────────▼─────────┐ ┌─────────▼─────────┐
│ DRAM Controller│ │ FLASH CONTROLLER │ │ Power Mgmt / PLI │
│ + DDR PHY │ │ │ │ (power-loss │
│ │ │ • Sequencer │ │ imminent) │
│ DDR4 / DDR5 / │ │ • RAID/parity │ └───────────────────┘
│ LPDDR4X │ │ • LDPC ECC engine│
│ │ │ • Scrambler │
│ Holds the │ └─────────┬─────────┘
│ L2P MAP TABLE │ │
└────────┬────────┘ ┌─────────▼─────────┐
│ │ NAND PHY │ ← ONFI / Toggle
┌─────▼─────┐ │ × 16 channels │
│ DRAM │ └─────────┬─────────┘
│ (DDR5) │ │
└───────────┘ ┌──────▼──────┐
│ NAND packages│
│ (8 CE each) │
└─────────────┘
2. The Compute Complex — Why Cortex-R
This is the part that connects directly to the ARM Cores page.
!!! abstract "The core argument"
An SSD's FTL lookup sits on the critical path of every single I/O. An A-profile core with an MMU can take a TLB miss, then a cache miss, and hand you a 200+ cycle stall you cannot predict. That is fatal to a P99.9 latency SLA.
**R-profile cores solve this with TCM.** The hot FTL path and the ISRs live in ITCM/DTCM — SRAM adjacent to the core, always single-cycle, no miss, no eviction. The jitter disappears because the cache disappears.
This is why enterprise SSD controllers are R-profile, and it's the cleanest real-world illustration of the determinism-vs-throughput trade that defines the profile split.
Core specialization
Modern controllers don't run one big SMP pool. They partition cores by function, because the workloads have genuinely different characteristics:
| Function | Typical core | Why |
|---|---|---|
| Host / front end | Cortex-R | NVMe queue processing, command parse. Throughput-oriented, latency-sensitive. |
| FTL / data path | Cortex-R (often several) | The L2P lookup. Must be deterministic. Lives in TCM. |
| Media management | Cortex-R | GC, wear leveling, read-disturb handling, retention. Background, but must not starve the data path. |
| Security / RoT | Separate small core | Isolated by design — see §6. |
| Power management | Cortex-M | Tiny, always-on, sequences the PLI capacitor discharge. |
Marvell Bravera SC5 is the concrete public example: 10 embedded cores — Cortex-R8 cores for the data path, plus Cortex-M7 cores, plus a Cortex-M3. Silicon Motion's SM8366 says only "Arm core complexes" and doesn't disclose the mix.
!!! tip "Core count and clock, roughly"
Current controllers run **anywhere from 1 to ~10 cores** in the **500 MHz – 1.5+ GHz** range. Consumer parts (Phison E28, SMI SM2508) are on 6nm; enterprise parts like the SM8366 are 12nm-class. More cores generally means more IOPS — but **the partitioning matters more than the count.**
3. Real Parts
| Controller | Channels | DRAM | Host | Cores (public) | Node / package |
|---|---|---|---|---|---|
| Marvell Bravera SC5 MV-SS1333 |
16 | DDR4 / LPDDR4X, 72-bit (incl. 8-bit ECC) | PCIe Gen5 x4 or dual x2 | Cortex-R8 + Cortex-M7 + Cortex-M3 (10 cores) | — |
| Marvell Bravera SC5 MV-SS1331 |
8 | same | same | same | — |
| Silicon Motion SM8366 (MonTitan) |
16 @ 2400 MT/s | DDR5-4800 / DDR4-3200, 40-bit, single/dual channel | PCIe Gen5 x4, dual-port | "Arm core complexes" (mix undisclosed) | 12nm, 21×21mm FCBGA |
| Silicon Motion SM8308 | 8 | DDR5-4800 / DDR4-3200 | PCIe Gen5 x4, dual-port | — | — |
| Microchip Flashtec NVMe 5016 | 16 | — | PCIe Gen5 x4 or dual x2 | — | — |
| Marvell 88SS1088 | 16 | up to 16 GB | — | 2 × 4 Cortex-R5 | — |
Performance envelope for the 16-channel enterprise class: ~14 GB/s sequential read, 2–3.5M random read IOPS, up to 128 TB addressable.
!!! note "Nobody ships exactly the textbook part"
A design with *DDR5 + 2× Cortex-R8 + a Cortex-R5 security island + 16 NAND channels* is a perfectly sensible architecture — but no single public part matches it exactly. Marvell gives you R8 + 16 channels + a security engine but pairs it with DDR4/LPDDR4X and uses M7/M3 for the auxiliary cores. Silicon Motion gives you DDR5 + 16 channels but won't say what the cores are.
That gap is itself informative: **core mix and DRAM generation are decoupled choices**, driven by firmware architecture and cost respectively, not by any technical coupling.
4. The NAND Interface — What "16 Channels" Buys
CHANNEL = an independent NAND bus (data + control).
The controller can drive all 16 SIMULTANEOUSLY.
THIS is where SSD bandwidth comes from.
CE (Chip Enable) = selects which package/die on that channel is active.
8 CE per channel is typical in enterprise.
CEs on one channel SHARE the bus — they take turns.
DIE = the unit the controller actually talks to.
A die can be executing a command independently → INTERLEAVING.
PLANE = within a die, 2/4/6 planes can operate in parallel
→ MULTI-PLANE operations.
Controller
│
├── CH0 ──┬── CE0 ─┬─ die ─┬─ plane
│ │ └─ die └─ plane
│ ├── CE1 ...
│ └── ... up to CE7
│
├── CH1 ──── (independent bus — runs in PARALLEL with CH0)
│
├── ...
│
└── CH15
BANDWIDTH MATH (16-channel enterprise class):
16 channels × 2400 MT/s × 1 byte = ~38 GB/s raw NAND bandwidth
…against a PCIe Gen5 x4 host link of ~16 GB/s.
The NAND side is deliberately OVER-PROVISIONED relative to the host
link. That headroom is what absorbs GC, read-retry, and LDPC
soft-decode traffic without the host ever seeing it.
Parallelism is the whole game. A single NAND die is slow — page reads are tens of microseconds, program is hundreds, erase is milliseconds. The controller hides that entirely by having 16 × 8 × (dies) operations in flight. Every architectural decision in the flash controller exists to keep that pipeline full.
5. The DRAM Subsystem — It Exists for the Map Table
!!! abstract "Why an SSD needs gigabytes of DRAM"
The **L2P (logical-to-physical) map table**. The FTL must translate every host LBA to a physical NAND location, and that table has to be fast to look up.
**Rule of thumb: ~1 GB of DRAM per 1 TB of NAND.** A 4-byte map entry per 4 KB page gives a 1:1024 ratio. A 16 TB enterprise drive therefore carries ~16 GB of DDR.
This is also why DRAM-less controllers exist (and why they're slower): they use HMB (Host Memory Buffer) or keep only a partial map cached in SRAM, and pay for it on random reads that miss the cached portion.
Design points visible in the public parts:
- Marvell Bravera SC5: 72-bit DDR4/LPDDR4X — i.e. 64-bit data + 8-bit ECC. The map table is the drive's most safety-critical structure; corrupting it loses everything, so the DRAM is ECC-protected.
- Silicon Motion SM8366: 40-bit DDR5-4800, single or dual channel — 32-bit data + 8-bit ECC, scalable.
The move to DDR5 here is about bandwidth per pin and per-DIMM channel independence (see the DDR5 page) — a 16-channel NAND back end generates enough map-table traffic to matter.
6. The Security Island
Enterprise controllers carry a hardware root of trust as a physically and logically isolated block. Public feature sets converge:
| Feature | What it does |
|---|---|
| Hardware Root of Trust | Immutable identity + key storage in silicon. The anchor for everything else. |
| Secure Boot | Firmware is signature-verified before execution. Marvell/Microchip both note dual signature authentication. |
| AES-256 | Data-at-rest encryption, inline on the data path. |
| TCG Opal | The self-encrypting-drive standard. |
| Attestation | The drive can prove its firmware state to the host — see SPDM. |
Why a separate core. The security block is given its own processor and its own memory so that a compromise of the (large, complex, frequently-updated) FTL firmware cannot reach the key material. This is the same architectural argument as Caliptra — the root of trust must be small enough to audit and isolated enough that the rest of the chip can't touch it.
A Cortex-R5 or a Cortex-M is the natural fit: small, no MMU, easy to reason about.
7. LDPC and the Flash Controller
Between the cores and the NAND PHY sits the block that does the actual media work:
- Sequencer — issues read/program/erase to the NAND, manages CE selection and interleaving.
- LDPC ECC engine — low-density parity check decoding. Marvell brands theirs NANDEdge™ v5. This is a large block; as NAND moves to QLC and higher layer counts, raw bit error rates rise and the decoder has to work harder (hard decode → soft decode → read retry).
- RAID / parity engine — die-level parity so the drive survives a NAND die failure.
- Scrambler — randomizes data before programming to reduce cell-to-cell interference.
See the LDPC page for the coding theory. The architectural point here: LDPC soft-decode is the biggest consumer of internal bandwidth and power under stress, and it's a major reason the NAND-side bandwidth is over-provisioned versus the host link.
8. Physical Reality — Why the Floorplan Looks Like It Does
!!! warning "Conceptual sketch, not a real floorplan"
No vendor publishes an SSD controller floorplan. What follows is **reasoning from constraints**, not a leaked layout. Treat it as a way to think, not as fact.
The dominant physical constraint on a controller die is that almost everything is I/O, and I/O lives at the edge:
┌───────────────────────────────────────────────┐
│ NAND PHY ×8 channels (edge-placed) │
├───────────────────────────────────────────────┤
│ │
DDR │ Flash Ctrl / LDPC Compute Complex │ P
PHY │ (wide, close to the R8 + TCM + SRAM │ C
+ │ NAND PHYs) │ I
Ctrl │ ┌──────────────┐ │ e
│ Big SRAM buffers │ Security │ │
│ │ island │ │ P
│ │ (isolated) │ │ H
│ └──────────────┘ │ Y
│ │
├───────────────────────────────────────────────┤
│ NAND PHY ×8 channels (edge-placed) │
└───────────────────────────────────────────────┘
WHY IT ENDS UP THIS WAY:
1. 16 NAND PHYs + DDR PHY + PCIe SerDes are ALL perimeter blocks.
A controller is frequently PAD-LIMITED, not gate-limited — the die
is as big as it is because of pin count, not logic.
2. The flash controller / LDPC sits adjacent to the NAND PHYs because
the buses between them are very wide.
3. PCIe SerDes gets its own quiet corner. High-speed analog next to a
switching digital core is an SI/noise problem you do not want.
4. The DDR PHY wants to be near both the compute complex (map table
lookups) and the flash controller (data buffering). It usually
loses that fight and sits on one edge.
5. SRAM is everywhere. Look at the PS5 controller die shot (§10) —
the memory banks visibly dominate.
6. Clock domains cross ALL of these boundaries: PCIe ref clock, DDR
clock, NAND channel clocks, core clock. The CDC problem here is
substantial. See the CDC page.
The estimate worth carrying: on a die like this, the ARM cores are a small fraction of the area. Using the numbers from the ARM Cores page — a Cortex-R8 is on the order of a few hundred thousand gates — even ten cores don't come close to the SRAM, the LDPC engine, and the PHYs. The CPUs are not what makes the chip big.
9. Study Checklist
Architecture
- [ ] Draw the canonical block diagram from memory: PCIe PHY → NVMe front end → compute complex → flash controller/LDPC → NAND PHY, plus DRAM and security
- [ ] Explain why the compute complex is R-profile, in terms of TCM vs. cache and P99.9 latency
- [ ] List the functional core partitions (host, FTL, media mgmt, security, power) and why they're separate
- [ ] Explain what a channel, a CE, a die, and a plane each are, and which one gives you parallelism
Numbers
- [ ] Compute raw NAND bandwidth: 16 channels × 2400 MT/s ≈ 38 GB/s
- [ ] Explain why NAND-side bandwidth is deliberately over-provisioned vs. a ~16 GB/s PCIe Gen5 x4 host link
- [ ] State the DRAM sizing rule: ~1 GB DRAM per 1 TB NAND, and derive it (4 B entry / 4 KB page)
- [ ] Explain why the DRAM interface is 72-bit or 40-bit rather than 64/32 (ECC)
Security
- [ ] Explain why the root of trust gets its own isolated core
- [ ] Name the standard enterprise security feature set (RoT, secure boot, AES-256, TCG Opal, attestation)
Physical
- [ ] Explain why an SSD controller is often pad-limited rather than gate-limited
- [ ] Explain why the LDPC engine sits adjacent to the NAND PHYs
- [ ] Explain why the ARM cores are a small fraction of the die area
10. References
Real controllers — block diagrams and specs
- Marvell Bravera SC5 (MV-SS1331 / MV-SS1333) Product Brief (PDF) — the best public block diagram of a 16-channel enterprise controller. Cortex-R8 + M7 + M3, security engine, NANDEdge™ v5 LDPC, NAND PHY, 72-bit DDR4/LPDDR4X, PCIe 5.0. Start here.
- Silicon Motion SM8366 Product Brief (PDF) — 16 channels @ 2400 MT/s, DDR5-4800, PCIe Gen5 dual-port, FDP support
- Silicon Motion MonTitan RDK Product Brief (PDF) — the reference design kit, 21×21mm FCBGA
- Silicon Motion Enterprise SSD Controllers — product line overview
- Microchip Flashtec NVMe 5016 — 16-channel, PCIe Gen5, secure boot with on-chip HW root of trust · reference validation board
ARM's reference architecture
- Arm Storage Solution for SSD Controllers (PDF) — the vendor-neutral view of how R-profile cores, the security island, and the NAND/DRAM subsystems fit together
Actual silicon
- PS5 SSD controller die shot — a Marvell part ("Titania 2"). Unannotated, and consumer rather than enterprise, but a genuine photograph of an SSD controller die. You can make out the core cluster on one side and large SRAM banks dominating the other — the best available confirmation of §8.
Industry coverage
- Tom's Hardware — Silicon Motion MonTitan SM8366 — good architectural summary
- ServeTheHome — SM8366 at FMS 2022 — package photos
Background
- Cactus Technologies — SSD Controller Block Diagram
- Cactus Technologies — Channels and Banks — the channel/CE/interleaving model behind §4
- Cadence NAND Flash Controller IP and NAND Flash PHY IP — what you'd actually license for the ONFI/Toggle interface
!!! note "On floorplans"
If you need real physical layout, the path is die-shot analysis houses — **TechInsights** and **SemiAnalysis** publish annotated teardowns. Storage controllers get far less coverage than CPUs/GPUs, and the detailed reports are paywalled.
Related pages
- ARM Cores — why R-profile, TCM vs. cache, core gate counts
- FTL — what the compute complex is actually running
- FDP — host-guided placement; the SM8366 supports it
- LDPC — the ECC engine in §7
- NAND — dies, planes, blocks, pages
- NVMe — the host interface protocol
- QoS — the tail-latency problem the whole architecture is fighting
- DDR5 — the map-table DRAM