-
Notifications
You must be signed in to change notification settings - Fork 0
Module Organization
These four values explain why two modules of the same advertised capacity can have meaningfully different timing requirements — the central discovery this project's own reference kit made about its two 16GB modules.
The capacity of a single die (one physical DRAM chip), independent of how
many dies are on the module or how they're wired — expressed in gigabits
(Gb), not gigabytes. This project's reference kit has both 8Gb-die and
16Gb-die modules of the same 16GB total module capacity, because they
arrive at that capacity through different die counts/configurations (see
below). Density is the single biggest driver of tRFC — see
Refresh Timing tRFC for why higher-density dies need measurably
longer refresh windows.
How many data pins (bits) each individual die exposes. A module's 64-bit data bus (72-bit for ECC) is built from enough dies, each contributing their width, to add up to that total: an x8 module needs 8 dies per rank (8 × 8 = 64 bits); an x16 module needs only 4 dies per rank (4 × 16 = 64 bits) for the same total bus width, using fewer, wider-per-pin dies.
This project's reference kit demonstrates why width matters beyond bookkeeping: its 8GB single-rank module turned out to be built from 16Gb-density dies in an x16 configuration — not the 8Gb x8 configuration that would have been the naive guess from capacity alone. Width and density interact multiplicatively to produce capacity, so the same module capacity can hide very different underlying die characteristics (and therefore different tRFC/tFAW/tRRD requirements) — exactly why relying on a module's advertised GB figure alone, without checking density/width, would have led this tool's earlier hand-analysis astray (see the main repo's conversation history / commit log for that exact correction).
A rank is one complete, independently-addressable 64-bit (or 72-bit ECC) set of dies sharing the module's data bus, distinguished by its own chip-select signal. A dual-rank module is, electrically, close to two single-rank modules sharing one slot's data pins — which is exactly why dual-rank modules add more electrical loading on the command/address and data buses than single-rank ones, and why Command Rate and tCWL's 2T recommendation heuristic keys partly off rank count.
capacity_GB = density_Gb * (64 / width) * ranks / 8
Read left to right: 64 / width is how many dies make up one rank's
64-bit bus; multiplying by density_Gb gives total gigabits per rank;
multiplying by ranks gives total gigabits for the whole module; dividing
by 8 converts gigabits to gigabytes.
spd-matchtable validated this formula against all three distinct real
capacities present in its own reference kit before trusting it in code:
| Module | density | width | ranks | formula result | actual capacity |
|---|---|---|---|---|---|
| Dual-rank 16GB stick | 8Gb | x8 | 2 |
8*(64/8)*2/8 = 16 |
16GB ✓ |
| Single-rank 16GB stick | 16Gb | x8 | 1 |
16*(64/8)*1/8 = 16 |
16GB ✓ |
| Single-rank 8GB stick | 16Gb | x16 | 1 |
16*(64/16)*1/8 = 8 |
8GB ✓ |
All three matched exactly — the reason this specific formula, rather than a simpler density-only guess, is what's implemented.