XMP Profiles Explained

XMP Profiles Explained

What XMP actually is

XMP (Extreme Memory Profile) is Intel's specification for an additional region of SPD data — beyond the mandatory JEDEC base timing block every DDR4 module must carry — where a manufacturer can store one or two extra, tighter, higher-voltage timing profiles that they've validated specifically for that module, beyond what plain JEDEC guarantees. AMD platforms read the exact same on-DIMM data structure (surfaced in BIOS as "DOCP" on many boards) — it's not an Intel-only feature at the data level, just an Intel-originated specification that both platforms' firmware learned to parse.

Critically: XMP is not required. A perfectly normal DDR4 module can ship with zero XMP data — nothing but the mandatory JEDEC base block — and this project's own reference kit demonstrates exactly that: two of its four modules (the single-rank sticks) carry no XMP profile at all, verified by reading the raw magic-signature bytes directly (0x00 0x00 instead of the expected 0x0C 0x4A) rather than inferring absence from a summarizer tool's silence.

Why decode-dimms doesn't show it

decode-dimms (the standard Linux i2c-tools SPD reader) has zero XMP-parsing code — not a bug, just a scope the tool never covered. This was confirmed directly by grepping its source for "xmp" during this project's development: no matches. This is exactly why spd-matchtable exists as a distinct tool rather than a wrapper around decode-dimms — the byte range decode-dimms genuinely cannot see is precisely where this project's reference kit's most useful data lives.

What's actually stored in a profile

Each profile (up to two per module) encodes its own: target frequency (as a timebase-tick cycle time, same MTB/FTB scheme described in SPD Structure and Timebase), CL/tRCD/tRP/tRAS/tRC/tRFC1/tRFC2/tRFC4/ tFAW/tRRD_S/tRRD_L at that frequency, and a voltage byte (encoded as hundredths-of-a-volt across two bit-packed fields: a "×100" flag bit plus a 0-127 remainder — e.g. this project's reference kit's profiles decode to exactly 1.35V, matching their printed box spec, not just a spec-sheet association).

This project's reference kit's two XMP-carrying modules each expose two profiles — a common real-world pattern: profile 1 is the "headline" rated speed (3200 MT/s CL16-18-18-36 @ 1.35V here), profile 2 a more conservative fallback (3003 MT/s CL15-17-17-36 @ 1.35V here) for boards or configurations that can't quite hit the top profile.

Why a mixed kit usually can't just "enable XMP"

An XMP profile only describes what that specific module is validated for. BIOS applies one system-wide DOCP/XMP setting across every populated slot — so enabling a profile only produces a coherent, safe configuration if every installed module carries a matching (or at least compatible) profile. In a genuinely mixed kit, that's frequently not true — exactly the case in this project's own reference system, where two modules have a real embedded profile and two have none at all. Turning on DOCP there wouldn't fail loudly; it would either silently ignore the profile-less modules' actual requirements or fail to train reliably, neither of which is obviously distinguishable from "it's fine" without independently checking each module's own data first.

This is the core reason spd-matchtable's computed match table is built entirely from each module's base JEDEC data — the part every DDR4 module is guaranteed to carry — and treats XMP profiles as reference information only, printed separately, never folded into the worst-case calculation. See Worst Case Methodology for exactly how that calculation works.