-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This wiki explains, in technical depth, what every value spd_matchtable.py
reads or computes actually means physically — not just the abbreviation,
but why the parameter exists in DDR4's protocol, what happens if you get
it wrong, and why this tool handles it the way it does. The tool's own
--selftest and source comments establish correctness; this wiki is
where the why lives.
Written to be read start to finish by someone who's never tuned RAM timings before, but precise enough to be useful to someone who has.
Timings — what each one physically gates
- Primary Timings CL tRCD tRP tRAS tRC — the core row/column access chain
- Refresh Timing tRFC — why bigger modules need longer refresh pauses
- Bank Group and Activation Timings — tFAW, tRRD_S/L, tCCD_L — current and bus-sharing limits
- Write Recovery and Turnaround — tWR, tWTR_S/L, tRTP — the write side nobody talks about
- Command Rate and tCWL — the two numbers SPD doesn't give you, and how this tool infers them
The data model
- SPD Structure and Timebase — how a byte-oriented EEPROM encodes fractional nanoseconds
- Module Organization — density, width, ranks, and where the capacity formula comes from
- Module Type and ECC Compatibility — why RDIMM+UDIMM or ECC+non-ECC won't POST
- XMP Profiles Explained — what's actually stored in that embedded profile, and why mixed kits usually can't use it
Methodology
- Worst Case Methodology — why "take the max per parameter" is almost right, and the one place it isn't
- Voltage — what VDD actually trades off, physically
- FAQ and Design Decisions — why not bash, why read-only, why offline files, why 80 columns, "why not just trust XMP"
Every byte offset and formula referenced across these pages was
independently verified against this project's own reference kit — a live
4-module mixed DDR4 set (2× Kingston KF3200C16D4/16GX dual-rank, plus
KF432C16BB3/16 and KF432C16BB/8 single-rank) — cross-checked against
decode-dimms output and, for the XMP region decode-dimms doesn't parse
at all, against integralfx/DDR4XMPEditor.
See the main repo's RELEASE_NOTES.md
for the specific verification history, including one case where an
external review's own claimed byte offset was wrong and had to be
re-derived from the struct layout before being trusted.
This tool, this wiki, and the surrounding repo were built in collaboration with two AI models, and neither was error-free — worth recording honestly rather than smoothing over.
Claude (Anthropic) did most of the implementation and this wiki, and
made real mistakes along the way, each caught before shipping: an early
manual count of SPD byte 0x11 was momentarily wrong before a re-check
caught it; a hand-rewrapped hex string for the --selftest fixture
silently dropped bytes (478 instead of the required 512), caught only
because the selftest itself then failed; and an earlier summary stated
CL=22 at 3200 MT/s where the correct value is 23 — a plain rounding
slip, corrected during a later verification pass.
Kimi (Moonshot AI) performed the independent review of v1.0.0
referenced above — it caught a real bug (the tRC understatement) and
correctly flagged the 2401-vs-2400 MT/s rounding artifact, but one of
its own suggested fixes cited the wrong byte offset (0x10 instead of
the correct 0x11), which had to be independently re-derived before
being applied.
Same mechanism caught every mistake above regardless of which model made it: check against real reference hardware and a second independent source before trusting a number. That's the actual subject of this wiki — not a scoreboard of whose output was cleaner.