An open, rigorously sourced index of NPU/accelerator, DRAM, and storage (HDD/SSD) research and development — the technology, the standards, the history, and the economics — organized around the problem that connects them.
Wm. A. Wulf and Sally A. McKee, "Hitting the memory wall: implications of the obvious." ACM SIGARCH Computer Architecture News 23(1), March 1995, pp. 20–24. doi:10.1145/216585.216588
That paper is this project's founding document. Its argument is five pages of arithmetic: if processor speed and DRAM latency improve at different exponential rates, then average memory access time comes to dominate runtime regardless of cache hit rate. The wall follows from the growth rates alone. It is not a design mistake anyone can correct, and thirty years later it is still the organizing constraint of the field.
Compute has outrun memory, and the interesting engineering of the last two decades has happened at the seams where the three domains are deforming into each other:
- HBM — DRAM bending toward compute
- CXL and computational storage — storage bending toward memory
- Processing-in-memory — all three collapsing into one another
This is one repository rather than three because those seams are the point. Three parallel wikis for DRAM, NPUs and storage would file each of these interface technologies under one heading and hide the fact that it belongs to all of them. A shared timeline with parallel lanes makes the causality legible without prose: HBM appears in the DRAM lane exactly when the compute lane strains against GDDR; NVMe appears when SSDs outrun SATA and AHCI.
Anyone who wants to genuinely learn this domain. Right now that knowledge sits behind conference paywalls, vendor marketing, and analyst subscriptions priced for corporate procurement. Most of the underlying material is actually public — JEDEC standards are free after registration, NVM Express publishes openly, Micron publishes real datasheets, and fifteen years of academic DRAM characterisation is on arXiv — but nobody has assembled it.
Future market entrants, with an honest account of the asymmetry:
| Domain | Entry reality |
|---|---|
| NPUs / accelerators | Genuinely tractable for small teams. RISC-V, open PDKs, cheap shuttle runs. |
| SSD controllers | A real startup category, with a real if difficult path. |
| DRAM fabrication | A three-company oligopoly with roughly $15–20B fabs. Educational here, not a route to entry. |
We document all three and weight effort accordingly. We do not pretend the third is a business plan.
An index, not an encyclopedia. There are already many good introductions to DRAM, and this project will not add another. The valuable artifacts are the ones nobody has assembled:
- Sourced generation timelines — every DDR, LPDDR, GDDR, HBM, NAND/SSD interface and NVMe generation, with real spec deltas and citations.
- Annotated bibliography — the papers that mattered, one line on what each contributed, a link, and a preprint pointer. The most-cited-sources page is generated from the registry and doubles as a reading list.
- Normalized NPU comparison — with explicit per-vendor notes on how each TOPS/W claim is constructed: sparsity assumptions, precision, batch size, clock conditions. This is scarce analytical work and the reason the comparison is worth doing at all.
- Hardware development stories — the readable history nobody has written. Intel 1103 to HBM4; the Qimonda collapse and its patent estate; how Rambus litigation shaped DDR; consolidation from a dozen DRAM makers to three; the 2002–2006 price-fixing litigation, whose court record put internal industry documents into the public domain; the cost of the EUV transition.
- Knowledge boundary maps — explicit pages on what is not publicly knowable per domain, and why. In DRAM, architecture, interface, circuit design and behaviour are well documented; process integration, capacitor formation, dielectric stacks and yield learning are dark. Telling readers where the wall of secrecy actually sits is a service.
Citations are data here, not prose. They live in
sources/registry/ as one YAML record per source, with a
stable ID, a DOI or URL, an access date, a licence, and a real Wayback Machine
snapshot captured at ingestion.
This project never mirrors content. It summarizes enough to make you want the original and then hands you the DOI. Paywalled work is cited in full rather than avoided, with a pointer to the author preprint wherever one exists — for ISSCC, HPCA and ISCA papers, one usually does.
Generated prose is nearly free and therefore nearly worthless, and this domain is maximally hostile to unverified numbers. A wrong timing parameter, bandwidth figure or process node is expensive to discover and easy to propagate. The scarce input is human-verified fact.
The architecture enforces that mechanically rather than asking for discipline:
- Every content claim page declares its source IDs in front matter.
- Every source ID must resolve to a registry record.
- Every registry record must carry an access date.
- Timeline events validate against a schema and must cite at least one source.
- Links are checked, and rot is reported against the archive URL.
- Agent-extracted, unverified material lives in
quarantine/and never renders until a human moves it.
A pull request that adds an unsourced number fails CI.
The rules automated contributors work under are in AGENTS.md.
memory-wall/
├── AGENTS.md agent operating rules
├── sources/
│ ├── SCHEMA.md source record schema, documented
│ ├── source.schema.json machine-readable, used by CI and the site build
│ └── registry/ one YAML file per source
├── timeline/
│ ├── SCHEMA.md
│ ├── event.schema.json
│ └── events/ one YAML file per milestone
├── content/ site pages
│ ├── dram/ npu/ storage/
│ ├── interfaces/ HBM, CXL, PIM, computational storage
│ └── history/ hardware development stories
├── quarantine/ extracted, unverified — NEVER rendered
├── tools/ validation, ingestion, compilation
└── .github/workflows/ CI and Pages deployment
The site is built with Astro Starlight rather
than MkDocs Material, for two reasons that both come down to this project being
a data set with a documentation site attached rather than a documentation site.
First, the timeline is a real client-side component — one shared time axis,
parallel lanes, milestones that expand into source cards — and Astro's island
architecture renders it from a JSON blob compiled at build time with an
ordinary component and a client:load directive, whereas MkDocs would require
hand-written JavaScript injected through theme overrides and a custom hook to
produce the JSON at all. Second, Astro's content collections validate front
matter against a schema at build time, so the same source-ID and front-matter
rules that CI enforces are enforced again by the build itself, and the source
cards render from typed data rather than from strings parsed at render time.
The cost is a Node toolchain instead of a Python one, which is a fair trade
given that the validation, ingestion and link-checking tools are Node already.
MkDocs Material would be the better pick for a project that was mostly prose;
this one is mostly records.
npm install
npm run validate # schema validation, source-ID resolution, front-matter rules
npm run archive # verify URLs resolve, attach real Wayback snapshots
npm run linkcheck # link rot, reported against archive_url
npm run dev # local site
npm run check # everything CI runsAdding a source:
node tools/archive.mjs --url https://example.org/the-paper # probe first
# write sources/registry/<id>.yml per sources/SCHEMA.md
npm run archive # stamp it for real
npm run validateThe scaffold is complete and the first sourced records and timeline events are in. The next milestone is deliberately narrow: the HBM vertical — every generation in the JESD235 line with complete spec deltas, fully sourced. Broad coverage comes after that, and not before. Information projects die at month eight, sixty percent complete; finished and narrow beats sprawling and incomplete.
- Content (everything in
content/,sources/,timeline/): CC BY-SA 4.0. - Code and tooling (
tools/,site/, workflows): MIT.
Cited sources remain under their own licences, recorded in each registry record. Nothing here relicenses them.