-
Notifications
You must be signed in to change notification settings - Fork 0
Command Rate and tCWL
This page covers the handful of values spd-matchtable's "Suggested
starting point" line prints on a separate, explicitly-labeled line
from everything else — because none of them come from SPD at all. This
page exists specifically to explain why they're inferred rather than
measured, and how confident you should be in each.
DDR4's SPD standard defines a fixed byte layout (see SPD Structure and Timebase) covering exactly the timings the DRAM device itself needs satisfied — CL, tRCD, tRP, tRAS, tRC, tRFC, tFAW, tRRD_S/L, tCCD_L, tWR, tWTR_S/L. Anything that's a property of the memory controller's relationship to the module, rather than a limit the DRAM chip itself imposes, isn't SPD's job to encode — it's a BIOS/ platform decision made at boot/training time based on electrical loading, not something a JEDEC-standard EEPROM on the DIMM can know in advance.
The write-side counterpart to CL: time from a WRITE command until data
must actually be presented on the DQ bus. Unlike CL, DDR4's JEDEC spec
ties tCWL to the operating frequency itself via a lookup table (a
given MT/s bin has one standard CWL value), rather than to the module's
own SPD-declared timing. Because the SPD doesn't carry this table,
spd-matchtable falls back to the common rule-of-thumb approximation
tCWL = CL - 1, which holds for many (not all) real DDR4 speed bins —
close enough to be a reasonable starting point, wrong enough in specific
cases that the tool marks it "inferred, not from SPD" rather than as a
computed fact.
As covered in Bank Group and Activation Timings, the different-bank-
group column-to-column spacing is fixed by the DDR4 standard at a small
constant (commonly 4 cycles) rather than varying per module — which is
why this tool just states tCCD_S=4 as a constant rather than computing
it from anything.
Covered in detail in Write Recovery and Turnaround — not in SPD's base timing block at all; approximated from a common industry-wide ~7.5ns figure.
This is the one item on this list that isn't a DRAM device timing at all — it's a setting on the command/address bus itself, specifically how many clock cycles the memory controller holds a command (and its associated chip-select) stable before considering it "sent." At 1T, a new command can be issued to a different rank every single clock; at 2T, it takes two.
Why this matters specifically for electrical loading: the command/
address bus is wired to every installed DIMM in a channel, in parallel
— it's not a point-to-point connection like the per-rank chip-select
lines are. The more ranks and DIMMs sharing that bus, the more
capacitance the signal has to drive and the more reflection/settling
margin it needs before every chip on the bus reliably samples the same
command correctly. A single-rank, single-DIMM-per-channel system usually
has enough margin to run 1T reliably; a 2-DIMM-per-channel or multi-rank
population — like this project's own reference kit, which mixes
dual-rank and single-rank sticks across both channels — often needs the
extra cycle of setup margin that 2T provides. This is exactly why
spd-matchtable's heuristic switches to recommending 2T once more than
two modules or any multi-rank module is detected: it's a proxy for
electrical loading, not a DRAM-device timing at all, and the tool is
explicit that it's a generic guess to verify in your own BIOS rather than
a computed requirement.