Hubbry Logo
Serial presence detectSerial presence detectMain
Open search
Serial presence detect
Community hub
Serial presence detect
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Serial presence detect
Serial presence detect
Serial presence detect
View on Wikipedia
from Wikipedia

In computing, serial presence detect (SPD) is a standardized way to automatically access information about a memory module. Earlier 72-pin SIMMs included five pins that provided five bits of parallel presence detect (PPD) data, but the 168-pin DIMM standard changed to a serial presence detect to encode more information.[1]

When an ordinary modern computer is turned on, it starts by doing a power-on self-test (POST). Since about the mid-1990s, this process includes automatically configuring the hardware currently present. SPD is a memory hardware feature that makes it possible for the computer to know what memory is present, and what memory timings to use to access the memory.

Some computers adapt to hardware changes completely automatically. In most cases, there is a special optional procedure for accessing BIOS parameters, to view and potentially make changes in settings. It may be possible to control how the computer uses the memory SPD data—to choose settings, selectively modify memory timings, or possibly to completely override the SPD data (see overclocking).

Stored information

[edit]

For a memory module to support SPD, the JEDEC standards require that certain parameters be in the lower 128 (or more, depending on the generation) bytes of an EEPROM located on the memory module. These bytes contain timing parameters, manufacturer, serial number and other useful information about the module. Devices utilizing the memory automatically determine key parameters of the module by reading this information. For example, the SPD data on an SDRAM module might provide information about the CAS latency so the system can set this correctly without user intervention.

The SPD EEPROM firmware is accessed using SMBus, a variant of the I2C protocol. This reduces the number of communication pins on the module to just two: a clock signal and a data signal. The EEPROM shares ground pins with the RAM, has its own power pin, and has three additional pins (SA0–2) to identify the slot, which are used to assign the EEPROM a unique address in the range 0x50–0x57. Not only can the communication lines be shared among 8 memory modules, the same SMBus is commonly used on motherboards for system health monitoring tasks such as reading power supply voltages, CPU temperatures, and fan speeds.

Before SPD, memory chips were spotted with parallel presence detect (PPD). PPD used a separate pin for each bit of information, which meant that only the speed and density of the memory module could be stored because of the limited space for pins.

SDR SDRAM

[edit]
Memory device on an SDRAM module, containing SPD data (red circled)

The first SPD specification was issued by JEDEC and tightened up by Intel as part of its PC100 memory specification introduced in 1998.[2][3][4] Most values specified are in binary-coded decimal form. The most significant nibble can contain values from 10 to 15, and in some cases extends higher. In such cases, the encodings for 1, 2 and 3 are instead used to encode 16, 17 and 18. A most significant nibble of 0 is reserved to represent "undefined".

The SPD ROM defines up to three DRAM timings, for three CAS latencies specified by set bits in byte 18. First comes the highest CAS latency (fastest clock), then two lower CAS latencies with progressively lower clock speeds.

SPD contents for SDR SDRAM[5]
Byte Bit Notes
(dec.) (hex.) 7 6 5 4 3 2 1 0
0 0x00 Number of bytes present Typically 128
1 0x01 log2(size of SPD EEPROM) Typically 8 (256 bytes)
2 0x02 Basic memory type (4: SPD SDRAM)
3 0x03 Bank 2 row address bits (0–15) Bank 1 row address bits (1–15) Bank 2 is 0 if same as bank 1
4 0x04 Bank 2 column address bits (0–15) Bank 1 column address bits (1–15) Bank 2 is 0 if same as bank 1
5 0x05 Number of RAM banks on module (1–255) Commonly 1 or 2
6 0x06 Module data width low byte Commonly 64, or 72 for ECC DIMMs
7 0x07 Module data width high byte 0, unless width ≥ 256 bits
8 0x08 Interface voltage level of this assembly (not the same as Vcc supply voltage) (0–4) Decoded by table lookup
9 0x09 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at highest CAS latency
10 0x0a Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) SDRAM access time from clock (tAC)
11 0x0b DIMM configuration type (0–2): non-ECC, parity, ECC Table lookup
12 0x0c Self Refresh period (0–5): 64, 256, 128, 32, 16, 8 kHz Refresh requirements
13 0x0d Bank 2 2× Bank 1 primary SDRAM width (1–127, usually 8) Width of bank 1 data SDRAM devices. Bank 2 may be same width, or 2× width if bit 7 is set.
14 0x0e Bank 2 2× Bank 1 ECC SDRAM width (0–127) Width of bank 1 ECC/parity SDRAM devices. Bank 2 may be same width, or 2× width if bit 7 is set.
15 0x0f Clock delay for random column reads Typically 1
16 0x10 Page — — — 8 4 2 1 Burst lengths supported (bitmap)
17 0x11 Banks per SDRAM device (1–255) Typically 2 or 4
18 0x12 — 7 6 5 4 3 2 1 CAS latencies supported (bitmap)
19 0x13 — 6 5 4 3 2 1 0 CS latencies supported (bitmap)
20 0x14 — 6 5 4 3 2 1 0 WE latencies supported (bitmap)
21 0x15 — Redundant Diff. clock Registered data Buffered data On-card PLL Registered addr. Buffered addr. Memory module feature bitmap
22 0x16 — — Upper Vcc (supply voltage) tolerance Lower Vcc (supply voltage) tolerance Write/1 read burst Precharge all Auto-precharge Early RAS precharge Memory chip feature support bitmap
23 0x17 Nanoseconds (4–18) Tenths of nanoseconds (0–9: 0.0–0.9) Clock cycle time at medium CAS latency
24 0x18 Nanoseconds (4–18) Tenths of nanoseconds (0–9: 0.0–0.9) Data access time from clock (tAC)
25 0x19 Nanoseconds (1–63) 0.25 ns (0–3: 0.00–0.75) Clock cycle time at short CAS latency.
26 0x1a Nanoseconds (1–63) 0.25 ns (0–3: 0.00–0.75) Data access time from clock (tAC)
27 0x1b Nanoseconds (1–255) Minimum row precharge time (tRP)
28 0x1c Nanoseconds (1–255) Minimum row active–row active delay (tRRD)
29 0x1d Nanoseconds (1–255) Minimum RAS to CAS delay (tRCD)
30 0x1e Nanoseconds (1–255) Minimum active to precharge time (tRAS)
31 0x1f 512 MiB 256 MiB 128 MiB 64 MiB 32 MiB 16 MiB 8 MiB 4 MiB Module bank density (bitmap). Two bits set if different size banks.
32 0x20 Sign (1: −) Nanoseconds (0–7) Tenths of nanoseconds (0–9: 0.0–0.9) Address/command setup time from clock
33 0x21 Sign (1: −) Nanoseconds (0–7) Tenths of nanoseconds (0–9: 0.0–0.9) Address/command hold time after clock
34 0x22 Sign (1: −) Nanoseconds (0–7) Tenths of nanoseconds (0–9: 0.0–0.9) Data input setup time from clock
35 0x23 Sign (1: −) Nanoseconds (0–7) Tenths of nanoseconds (0–9: 0.0–0.9) Data input hold time after clock
36–61 0x24–0x3d Reserved For future standardization
62 0x3e Major revision (0–9) Minor revision (0–9) SPD revision level; e.g., 1.2
63 0x3f Checksum Sum of bytes 0–62, not then negated
64–71 0x40–47 Manufacturer JEDEC id. Stored little-endian, trailing zero-padded
72 0x48 Module manufacturing location Vendor-specific code
73–90 0x49–0x5a Module part number ASCII, space-padded
91–92 0x5b–0x5c Module revision code Vendor-specific code
93 0x5d Tens of years (0–9: 0–90) Years (0–9) Manufacturing date (YYWW)
94 0x5e Tens of weeks (0–5: 0–50) Weeks (0–9)
95–98 0x5f–0x62 Module serial number Vendor-specific code
99–125 0x63–0x7f Manufacturer-specific data Could be enhanced performance profile
126 0x7e 0x66 [sic] for 66 MHz, 0x64 for 100 MHz Intel frequency support
127 0x7f CLK0 CLK1 CLK3 CLK3 90/100 °C CL3 CL2 Concurrent AP Intel feature bitmap

DDR SDRAM

[edit]

The DDR DIMM SPD format is an extension of the SDR SDRAM format. Mostly, parameter ranges are rescaled to accommodate higher speeds.

SPD contents for DDR SDRAM[6]
Byte Bit Notes
(dec.) (hex.) 7 6 5 4 3 2 1 0
0 0x00 Number of bytes written Typically 128
1 0x01 log2(size of SPD EEPROM) Typically 8 (256 bytes)
2 0x02 Basic memory type (7 = DDR SDRAM)
3 0x03 Bank 2 row address bits (0–15) Bank 1 row address bits (1–15) Bank 2 is 0 if same as bank 1.
4 0x04 Bank 2 column address bits (0–15) Bank 1 column address bits (1–15) Bank 2 is 0 if same as bank 1.
5 0x05 Number of RAM banks on module (1–255) Commonly 1 or 2
6 0x06 Module data width low byte Commonly 64, or 72 for ECC DIMMs
7 0x07 Module data width high byte 0, unless width ≥ 256 bits
8 0x08 Interface voltage level of this assembly (not the same as Vcc supply voltage) (0–5) Decoded by table lookup
9 0x09 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at highest CAS latency.
10 0x0a Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) SDRAM access time from clock (tAC)
11 0x0b DIMM configuration type (0–2): non-ECC, parity, ECC Table lookup
12 0x0c Self Refresh period (0–5): 64, 256, 128, 32, 16, 8 kHz Refresh requirements
13 0x0d Bank 2 2× Bank 1 primary SDRAM width (1–127) Width of bank 1 data SDRAM devices. Bank 2 may be same width, or 2× width if bit 7 is set.
14 0x0e Bank 2 2× Bank 1 ECC SDRAM width (0–127) Width of bank 1 ECC/parity SDRAM devices. Bank 2 may be same width, or 2× width if bit 7 is set.
15 0x0f Clock delay for random column reads Typically 1
16 0x10 Page — — — 8 4 2 1 Burst lengths supported (bitmap)
17 0x11 Banks per SDRAM device (1–255) Typically 4
18 0x12 — 4 3.5 3 2.5 2 1.5 1 CAS latencies supported (bitmap)
19 0x13 — 6 5 4 3 2 1 0 CS latencies supported (bitmap)
20 0x14 — 6 5 4 3 2 1 0 WE latencies supported (bitmap)
21 0x15 — x Diff clock FET switch external enable FET switch on-board enable On-card PLL Registered Buffered Memory module feature bitmap
22 0x16 Fast AP Concurrent auto precharge Upper Vcc (supply voltage) tolerance Lower Vcc (supply voltage) tolerance — — — Includes weak driver Memory chip feature bitmap
23 0x17 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at medium CAS latency.
24 0x18 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data access time from clock (tAC)
25 0x19 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at short CAS latency.
26 0x1a Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data access time from clock (tAC)
27 0x1b Nanoseconds (1–63) 0.25 ns (0–0.75) Minimum row precharge time (tRP)
28 0x1c Nanoseconds (1–63) 0.25 ns (0–0.75) Minimum row active–row active delay (tRRD)
29 0x1d Nanoseconds (1–63) 0.25 ns (0–0.75) Minimum RAS to CAS delay (tRCD)
30 0x1e Nanoseconds (1–255) Minimum active to precharge time (tRAS)
31 0x1f 512 MiB 256 MiB 128 MiB 64 MiB 32 MiB 16 MiB/
4 GiB		 8 MiB/
2 GiB		 4 MiB/
1 GiB		 Module bank density (bitmap). Two bits set if different size banks.
32 0x20 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Address/command setup time from clock
33 0x21 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Address/command hold time after clock
34 0x22 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data input setup time from clock
35 0x23 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data input hold time after clock
36–40 0x24–0x28 Reserved Superset information
41 0x29 Nanoseconds (1–255) Minimum active to active/refresh time (tRC)
42 0x2a Nanoseconds (1–255) Minimum refresh to active/refresh time (tRFC)
43 0x2b Nanoseconds (1–63, or 255: no maximum) 0.25 ns (0–0.75) Maximum clock cycle time (tCK max.)
44 0x2c Hundredths of nanoseconds (0.01–2.55) Maximum skew, DQS to any DQ. (tDQSQ max.)
45 0x2d Tenths of nanoseconds (0.0–1.2) Hundredths of nanoseconds (0.00–0.09) Read data hold skew factor (tQHS)
46 0x2e Reserved For future standardization
47 0x2f — Height Height of DIMM module, table lookup
48–61 0x30–0x3d Reserved For future standardization
62 0x3e Major revision (0–9) Minor revision (0–9) SPD revision level, 0.0 or 1.0
63 0x3f Checksum Sum of bytes 0–62, not then negated
64–71 0x40–47 Manufacturer JEDEC id. Stored little-endian, trailing zero-padded
72 0x48 Module manufacturing location Vendor-specific code
73–90 0x49–0x5a Module part number ASCII, space-padded
91–92 0x5b–0x5c Module revision code Vendor-specific code
93 0x5d Tens of years (0–90) Years (0–9) Manufacturing date (YYWW)
94 0x5e Tens of weeks (0–50) Weeks (0–9)
95–98 0x5f–0x62 Module serial number Vendor-specific code
99–127 0x63–0x7f Manufacturer-specific data Could be enhanced performance profile

DDR2 SDRAM

[edit]

The DDR2 SPD standard makes a number of changes, but is roughly similar to the above. One notable deletion is the confusing and little-used support for DIMMs with two ranks of different sizes.

For cycle time fields (bytes 9, 23, 25 and 49), which are encoded in BCD, some additional encodings are defined for the tenths digit to represent some common timings exactly:

DDR2 BCD extensions
Hex Binary Significance
A 1010 0.25 (1⁄4)
B 1011 0.33 (1⁄3)
C 1100 0.66 (2⁄3)
D 1101 0.75 (3⁄4)
E 1110 0.875 (7⁄8, Nvidia XMP extension)
F 1111 Reserved
SPD contents for DDR2 SDRAM[7]
Byte Bit Notes
Dec Hex 7 6 5 4 3 2 1 0
0 0x00 Number of bytes written Typically 128
1 0x01 log2(size of SPD EEPROM) Typically 8 (256 bytes)
2 0x02 Basic memory type (8 = DDR2 SDRAM)
3 0x03 Reserved Row address bits (1–15)
4 0x04 Reserved Column address bits (1–15)
5 0x05 Vertical height Stack? ConC? Ranks−1 (1–8) Commonly 0 or 1, meaning 1 or 2
6 0x06 Module data width Commonly 64, or 72 for ECC DIMMs
7 0x07 Reserved
8 0x08 Interface voltage level of this assembly (not the same as Vcc supply voltage) (0–5) Decoded by table lookup.
Commonly 5 = SSTL 1.8 V
9 0x09 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at highest CAS latency.
10 0x0a Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) SDRAM access time from clock (tAC)
11 0x0b DIMM configuration type (0–2): non-ECC, parity, ECC Table lookup
12 0x0c Self Refresh period (0–5): 64, 256, 128, 32, 16, 8 kHz Refresh requirements
13 0x0d Primary SDRAM width (1–255) Commonly 8 (module built from ×8 parts) or 16
14 0x0e ECC SDRAM width (0–255) Width of bank ECC/parity SDRAM devices. Commonly 0 or 8.
15 0x0f Reserved
16 0x10 — — — — 8 4 — — Burst lengths supported (bitmap)
17 0x11 Banks per SDRAM device (1–255) Typically 4 or 8
18 0x12 7 6 5 4 3 2 — — CAS latencies supported (bitmap)
19 0x13 Reserved
20 0x14 — — Mini-UDIMM Mini-RDIMM Micro-DIMM SO-DIMM UDIMM RDIMM DIMM type of this assembly (bitmap)
21 0x15 — Module is analysis probe — FET switch external enable — — — — Memory module feature bitmap
22 0x16 — — — — — — — Includes weak driver Memory chip feature bitmap
23 0x17 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at medium CAS latency.
24 0x18 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data access time from clock (tAC)
25 0x19 Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Clock cycle time at short CAS latency.
26 0x1a Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data access time from clock (tAC)
27 0x1b Nanoseconds (1–63) 1/4 ns (0–0.75) Minimum row precharge time (tRP)
28 0x1c Nanoseconds (1–63) 1/4 ns (0–0.75) Minimum row active–row active delay (tRRD)
29 0x1d Nanoseconds (1–63) 1/4 ns (0–0.75) Minimum RAS to CAS delay (tRCD)
30 0x1e Nanoseconds (1–255) Minimum active to precharge time (tRAS)
31 0x1f 512 MiB 256 MiB 128 MiB 16 GiB 8 GiB 4 GiB 2 GiB 1 GiB Size of each rank (bitmap).
32 0x20 Tenths of nanoseconds (0.0–1.2) Hundredths of nanoseconds (0.00–0.09) Address/command setup time from clock
33 0x21 Tenths of nanoseconds (0.0–1.2) Hundredths of nanoseconds (0.00–0.09) Address/command hold time after clock
34 0x22 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data input setup time from strobe
35 0x23 Tenths of nanoseconds (0.0–0.9) Hundredths of nanoseconds (0.00–0.09) Data input hold time after strobe
36 0x24 Nanoseconds (1–63) 0.25 ns (0–0.75) Minimum write recovery time (tWR)
37 0x25 Nanoseconds (1–63) 0.25 ns (0–0.75) Internal write to read command delay (tWTR)
38 0x26 Nanoseconds (1–63) 0.25 ns (0–0.75) Internal read to precharge command delay (tRTP)
39 0x27 Reserved Reserved for "memory analysis probe characteristics"
40 0x28 — tRC fractional ns (0–5):
0, 0.25, 0.33, 0.5, 0.66, 0.75		 tRFC fractional ns (0–5):
0, 0.25, 0.33, 0.5, 0.66, 0.75		 tRFC + 256 ns Extension of bytes 41 and 42.
41 0x29 Nanoseconds (1–255) Minimum active to active/refresh time (tRC)
42 0x2a Nanoseconds (1–255) Minimum refresh to active/refresh time (tRFC)
43 0x2b Nanoseconds (0–15) Tenths of nanoseconds (0.0–0.9) Maximum clock cycle time (tCK max)
44 0x2c Hundredths of nanoseconds (0.01–2.55) Maximum skew, DQS to any DQ. (tDQSQ max)
45 0x2d Hundredths of nanoseconds (0.01–2.55) Read data hold skew factor (tQHS)
46 0x2e Microseconds (1–255) PLL relock time
47–61 0x2f–0x3d Reserved For future standardization.
62 0x3e Major revision (0–9) Minor revision (0.0–0.9) SPD revision level, usually 1.0
63 0x3f Checksum Sum of bytes 0–62, not negated
64–71 0x40–47 Manufacturer JEDEC ID Stored little-endian, trailing zero-pad
72 0x48 Module manufacturing location Vendor-specific code
73–90 0x49–0x5a Module part number ASCII, space-padded (limited to (,-,), A–Z, a–z, 0–9, space)
91–92 0x5b–0x5c Module revision code Vendor-specific code
93 0x5d Years since 2000 (0–255) Manufacturing date (YYWW)
94 0x5e Weeks (1–52)
95–98 0x5f–0x62 Module serial number Vendor-specific code
99–127 0x63–0x7f Manufacturer-specific data Could be enhanced performance profile

DDR3 SDRAM

[edit]

The DDR3 SDRAM standard significantly overhauls and simplifies the SPD contents layout. Instead of a number of BCD-encoded nanosecond fields, some "timebase" units are specified to high precision, and various timing parameters are encoded as multiples of that base unit.[8] Further, the practice of specifying different time values depending on the CAS latency has been dropped; now there are just a single set of timing parameters.

Revision 1.1 lets some parameters be expressed as a "medium time base" value plus a (signed, −128 +127) "fine time base" correction. Generally, the medium time base is 1/8 ns (125 ps), and the fine time base is 1, 2.5 or 5 ps. For compatibility with earlier versions that lack the correction, the medium time base number is usually rounded up and the correction is negative. Values that work this way are:

DDR3 SPD two-part timing parameters
MTB byte FTB byte Value
12 34 tCKmin, minimum clock period
16 35 tAAmin, minimum CAS latency time
18 36 tRCDmin, minimum RAS# to CAS# delay
20 37 tRPmin, minimum row precharge delay
21, 23 38 tRCmin, minimum active to active/precharge delay
SPD contents for DDR3 SDRAM[9][10]
Byte Bit Notes
Dec Hex 7 6 5 4 3 2 1 0
0 0x00 Exclude serial from CRC SPD bytes total (undef/256) SPD bytes used (undef/128/176/256)
1 0x01 SPD major revision SPD minor revision 1.0, 1.1, 1.2 or 1.3
2 0x02 Basic memory type (11 = DDR3 SDRAM) Type of RAM chips
3 0x03 Reserved Module type Type of module; e.g., 2 = Unbuffered DIMM, 3 = SO-DIMM, 11=LRDIMM
4 0x04 — Bank address bits−3 log2(bits per chip)−28 Zero means 8 banks, 256 Mibit.
5 0x05 — Row address bits−12 Column address bits−9
6 0x06 Reserved 1.25 V 1.35 V Not 1.5 V Modules voltages supported. 1.5 V is default.
7 0x07 — ranks−1 log2(I/O bits/chip)−2 Module organization
8 0x08 — ECC bits (001=8) log2(data bits)−3 0x03 for 64-bit, non-ECC DIMM.
9 0x09 Dividend, picoseconds (1–15) Divisor, picoseconds (1–15) Fine Time Base, dividend/divisor
10 0x0a Dividend, nanoseconds (1–255) Medium Time Base, dividend/divisor; commonly 1/8
11 0x0b Divisor, nanoseconds (1–255)
12 0x0c Minimum cycle time tCKmin In multiples of MTB
13 0x0d Reserved
14 0x0e 11 10 9 8 7 6 5 4 CAS latencies supported (bitmap)
15 0x0f — 18 17 16 15 14 13 12
16 0x10 Minimum CAS latency time, tAAmin In multiples of MTB; e.g., 80/8 ns.
17 0x11 Minimum write recovery time, tWRmin In multiples of MTB; e.g., 120/8 ns.
18 0x12 Minimum RAS to CAS delay time, tRCDmin In multiples of MTB; e.g., 100/8 ns.
19 0x13 Minimum row to row active delay time, tRRDmin In multiples of MTB; e.g., 60/8 ns.
20 0x14 Minimum row precharge time, tRPmin In multiples of MTB; e.g., 100/8 ns.
21 0x15 tRCmin, bits 11:8 tRASmin, bits 11:8 Upper 4 bits of bytes 23 and 22
22 0x16 Minimum active to time, tRASmin, bits 7:0 In multiples of MTB; e.g., 280/8 ns.
23 0x17 Minimum active to active/refresh, tRCmin, bits 7:0 In multiples of MTB; e.g., 396/8 ns.
24 0x18 Minimum refresh recovery delay, tRFCmin, bits 7:0 In multiples of MTB; e.g., 1280/8 ns.
25 0x19 Minimum refresh recovery delay, tRFCmin, bits 15:8
26 0x1a Minimum internal write to read delay, tWTRmin In multiples of MTB; e.g., 60/8 ns.
27 0x1b Minimum internal read to precharge delay, tRTPmin In multiples of MTB; e.g., 60/8 ns.
28 0x1c Reserved tFAWmin, bits 11:8 In multiples of MTB; e.g., 240/8 ns.
29 0x1d Minimum four activate window delay tFAWmin, bits 7:0
30 0x1e DLL-off — RZQ/7 RZQ/6 SDRAM optional features support bitmap
31 0x1f PASR — ODTS ASR ETR 1× ETR (95 °C) SDRAM thermal and refresh options
32 0x20 Present Accuracy (TBD; currently 0 = undefined) DIMM thermal sensor present?
33 0x21 Nonstd. Die count — Signal load Nonstandard SDRAM device type (e.g., stacked die)
34 0x22 tCKmin correction (new for 1.1) Signed multiple of FTB, added to byte 12
35 0x23 tAAmin correction (new for 1.1) Signed multiple of FTB, added to byte 16
36 0x24 tRCDmin correction (new for 1.1) Signed multiple of FTB, added to byte 18
37 0x25 tRPmin correction (new for 1.1) Signed multiple of FTB, added to byte 20
38 0x26 tRCmin correction (new for 1.1) Signed multiple of FTB, added to byte 23
39–40 0x27–0x28 Reserved For future standardization.
41 0x29 Vendor specific tMAW Maximum Activate Count (MAC) (untested/700k/600k/.../200k/reserved/∞) For row hammer mitigation
42–59 0x2a–0x3b Reserved For future standardization.
60 0x3c — Module height, mm (1–31, >45) Module nominal height
61 0x3d Back thickness, mm (1–16) Front thickness, mm (1–16) Module thickness, value = ceil(mm) − 1
62 0x3e Design Revision JEDEC design number JEDEC reference design used (11111=none)
63–116 0x3f–0x74 Module-specific section Differs between registered/unbuffered
117 0x75 Module manufacturer ID, lsbyte Assigned by JEP-106
118 0x76 Module manufacturer ID, msbyte
119 0x77 Module manufacturing location Vendor-specific code
120 0x78 Tens of years Years Manufacturing year (BCD)
121 0x79 Tens of weeks Weeks Manufacturing week (BCD)
122–125 0x7a–0x7d Module serial number Vendor-specific code
126–127 0x7e–0x7f SPD CRC-16 Includes bytes 0–116 or 0–125; see byte 0 bit 7
128–145 0x80–0x91 Module part number ASCII subset, space-padded
146–147 0x92–0x93 Module revision code Vendor-defined
148–149 0x94–0x95 DRAM manufacturer ID As distinct from module manufacturer
150–175 0x96–0xAF Manufacturer-specific data
176–255 0xB0–0xFF Available for customer use

The memory capacity of a module can be computed from bytes 4, 7 and 8. The module width (byte 8) divided by the number of bits per chip (byte 7) gives the number of chips per rank. That can then be multiplied by the per-chip capacity (byte 4) and the number of ranks of chips on the module (usually 1 or 2, from byte 7).

DDR4 SDRAM

[edit]

The DDR4 SDRAM "Annex L" standard for SPD changes the EEPROM module used. Instead of the old AT24C02-compatible 256-byte EEPROMs, JEDEC now defines a new nonstandard EE1004 type with two pages at the SMBus level each with 256 bytes. The new memory still uses the old 0x50–0x57 addresses, but two additional address at 0x36 (SPA0) and 0x37 (SPA1) are now used to receive commands to select the currently-active page for the bus, a form of bank switching.[11] Internally each logical page is further divided into two physical blocks of 128 bytes each, totaling four blocks and 512 bytes.[12] Other semantics for "special" address ranges remain the same, although write protection is now addressed by blocks and a high voltage at SA0 is now required to change its status.[13]

Annex L defines a few different layouts that can be plugged into a 512-byte (of which a maximum of 320 bytes are defined) template, depending on the type of the memory module. The bit definitions are similar to DDR3.[12]

SPD contents for DDR4 SDRAM[14]
Byte Bit Notes
Dec Hex 7 6 5 4 3 2 1 0
0 0x00 SPD bytes used
1 0x01 SPD revision n Typically 0x10, 0x11, 0x12
2 0x02 Basic memory type (12 = DDR4 SDRAM) Type of RAM chips
3 0x03 Reserved Module type Type of module; e.g., 2 = Unbuffered DIMM, 3 = SO-DIMM, 11=LRDIMM
4 0x04 Bank group bits Bank address bits−2 Total SDRAM capacity per die in megabits Zero means no bank groups, 4 banks, 256 Mibit.
5 0x05 Reserved Row address bits−12 Column address bits−9
6 0x06 Primary SDRAM package type Die count Reserved Signal loading
7 0x07 Reserved Maximum activate window (tMAW) Maximum activate count (MAC) SDRAM optional features
8 0x08 Reserved SDRAM thermal and refresh options
9 0x09 Post package repair (PPR) Soft PPR Reserved Other SDRAM optional features
10 0x0a SDRAM package type Die count−1 DRAM density ratio Signal loading Secondary SDRAM package type
11 0x0b Reserved Endurant flag Operable flag Module nominal voltage, VDD
12 0x0c Reserved Rank mix Package ranks per DIMM−1 SDRAM device width Module organization
13 0x0d Reserved Bus width extension Primary bus width Module memory bus width in bits
14 0x0e Thermal sensor Reserved Module thermal sensor
15 0x0f Reserved Extended base module type
16 0x10 Reserved
17 0x11 Reserved Medium timebase (MTB) Fine timebase (FTB) Measured in ps.
18 0x12 Minimum SDRAM cycle time, tCKAVGmin In multiples of MTB; e.g., 100/8 ns.
19 0x13 Maximum SDRAM cycle time, tCKAVGmax In multiples of MTB; e.g., 60/8 ns.
20 0x14 14 13 12 11 10 9 8 7 CAS latencies supported bit-mask
21 0x15 22 21 20 19 18 17 16 15 CAS latencies supported bit-mask
22 0x16 30 29 28 27 26 25 24 23 CAS latencies supported bit-mask
23 0x17 Low CL range Reserved 36 35 34 33 32 31 CAS latencies supported bit-mask
24 0x18 Minimum CAS latency time, tAAmin In multiples of MTB; e.g., 1280/8 ns.
25 0x19 Minimum RAS to CAS delay time, tRCDmin In multiples of MTB; e.g., 60/8 ns.
26 0x1a Minimum row precharge delay time, tRPmin In multiples of MTB; e.g., 60/8 ns.
27 0x1b Upper nibbles for tRASmin and tRCmin
28 0x1c Minimum active to precharge delay time, tRASmin least significant byte In multiples of MTB
29 0x1d Minimum active to active/refresh delay time, tRCmin least significant byte In multiples of MTB
30 0x1e Minimum refresh recovery delay time, tRFC1min least significant byte In multiples of MTB
31 0x1f Minimum refresh recovery delay time, tRFC1min most significant byte In multiples of MTB
32 0x20 Minimum refresh recovery delay time, tRFC2min least significant byte In multiples of MTB
33 0x21 Minimum refresh recovery delay time, tRFC2min most significant byte In multiples of MTB
34 0x22 Minimum refresh recovery delay time, tRFC4min least significant byte In multiples of MTB
35 0x23 Minimum refresh recovery delay time, tRFC4min most significant byte In multiples of MTB
36 0x24 Reserved tFAWmin most significant nibble
37 0x25 Minimum four activate window delay time, tFAWmin least significant byte In multiples of MTB
38 0x26 Minimum activate to activate delay time, tRRD_Smin, different bank group In multiples of MTB
39 0x27 Minimum activate to activate delay time, tRRD_Lmin, same bank group In multiples of MTB
40 0x28 Minimum CAS to CAS delay time, tCCD_Lmin, same bank group In multiples of MTB
41 0x29 Upper nibble for tWRmin
42 0x2a Minimum write recovery time, tWRmin In multiples of MTB
43 0x2b Upper nibbles for tWTRmin
44 0x2c Minimum write to read time, tWTR_Smin, different bank group In multiples of MTB
45 0x2d Minimum write to read time, tWTR_Lmin, same bank group In multiples of MTB
49–59 0x2e–0x3b Reserved Base configuration section
60–77 0x3c–0x4d Connector to SDRAM bit mapping
78–116 0x4e–0x74 Reserved Base configuration section
117 0x75 Fine offset for minimum CAS to CAS delay time, tCCD_Lmin, same bank Two's complement multiplier for FTB units
118 0x76 Fine offset for minimum activate to activate delay time, tRRD_Lmin, same bank group Two's complement multiplier for FTB units
119 0x77 Fine offset for minimum activate to activate delay time, tRRD_Smin, different bank group Two's complement multiplier for FTB units
120 0x78 Fine offset for minimum active to active/refresh delay time, tRCmin Two's complement multiplier for FTB units
121 0x79 Fine offset for minimum row precharge delay time, tRPmin Two's complement multiplier for FTB units
122 0x7a Fine offset for minimum RAS to CAS delay time, tRCDmin Two's complement multiplier for FTB units
123 0x7b Fine offset for minimum CAS latency time, tAAmin Two's complement multiplier for FTB units
124 0x7c Fine offset for SDRAM maximum cycle time, tCKAVGmax Two's complement multiplier for FTB units
125 0x7d Fine offset for SDRAM minimum cycle time, tCKAVGmin Two's complement multiplier for FTB units
126 0x7e Cyclic rendundancy code (CRC) for base config section, least significant byte CRC16 algorithm
127 0x7f Cyclic rendundancy code (CRC) for base config section, most significant byte CRC16 algorithm
128–191 0x80–0xbf Module-specific section Dependent upon memory module family (UDIMM, RDIMM, LRDIMM)
192–255 0xc0–0xff Hybrid memory architecture specific parameters
256–319 0x100–0x13f Extended function parameter block
320–321 0x140–0x141 Module manufacturer See JEP-106
322 0x142 Module manufacturing location Manufacturer-defined manufacturing location code
323 0x143 Module manufacturing year Represented in Binary Coded Decimal (BCD)
324 0x144 Module manufacturing week Represented in Binary Coded Decimal (BCD)
325–328 0x145–0x148 Module serial number Manufacturer-defined format for a unique serial number across part numbers
329–348 0x149–0x15c Module part number ASCII part number, unused digits should be set to 0x20
349 0x15d Module revision code Manufacturer-defined revision code
350–351 0x15e–0x15f DRAM manufacturer ID code See JEP-106
352 0x160 DRAM stepping Manufacturer-defined stepping or 0xFF if not used
353–381 0x161–0x17d Manufacturer's specific data
382–383 0x17e–0x17f Reserved

DDR5 SDRAM

[edit]

Preliminary table for DDR5, based on JESD400-5 specification.[15]

DDR5 expands the SPD table to 1024-byte. SPD of DDR5 is using the I3C bus.

SPD contents for DDR5 SDRAM
Byte Bit Notes
Dec Hex 7 6 5 4 3 2 1 0
0 0x00 Number of bytes in SPD device
1 0x01 SPD revision for base configuration parameters
2 0x02 Key byte / host bus command protocol type
3 0x03 Key byte / module type
4 0x04 First SDRAM density and package
5 0x05 First SDRAM addressing
6 0x06 First SDRAM I/O width
7 0x07 First SDRAM bank groups & banks per bank group
8 0x08 Second SDRAM density and package
9 0x09 Second SDRAM addressing
10 0x0a Second SDRAM I/O width
11 0x0b Second SDRAM bank groups & banks per bank group
12 0x0c SDRAM optional features
13 0x0d Thermal and refresh options
14 0x0e Reserved
15 0x0f Reserved
16 0x10 SDRAM nominal voltage, VDD

EEPROM chip

[edit]

There are three main generations of EEPROMs as described in JEDEC standards: the 256-byte EE1002 for DDR3 and earlier, the 512-byte EE1004 for DDR4, and the 1024-byte "hub" SPD1558 for DDR5. The EE1002 is the bog-standard 24-series EEPROM. The EE1004 is the newer 34-series EEPROM and differs mainly in having a "page switch" command to allow access to its full content (among other differences). The SPD1558 is very different.

There are also thermal sensor versions of EE1002 and EE1004 but they speak the same protocol for their SPD part.

Addressing

[edit]

As mentioned above SPD uses three pins for addressing up to 8 separate modules from 0 to 7. This is only correct for EE1002 and EE1004; SPD1558 uses a single pin with grounding resistors to specify the module's identity from 0 to 7.[16]: §2.7 

For EE1002 and EE1004 the I2C address range is 0x50–0x57. They also use respond to 0x30–0x37 if they have not been write protected (see below). If they have an associated thermal sensor, they use 0x18–0x1F. All those values are seven-bit I2C addresses formed by a Device Type Identifier Code prefix (DTIC) with SA0-2: to read (1100) from slot 3, one uses 110 0011 = 0x33. With a final R/W bit it forms the 8-bit Device Select Code.[17]

The 5118 contains many devices. The hub itself lies at 0x50–0x57, as before. The local devices are addressed through the hub using I3C.[16]: §2.7 

Write protection

[edit]

The EE1002 has three layers of write protection. The hardware layer is in the form of a WC# pin; when driven low, it prevents all writes. The software layer is in the form of a few commands. Changing software write protect requires driving VHV (instead of the regular 0 or 1 logic voltages) on the address pin SA0 with specific combinations for the other SA pins. As a result there is no differentaion of slot-id.[18] The final layer is the "permanent" layer, a command that can be sent to render the first 128 bytes permanently unchangable.[19]

The EE1004 has no WC# pin or a "permanent" layer. It has four commands to separately set the write-protect status of each 64-byte slice of the device (using different ) and one to clear them all at once. These commands all require driving VHV like before.[20]

The SPD5118 has two modes of protection. In the normal operating mode with the address pin connected to GND via a resistor, protection can only be added to 64-byte slices, not removed. In the "tester" mode with the address pin connected to GND directly however, these bits can be freely removed.[16]: §2.7  (The hub itself also has a number of volatile and non-volatile registers independent of the EEPROM part. Some registers are "password-protected", being neither readable nor writable unless the correct value is filled to the "password registers".)

Extensions

[edit]

The JEDEC standard only specifies some of the SPD bytes. The truly critical data (for up to DDR3) fits into the first 64 bytes,[6][7][21][22][23] while some of the remainder is earmarked for manufacturer identification. However, a 256-byte EEPROM is standardized (for up to DDR3). A number of uses have been made of the remaining space.

Memory generally comes with conservative timing recommendations in the SPD ROM, to ensure basic functionality on all systems. Enthusiasts often spend considerable time manually adjusting the memory timings for higher speed. Enabling special configurations such as Intel XMP or AMD EXPO often requires additional testing to ensure system stability[24] and may void CPU warranty if used out of the manufacturer’s published specifications.[25][26][27]

Enhanced Performance Profiles (EPP)

[edit]

Enhanced Performance Profiles is an extension of SPD, developed by Nvidia and Corsair, which includes additional information for higher-performance operation of DDR2 SDRAM, including supply voltages and command timing information not included in the JEDEC SPD spec. The EPP information is stored in the same EEPROM, but in bytes 99–127, which are unused by standard DDR2 SPD.[28]

EPP SPD ROM usage
Bytes Size Full profiles Abbreviated profiles
99–103 5 EPP header
104–109 6 Profile FP1 Profile AP1
110–115 6 Profile AP2
116–121 6 Profile FP2 Profile AP3
122–127 6 Profile AP4

The parameters are particularly designed to fit the memory controller on the nForce 5, nForce 6 and nForce 7 chipsets. Nvidia encourages support for EPP in the BIOS for its high-end motherboard chipsets. This is intended to provide "one-click overclocking" to get better performance with minimal effort.

Nvidia's name for EPP memory that has been qualified for performance and stability is "SLI-ready memory".[29] The term "SLI-ready-memory" has caused some confusion, as it has nothing to do with SLI video. One can use EPP/SLI memory with a single video card (even a non-Nvidia card), and one can run a multi-card SLI video setup without EPP/SLI memory.

An extended version, EPP 2.0, supports DDR3 memory as well.[30]

Intel Extreme Memory Profile (XMP)

[edit]
"Intel XMP" redirects here; not to be confused with Intel MPX.

A similar, Intel-developed JEDEC SPD extension was developed for DDR3 SDRAM DIMMs, later used in DDR4 and DDR5 SDRAM as well. XMP uses bytes 176–255, which are unallocated by JEDEC, to encode higher-performance memory timings.[31]

Later, AMD developed AMP, an equivalent technology to XMP, for use in its "Radeon Memory" line of memory modules optimized for use in AMD platforms.[32][33] Furthermore, motherboard developers implemented their own technologies to allow their AMD-based motherboards to read XMP profiles: MSI offers A-XMP,[34] ASUS has DOCP (Direct Over Clock Profile), and Gigabyte has EOCP (Extended Over Clock Profile).[35]

DDR3 XMP

[edit]
XMP SPD ROM usage[36]
DDR3 Bytes Size Use
176–184 9 XMP header
185–219 35 XMP profile 1 ("enthusiast" settings)
220–254 35 XMP profile 2 ("extreme" settings)

The header contains the following data. Most importantly, it contains a "medium timebase" value MTB, as a rational number of nanoseconds (common values are 1/8, 1/12 and 1/16 ns). Many other later timing values are expressed as an integer number of MTB units.

Also included in the header is the number of DIMMs per memory channel that the profile is designed to support; including more DIMMs may not work well.

XMP Header bytes[36]
DDR3 Byte Bits Use
176 7:0 XMP magic number byte 1 0x0C
177 7:0 XMP magic number byte 2 0x4A
178 0 Profile 1 enabled (if 0, disabled)
1 Profile 2 enabled
3:2 Profile 1 DIMMs per channel (1–4 encoded as 0–3)
5:4 Profile 2 DIMMs per channel
7:6 Reserved
179 3:0 XMP minor version number (x.0 or x.1)
7:4 XMP major version number (0.x or 1.x)
180 7:0 Medium timebase dividend for profile 1
181 7:0 Medium timebase divisor for profile 1 (MTB = dividend/divisor ns)
182 7:0 Medium timebase dividend for profile 2 (e.g. 8)
183 7:0 Medium timebase divisor for profile 2 (e.g. 1, giving MTB = 1/8 ns)
184 7:0 Reserved
XMP profile bytes[36]
DDR3 Byte 1 DDR3 Byte 2 Bits Use
185 220 0 Module Vdd voltage twentieths (0.00 or 0.05)
4:1 Module Vdd voltage tenths (0.0–0.9)
6:5 Module Vdd voltage units (0–2)
7 Reserved
186 221 7:0 Minimum SDRAM clock period tCKmin (MTB units)
187 222 7:0 Minimum CAS latency time tAAmin (MTB units)
188 223 7:0 CAS latencies supported (bitmap, 4–11 encoded as bits 0–7)
189 224 6:0 CAS latencies supported (bitmap, 12–18 encoded as bits 0–6)
7 Reserved
190 225 7:0 Minimum CAS write latency time tCWLmin (MTB units)
191 226 7:0 Minimum row precharge delay time tRPmin (MTB units)
192 227 7:0 Minimum RAS to CAS delay time tRCDmin (MTB units)
193 228 7:0 Minimum write recovery time tWRmin (MTB units)
194 229 3:0 tRASmin upper nibble (bits 11:8)
7:4 tRCmin upper nibble (bits 11:8)
195 230 7:0 Minimum active to precharge delay time tRASmin bits 7:0 (MTB units)
196 231 7:0 Minimum active to active/refresh delay time tRCmin bits 7:0 (MTB units)
197 232 7:0 Maximum average refresh interval tREFI lsbyte (MTB units)
198 233 7:0 Maximum average refresh interval tREFI msbyte (MTB units)
199 234 7:0 Minimum refresh recovery delay time tRFCmin lsbyte (MTB units)
200 235 7:0 Minimum refresh recovery delay time tRFCmin msbyte (MTB units)
201 236 7:0 Minimum internal read to precharge command delay time tRTPmin (MTB units)
202 237 7:0 Minimum row active to row active delay time tRRDmin (MTB units)
203 238 3:0 tFAWmin upper nibble (bits 11:8)
7:4 Reserved
204 239 7:0 Minimum four activate window delay time tFAWmin bits 7:0 (MTB units)
205 240 7:0 Minimum internal write to read command delay time tWTRmin (MTB units)
206 241 2:0 Write to read command turnaround time adjustment (0–7 clock cycles)
3 Write to read command turnaround adjustment sign (0=pull-in, 1=push-out)
6:4 Read to write command turnaround time adjustment (0–7 clock cycles)
7 Read to write command turnaround adjustment sign (0=pull-in, 1=push-out)
207 242 2:0 Back-to-back command turnaround time adjustment (0–7 clock cycles)
3 Back-to-back turnaround adjustment sign (0=pull-in, 1=push-out)
7:4 Reserved
208 243 7:0 System CMD rate mode. 0=JTAG default, otherwise in peculiar units of MTB × tCK/ns.
E.g. if MTB is 1/8 ns, then this is in units of 1/8 clock cycle.
209 244 7:0 SDRAM auto self refresh performance.
Standard version 1.1 says documentation is TBD.
210–218 245–253 7:0 Reserved
219 254 7:0 Reserved, vendor-specific personality code.

Newer versions

[edit]

DDR4 specs are not yet publicly available.

AMD Extended Profiles for Overclocking (EXPO)

[edit]

AMD's Extended Profiles for Overclocking (EXPO) is a JEDEC SPD extension developed for DDR5 DIMMs to apply a one-click automatic overclocking profile to system memory.[37][38] AMD EXPO-certified DIMMs include optimised timings certified to work on Zen 4 processors.[39] Unlike Intel's closed standard XMP, the EXPO standard is open and royalty-free.[38] It can be used on Intel platforms.[38] At launch in September 2022, there are 15 partner RAM kits with EXPO-certification available reaching up to 6400 MT/s.[40]

Vendor-specific memory

[edit]

A common misuse is to write information to certain memory regions to bind vendor-specific memory modules to a specific system. Fujitsu Technology Solutions is known to do this. Adding different memory module to the system usually results in a refusal or other counter-measures (like pressing F1 on every boot). 

02 0E 00 01-00 00 00 EF-02 03 19 4D-BC 47 C3 46 ...........M.G.F
53 43 00 04-EF 4F 8D 1F-00 01 70 00-01 03 C1 CF SC...O....p.....

This is the output of a 512 MB memory module from Micron Technologies, branded for Fujitsu-Siemens Computers, note the "FSC" (46 53 43) string. The system BIOS rejects memory modules that don't have this information starting at offset 128h.

Some Packard Bell AMD laptops also use this method, in this case the symptoms can vary but it can lead to a flashing cursor rather than a beep pattern. Incidentally this can also be a symptom of BIOS corruption as well.[41] Though upgrading a 2 GB to a 4 GB can also lead to issues.

Reading and writing SPD information

[edit]

Memory module manufacturers write the SPD information to the EEPROM on the module. Motherboard BIOSes read the SPD information to configure the memory controller.

Onboard SMBus

[edit]

The motherboard SMBus controller is the "raw" way of accessing SPD on a memory module attached to it. Some motherboard chipsets allow selecting whether the SPD should be write protected. To allow access this way, the operating system must include SMBus support, have appropriate drivers for the EEPROMs, and the motherboard SMBus needs to be connected to the SPD EEPROMs.

  • (R) On Linux and FreeBSD, the userspace program decode-dimms provided by i2c-tools decodes and prints JEDEC standard information on any memory with SPD information in the computer. For pre-DDR4 SPD it requires either the "eeprom" or the "at24" driver (24-series EEPROM). For DDR4 SPD it requires either the "eeprom" driver or the "ee1004" driver (34-series EEPROMs defined in JEDEC EE1004).[42][43] On older Linux distributions, decode-dimms.pl was available as part of lm_sensors.
    • (W) The eeprog tool from i2c-tools allows writing to 24-series EEPROMs, i.e. up to DDR3.
  • (RW) On Linux and FreeBSD, the Python script spd-eeprom reads and writes AT24 and EE1004-series EEPROMs. It only provides raw SMBus reading and writing, not decoding. Driver requirements are the same as i2c-tools.[44]
  • (R) On OpenBSD 4.3+ and NetBSD 5.0+, the spdmem(4) driver accesses the EEPROM through the SMBus to provide information about memory modules (only the JEDEC standard part).
  • (R) Coreboot reads and uses SPD information to initialize all memory controllers in a computer with timing, size and other properties. Coreboot is intended to act as a computer's firmware, replacing a BIOS (or UEFI-enabled BIOS).
  • (R) HWiNFO, CPU-Z and Speccy are Microsoft Windows programs that read and display SPD information, including XMP and other extensions.[45]
  • (RW) Thaiphoon Burner (abandonware) is a Windows program that allows reading from and writing to SPD from memory modules up to DDR4 (including XMP). SPDtool is another piece of abandonware of similar purpose.

Other SMBus features

[edit]
Temperature sensor
[edit]

JEDEC has standards for SMBus-addressable temperature sensors on memory strips. TS3000 is for the independent sensor for up to DDR3. TSE2002 is the combined SPD and temperature sensor for up to DDR3. TSE2004 is the combined SPD and temperature sensor for DDR4. SPD5118 is the "hub" that integrates temperature and SPD on DDR5.

RGB LED control
[edit]

Some memory modules (especially on Gaming PCs)[46] support RGB LEDs that are controlled by proprietary SMBus commands. This allows LED color control without additional connectors and cables. Windows kernel drivers from multiple manufacturers required to control the lights have been exploited to gain access ranging from full kernel memory access, to MSR and I/O port control numerous times in 2020 alone.[47][48][49]

SMBIOS

[edit]

The SMBIOS relays data about the memory from the BIOS to the computer. This information is accessed by the dmidecode program, which runs on Linux, FreeBSD, NetBSD, OpenBSD, BeOS, Cygwin and Solaris. Again, it accesses not the SPD information, but SMBIOS information, so data may be limited or incorrect.[50]

Ex situ SMBus

[edit]

By removing the EEPROM chip and transplanting it somewhere else, one can obtain a more direct SMBus access. This helps remove the interference from chipsets.

Laptops and webcams

[edit]

A not so common use for old laptops is as generic SMBus readers, as the internal EEPROM on the module can be disabled once the BIOS has read it so the bus is essentially available for use. The method used is to pull low the A0,A1 lines so the internal memory shuts down, allowing the external device to access the SMBus. Once this is done, a custom Linux build or DOS application can then access the external device. A common use is recovering data from LCD panel memory chips to retrofit a generic panel into a proprietary laptop.

A related technique is rewriting the chip on webcams often included with many laptops, as the bus speed is substantially higher. They can even be modified so that 25-series chips, commonly used in storing a motherboard's UEFI ROM, can be read and written for protection against chip failure.

On some chips it is also a good idea to separate write protect lines so that the onboard chips do not get wiped during reprogramming.

Chip generation issues

[edit]

This unfortunately only works on DDR3 and below, as DDR4 uses a different chip model (34-series) to fit the 512-byte SPD (as opposed to the 256-byte of earlier generations). This chip interface (EE1004/TSE2004) divides its storage into two pages and requires a page-switch to read or write the whole chip.

Some chipsets also do not correctly negotiate the reading of 34-series EEPROM chips so they may even fail to read. The software may return a "Incompatible SMBus driver?" message in response.

DDR5 uses an even more complex design, the SPD5118 "hub" with another doubling of capacity.

On older equipment

[edit]

Some older equipment require the use of SIMMs with parallel presence detect (more commonly called simply presence detect or PD). Some of this equipment uses non-standard PD coding, IBM computers and Hewlett-Packard LaserJet and other printers in particular.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Serial presence detect

View on Grokipedia
from Grokipedia
Serial Presence Detect (SPD) is a standardized hardware feature for computer memory modules that stores configuration data in an electrically erasable programmable read-only memory (EEPROM) chip, allowing the system's basic input/output system (BIOS) or unified extensible firmware interface (UEFI) to automatically detect the module's characteristics and apply appropriate operating parameters during initialization. Developed by the Device Engineering Council (), SPD evolved from the presence detect (PPD) method used in earlier 72-pin single in-line memory modules (SIMMs), which was limited to basic detection, to a serial interface approach introduced with 168-pin dual in-line memory modules (DIMMs) for greater data capacity and flexibility across memory technologies. The data is accessed via a two-wire serial bus, such as or (SMBus), using a specific device address, enabling the host controller to read a structured byte array without manual configuration. Key information encoded in SPD includes the memory type (e.g., DDR, DDR4, DDR5), total capacity and organization, operating speed and voltage, timing parameters for read/write operations, support for features like error-correcting code (ECC), refresh rates, and manufacturer-specific details such as part numbers and serial identifiers, all validated by a for . This standardization ensures compatibility and performance optimization across diverse systems, with ongoing updates to accommodate advancements like LPDDR5 and DDR5 modules.

Overview and History

Definition and Purpose

Serial Presence Detect (SPD) is a standardized mechanism defined by the JEDEC organization under the JESD-21-C specification for storing configuration data within a non-volatile electrically erasable programmable read-only memory (EEPROM) integrated on dynamic random-access memory (DRAM) modules. This embedded EEPROM, typically accessible via a serial interface such as I²C, holds essential details about the memory module produced by the manufacturer. The primary purpose of SPD is to enable automatic detection and configuration of RAM parameters by the system's BIOS, UEFI firmware, or memory controller during initialization, eliminating the need for manual user intervention. Key parameters retrieved include module size, operating speed, access timings, required voltage levels, and organization (such as rank and bank configuration), allowing the system to optimize memory operation without relying on predefined defaults or user-specified settings. By querying the EEPROM serially through dedicated pins on the module's edge connector, the host can read this data in a plug-and-play manner, ensuring compatibility and correct setup for diverse memory types. SPD addresses the increasing complexity of memory modules emerging in the mid-1990s, particularly as systems transitioned from simpler extended data out (EDO) and fast page mode (FPM) RAM to more advanced synchronous DRAM (SDRAM) technologies with variable timings and densities. Its benefits include minimizing configuration errors that could lead to instability or suboptimal performance, facilitating easier installation of compatible modules, and providing access to manufacturer-specific optimizations for enhanced reliability and efficiency. Overall, this automation supports scalable memory upgrades in personal computers, workstations, and servers by ensuring the hardware adapts seamlessly to installed components.

Development and Standards

Serial Presence Detect (SPD) originated from efforts by the Joint Electron Device Engineering Council () to standardize configuration during the mid-1990s transition from proprietary DRAM setups to (SDRAM). This development addressed the need for automated detection of module parameters in systems, enabling plug-and-play compatibility without manual adjustments. The initial framework was integrated with the first SDRAM modules in 1996, marking a key milestone in industry-wide adoption. The core SPD specification is defined in JEDEC Standard No. 21-C, Section 4.1.2, which outlines the serial interface and data structure for presence detection across various memory technologies and form factors. This standard has been revised multiple times through the 2010s to accommodate evolving requirements, with specific annexes added for double data rate (DDR) variants, such as Annex K for DDR3 SDRAM modules (initially released in 2008 and updated to Release 6 in 2014) and Annex L for DDR4 SDRAM modules (first published in 2014). These updates supported higher memory densities and faster clock speeds, ensuring SPD's adaptability to technological advancements. JEDEC plays a central role in mandating SPD inclusion for compliance in all standard modules, promoting among manufacturers. Optional extensions have arisen through collaborations with platform vendors like and ; for instance, Intel's PC100 specification in 1998 refined SPD parameters for 100 MHz SDRAM to enhance system stability. In the , SPD expanded to cover the DDR series, including initial support for in 2000, DDR2 in 2003, and DDR3 in 2007, aligning with broader DDR standardization efforts. In the 2020s, JEDEC continued SPD evolution with dedicated standards for next-generation memories, such as JESD400-5 for DDR5 modules (first released in 2020 and updated annually, with version 1.4 in October 2025 supporting speeds up to DDR5-9200) and JESD406-5 for LPDDR5/5X modules (first published in 2024, with an update to JESD406-5B in October 2025). As of November 2025, SPD remains foundational to memory ecosystems, providing backward compatibility in DDR5 and LPDDR5X designs while coexisting with emerging interconnects like Compute Express Link (CXL) for coherent memory expansion.

Technical Foundation

EEPROM Storage Mechanism

Serial Presence Detect (SPD) relies on an electrically erasable programmable read-only memory (EEPROM) chip to store configuration data for memory modules such as DIMMs and SO-DIMMs. This nonvolatile storage device is typically an I²C-compatible serial EEPROM from the EE1002 family or equivalents, with capacities ranging from 128 bytes in early implementations to larger sizes in modern standards. In initial SDRAM modules, the EEPROM capacity was 256 bytes (2048 bits), as specified in early JEDEC and Intel standards for PC SDRAM. For DDR4 modules, the standard evolved to support 512-byte EEPROM devices to handle expanded data requirements, including module-specific parameters. DDR5 further increased this to 1024 bytes, incorporating hub functions and additional thermal sensor integration to accommodate fine-grained timings and denser configurations. Common examples include the AT24C02 for 256-byte devices and specialized variants like the AT34C02D tailored for SPD applications. The EEPROM interfaces with the system via the System Management Bus (SMBus), a subset of the I²C protocol, using two dedicated pins: SCL for the serial clock and SDA for bidirectional data transmission. These pins are integrated into the memory module's edge connector, allowing the host memory controller or chipset to access the device without interfering with DRAM operations. In DDR5, the interface may extend to I³C for enhanced speed, but SMBus remains the baseline for compatibility. Reliability is ensured through features like software-configurable write protection, which prevents unauthorized modifications via lock bits or session controls. These EEPROMs offer an endurance rating of at least 1 million write/erase cycles per byte and data retention exceeding 40 years under normal operating conditions, making them suitable for long-term module deployment. Physically, the EEPROM is soldered directly onto the memory module's printed circuit board (PCB), positioned near the connector notch for optimal signal integrity and accessibility. This placement allows the chipset to read the SPD data during the Power-On Self-Test (POST) phase, enabling automatic system configuration without manual intervention.

Data Structure and Format

Serial Presence Detect (SPD) data is structured as a contiguous of 128 to bytes stored in an device on the memory module, with the exact size and organization defined by standards for each memory generation to ensure compatibility and readability by host systems. The is logically divided into sections, including a header for metadata, core module parameters, and optional manufacturer-specific , allowing for scalable extensions across technologies from SDRAM to DDR5. For instance, early SDRAM implementations use 256 bytes total, with the first 128 bytes dedicated to essential configuration, while DDR4 expands to 512 bytes and DDR5 to bytes to accommodate advanced features like higher densities and error correction. The header begins with bytes 0 and 1, where byte 0 encodes the number of bytes written by the manufacturer and the CRC coverage range (e.g., 23h indicating 384 bytes used and coverage up to byte 125 in DDR4), and byte 1 specifies the SPD revision level (e.g., 10h for revision 1.0 in SDRAM or 40h for 4.0 in DDR4). Bytes 2 and 3 follow as part of the initial configuration, with byte 2 indicating the DRAM type (e.g., 04h for SDRAM or 0Ch for DDR4) and byte 3 providing additional header details, such as row addressing bits in SDRAM or module memory bus width in DDR4. Manufacturer identification is encoded later using JEP-106 codes, such as in bytes 64–71 for SDRAM (an 8-byte sequence representing the ID) or bytes 320–321 for DDR4 (a 2-byte code, e.g., 04h/80h for certain vendors). Subsequent bytes cover module information, including device size in log base 2 encoding (e.g., byte 4 in DDR4 as 95h for 8 Gbit with 4 bank groups and 8 internal s, using a code that combines and banking configuration), row and column counts (e.g., byte 5 in DDR4 as 21h for 16 rows and 10 columns), intervals (e.g., bytes 30–31 in DDR4 encoding 260 ns as 20h/08h for standard operation), and support (e.g., bytes 20–23 in DDR4 as bit flags for supported latencies from 7 to 24 cycles). Dates, such as manufacturing year and week, are stored in (BCD) format for readability (e.g., bytes 93–94 in SDRAM as 61h/05h for 1997 week 5, or bytes 323–324 in DDR4). Data integrity is maintained through checksum mechanisms tailored to the revision. In basic SDRAM SPD (revision 1.0), a simple 8-bit checksum occupies byte 63, calculated as the sum of bytes 0–62 modulo 256, allowing systems to detect read errors during access. Advanced implementations like DDR4 (revision 4.0 and later) employ a more robust CRC-8 polynomial over bytes 0–125, stored in bytes 126–127, supplemented by a sum modulo 256 on bytes 117–125 for partial verification, ensuring reliable detection of corruption in extended fields supporting 3D-stacked DRAM and on-die ECC. Revision 1.0 provides a foundational format for SDRAM with core parameters like size and timings in the first 64 bytes, while revisions 4.0+ for DDR4 and DDR5 introduce expanded layouts with additional bytes for high-speed operations and features like on-die ECC, maintaining backward compatibility through consistent header placement. Specific fields use compact encodings to optimize space. Speed bins are represented as nibble values in dedicated bytes; for example, in DDR4, byte 18 uses 05h to denote support for 3200 MT/s maximum data rate. Voltage levels are encoded via bit fields or codes, such as in byte 11 of DDR4 where a 2-bit value of 00b indicates 1.2 V operation, 01b for 1.35 V, and other combinations for extended ranges like 1.5 V. These encodings prioritize efficiency, using logarithmic scales for sizes and bitmasks for multi-option parameters like latencies, enabling precise configuration without excessive byte usage.

Core Stored Information

Fundamental Module Parameters

The fundamental module parameters in Serial Presence Detect (SPD) encompass the core attributes of a memory module that are universally applicable across DRAM generations, enabling systems to configure memory access without type-specific knowledge. These parameters include details on the module's physical and logical structure, such as total capacity, which is typically expressed in bits (e.g., 8 GB as 2332^{33} bits) and encoded to reflect the aggregate density of all devices on the module. Ranks, indicating the number of independent memory banks accessible in parallel (commonly single-rank or dual-rank configurations), and the number of internal banks per device (e.g., 8 or 16 banks) are also specified to define the module's organization for addressing and interleaving. Module organization is detailed through the number of row and column address bits required to access data locations, such as 15 row bits by 10 column bits in many DDR4 configurations, which determines the internal array structure and influences burst access patterns. Primary timings, including the CAS latency (tCL), RAS-to-CAS delay (tRCD), and row precharge time (tRP), are provided in clock cycles or nanoseconds (e.g., tCL of 16 cycles at a given frequency) to establish baseline operational speeds for reliable data retrieval and refresh cycles. These timings ensure compatibility with the system's memory controller by specifying minimum delays in standardized units. Electrical specifications cover operating voltage, typically in the 1.2 V to 1.8 V range depending on the generation (e.g., 1.2 V nominal for DDR4), along with drive strength options (e.g., moderate or strong output drivers calibrated to RZQ/7 impedance) and input/output capacitance values (often around 1-2 pF per pin) to match signaling requirements and prevent signal integrity issues. Manufacturing information includes a unique serial number, the manufacturer's JEDEC-assigned part number in ASCII format, the manufacturing date encoded in binary-coded decimal (BCD) as week and year (e.g., week 45 of 2023), and an assembly location code to trace production origins and support quality control. Error handling indicators denote the presence of error-correcting code (ECC) support, such as single-error correction capabilities on the module, and on-module registers (e.g., for registered DIMMs) that buffer address and control signals to enhance stability in high-capacity setups. These fields collectively allow BIOS or firmware to detect and initialize the module correctly, with ECC presence often widening the data bus by 8 bits (e.g., 72-bit for x64 ECC).
Parameter CategoryKey ExamplesTypical Encoding
Size and Density8 GB total (2^33 bits), 8 banksDensity code (e.g., 95h for 8 Gb per device)
Organization15 row x 10 column bits, dual ranksAddressing code (e.g., 29h), rank count (e.g., 09h)
Primary TimingstCL=16 cycles, tRCD=14 ns, tRP=14 nsTiming values in ns or cycles (e.g., 6Eh for 110 ps base)
Electrical1.2 V nominal, RZQ/7 drive, 1.5 pF capacitanceVoltage code (e.g., 03h), driver option (e.g., 01h)
ManufacturingSerial: 0x12345678, Part: "MT40ATF...", Date: Week 45/2023BCD week/year (e.g., 2Dh/7B7h), ASCII string
Error HandlingECC supported, registers presentBus width (e.g., 0Bh for 64+8), config type (e.g., 00h)
This table illustrates representative values from JEDEC-compliant SPD implementations, emphasizing scalability across module types.

Memory Type-Specific Details

Serial Presence Detect (SPD) for Synchronous Dynamic Random-Access Memory (SDRAM) utilizes a basic 128-byte structure within a 256-byte EEPROM, accommodating early memory configurations including fields for compatibility with Extended Data Out (EDO) and Fast Page Mode (FPM) technologies through byte 2, which specifies the memory type such as EDO (02h) or SDRAM (04h). Initial clock speeds ranging from 66 MHz to 133 MHz are encoded in bytes 9 and 10 for cycle and access times (e.g., 10 ns for 100 MHz CL3, 7.5 ns for 133 MHz CL3), with additional Intel-specific frequency details in bytes 126-127. For Double Data Rate (DDR) SDRAM, the SPD expands on the 128-byte format to include fields for burst lengths of 4 or 8, as defined in the mode register and reflected in SPD byte mappings for operational configuration. The architecture supports 4 internal banks per device, with SPD bytes 3-5 detailing row/column addressing and bank count to enable proper memory mapping. Preamble support, indicating the presence of a write preamble for signal integrity, is incorporated into timing parameters within the SPD to align with DDR's double-pumped data transfers. DDR2 SDRAM SPD introduces indicators for on-die termination (ODT) in byte 49, allowing dynamic impedance matching to reduce reflections on the bus, which is essential for higher speeds up to 800 MT/s. Fly-by topology hints are provided through module configuration fields in bytes 5 and 117-125, guiding BIOS in routing address and command signals daisy-chain style for improved signal integrity over multi-drop stubs. Density support extends to up to 4 GB per module, calculated via rank density in byte 116 multiplied by the number of ranks in byte 5, accommodating larger 512 Mb to 1 Gb devices. The DDR3 SDRAM SPD doubles to a 256-byte format to store expanded parameters, including ZQ calibration data in bytes 174-177 for on-die impedance calibration commands that adjust output drivers and termination over PVT variations. Presence of an integrated thermal sensor is flagged in byte 117 (bit 7), enabling temperature monitoring via the SPD EEPROM for thermal throttling decisions. Support for green modes at 1.5 V standard and 1.35 V low-voltage operation is indicated in bytes 8 and 161, optimizing power efficiency for high-density modules up to 16 GB. In DDR4 SDRAM, SPD fields for gear-down mode are located in byte 18 (bit 6 of the fine offset offsets), enabling half-rate address and command latching on every other clock edge to enhance stability at speeds beyond 2400 MT/s. Data bus inversion (DBI) flags in byte 117 (bits 4-5) signal support for inverting data bytes to minimize bus transitions and electromagnetic interference, particularly beneficial for x8 devices. Maximum module capacity reaches 128 GB through 3D stacked (3DS) configurations, with stacking details and rank counts in bytes 5, 116, and 129-131 supporting up to 4 high-density ranks per package. DDR5 SDRAM employs a 512-byte SPD format under JESD400-5D, providing extensive configuration for dual-channel modules with fields for decision feedback equalization (DFE) in bytes 300-307 to mitigate inter-symbol interference at data rates up to 6400 MT/s. As of October 2025, the JESD400-5D standard (version 1.4) supports modules up to DDR5-9200 speeds and includes codes for new form factors like Small Outline Compression Attached Memory Module (SO-CAMM). Per-DRAM addressability (PDA) is supported via byte 380 flags, allowing independent chip select and command addressing for up to 32 DRAMs per channel. Capacity fields in bytes 240-247 accommodate 8-64 GB per channel, scaling with on-die ECC and PMIC integration for higher densities. For emerging Low-Power DDR5 (LPDDR5) and LPDDR5X, the SPD under JESD406-5 (released August 2024) includes mobile-optimized fields for low-voltage operation ranging from 0.5 V to 1.1 V core supply, detailed in bytes 80-95 for VDD/VDDQ scaling to minimize power in battery-constrained devices. Adaptive refresh management is encoded in bytes 200-215, enabling directed or partial-array refreshes to reduce power by up to 20% in idle states while maintaining data integrity, as per 2023-2025 standards.

Performance Extensions

Standard Profiles

Standard profiles in Serial Presence Detect (SPD) encompass the JEDEC-defined configurations for DDR memory modules, providing essential timing, voltage, and operational parameters to enable automatic system configuration for stable, non-overclocked performance. These profiles are encoded in the SPD EEPROM and allow the BIOS or memory controller to select the highest supported speed bin compatible with the system's capabilities, ensuring interoperability across compliant hardware. JEDEC specifies up to eight speed bins per DDR4 module type, ranging from DDR4-2133 (with timings such as CL=15 at 1.2V) to DDR4-3200 (CL=22 at 1.2V), each associated with predefined AC and DC timings, including parameters like tRCD, tRP, and tRAS, as well as slew rates for signal integrity. The SPD stores these details in dedicated bytes—such as byte 18 for minimum clock cycle time (tCKAVG_min) and bytes 20-21 for supported CAS latency values (tCL)—allowing the system to read and apply the appropriate bin without manual intervention. For instance, a DDR4-2666 module's SPD would include timings optimized for that bin while supporting fallback to lower bins like DDR4-2400 if needed. Profile selection occurs during boot, where the BIOS scans the SPD across all modules, identifies the common highest speed bin, and programs the memory controller accordingly, incorporating details like voltage (typically 1.2V for standard operation) and refresh rates to maintain reliability. Modules bearing the JEDEC logo are validated against these profiles, confirming compliance through rigorous testing for stability under standard conditions. Enhanced Performance Profiles (EPP), introduced as an optional extension in 2006, enable higher-speed configurations beyond the baseline bins for certified modules, storing additional timing sets in unused SPD space to support validated overclocks while adhering to JEDEC guidelines. These profiles include extended voltage tolerances and refined timings but remain optional and require system support for activation. Despite their robustness, standard profiles prioritize conservative speeds and voltages to guarantee broad compatibility, limiting support for extreme settings that could compromise stability or longevity.

Vendor and Platform-Specific Profiles

Intel's Extreme Memory Profile (XMP), introduced in 2007 as an extension to the standard JEDEC Serial Presence Detect (SPD) specification, enables one-click of DDR memory modules by storing pre-configured performance profiles directly in the SPD EEPROM. These profiles, typically up to two per module, occupy dedicated byte ranges in the SPD—such as bytes 176-250 for DDR3 implementations and 384-511 for DDR4—to encode optimized settings beyond JEDEC defaults. For example, XMP allows DDR4 modules to achieve speeds like 4000 MT/s with timings such as CL18-22-22 at 1.35V or higher, improving bandwidth for gaming and workloads on platforms. In response to the DDR5 era, AMD launched Extended Profiles for Overclocking (EXPO) in 2022, tailored for Ryzen processors on the AM5 socket to simplify memory overclocking similar to XMP but with optimizations for AMD's Infinity Fabric architecture. EXPO profiles, stored in the SPD, support DDR5 speeds of 6000 MT/s and beyond, often synchronized with the fabric clock (FCLK) at 2000-2100 MHz for 1:1 ratios to maximize latency-sensitive performance in applications like simulations and rendering. Beyond platform leaders, memory vendors implement proprietary SPD extensions for specialized use cases. G.Skill, for instance, embeds custom XMP timings in their Trident Z series modules, fine-tuned for extreme overclocking with low-latency primaries like CL14 at 3600 MT/s on DDR4, allowing enthusiasts to push beyond standard profiles while maintaining stability through validated secondary timings. Corsair integrates SPD profile management via their iCUE software for DDR5 modules, enabling users to create and write custom overclocking configurations—such as adjusted voltages and timings—directly to the EEPROM after enabling SPD Write in the BIOS, facilitating RGB-synced performance tweaks. For enterprise environments, Samsung's server-oriented RDIMM and LRDIMM modules incorporate SPD profiles optimized for registered ECC DDR5 operation, supporting high-capacity configurations up to 96GB per module at 6400 MT/s with on-die ECC for reliability in data centers, though these prioritize error correction over consumer overclocking. JEDEC continues to update DDR5 SPD standards, with the latest revision (JESD400-5D) released in October 2025 to support advanced performance configurations. These vendor and platform-specific profiles generally encode key parameters including operating frequency, primary/secondary latencies (e.g., , tRCD), DRAM voltage (often 1.25-1.4V for DDR5), and command rate (1T or 2T), which are applied by selecting the profile in the . Activation involves navigating to the or settings and toggling the desired XMP or EXPO option, followed by a to load the settings automatically from the SPD. Compatibility enhancements include XMP 3.0, rolled out around for DDR5 support on Intel's 12th-generation Core processors, which expands profile storage to 384 bytes and incorporates fine-grained timings like tREFI and read/write preambles for better precision in high-speed configurations. EXPO is native to AM5 platforms but offers partial with XMP on many AMD motherboards, allowing Intel-certified modules to load profiles via translation, though optimal results require AMD-tuned kits to align with the integrated . While these profiles enhance performance, they carry risks such as system instability from mismatched timings or excessive voltage, potentially leading to crashes, data corruption, or hardware degradation under sustained loads. Additionally, enabling XMP or EXPO constitutes overclocking, which may void CPU or motherboard warranties if damage occurs, as stated by both Intel and AMD policies, though memory module warranties from vendors like G.Skill and Corsair typically cover profile usage.

Access Methods

Reading SPD Data

The reading of SPD data utilizes the I²C or SMBus protocol, which employs a serial transaction sequence to retrieve information from the EEPROM on each memory module. The process begins with the host controller issuing a Start condition on the bus, followed by the 7-bit slave address (ranging from 0x50 to 0x57 to accommodate up to eight modules per channel) shifted left by one bit with the read/write bit set to 1 for read operations; the targeted slave acknowledges if present. For a selective read from a specific byte address, the host first performs a "dataless" write transaction—Start, slave address with read/write bit 0, the desired byte address, and repeated Start—before proceeding to the read phase. In the read phase, the slave transmits data bytes sequentially from the current or specified address, with the host acknowledging each byte via ACK (low) until the final byte, which receives a NoACK (high), followed by a Stop condition to end the transaction. Sequential reads auto-increment the internal address pointer, allowing continuous retrieval across the EEPROM's capacity, which wraps around at the bank end. The SMBus operates at a standard clock speed of up to 100 kHz, ensuring compatibility with system initialization phases, though some implementations support faster modes up to 1 MHz. During system boot, the BIOS or UEFI firmware systematically scans the address range 0x50–0x57 on the memory controller's SMBus channel to detect and read SPD data from installed modules, using this information to configure memory timings, speeds, and population details. This read occurs early in the POST (Power-On Self-Test) sequence, enabling the firmware to populate system configuration structures, such as memory descriptors in ACPI tables, for subsequent operating system handoff. In multi-module configurations, the shared bus handles access to up to eight DIMMs per channel through address-based selection, with the protocol's arbitration mechanism preventing collisions by ensuring only the addressed slave responds during transactions. User-accessible tools facilitate runtime reading of SPD data without disrupting system operation. On Windows, applications like CPU-Z and HWiNFO interface with the SMBus to dump and decode SPD contents, displaying parameters such as module capacity and timings in a user-friendly format. In Linux environments, the i2c-tools package (e.g., via the i2cdump command targeting addresses 0x50–0x57 on the relevant bus) or the decode-dimms utility from the i2c-tools suite extracts and interprets the raw data, often combined with kernel modules like eeprom for direct access. These tools typically operate through the system's SMBus driver, providing non-destructive reads for diagnostic purposes. To ensure , SPD EEPROMs include a CRC (bytes 126–127 for DDR4, calculated over bytes 0–125 using CRC-16-CCITT) that the reader validates upon retrieval; if the CRC fails, indicating potential or read errors, the system falls back to conservative default parameters to maintain stability. This validation is performed both during by and in software tools, with failures logged for .

Writing and Modifying SPD Data

Writing and modifying Serial Presence Detect (SPD) data involves programming the EEPROM chip on memory modules using the protocol, typically reserved for manufacturing or specialized repair scenarios. The process begins by addressing the SPD EEPROM with a slave (commonly 0x50 to 0x57, depending on the module configuration), followed by specifying the internal word and transmitting one or more data bytes. For single-byte writes, the sequence ends with a stop condition, initiating an internal write cycle lasting approximately 15 ms, during which the device becomes unresponsive to further commands. Page writes allow up to 16 bytes to be sent sequentially after the word , still concluding with a single 15 ms write cycle per page, and acknowledge polling—repeated read attempts until an acknowledgment is received—verifies completion to ensure data integrity. Tools for writing SPD data include hardware programmers like the CH341A USB-to-I²C adapter, which connects directly to the module's EEPROM pins (SCL, SDA, and ground) for in-circuit programming without desoldering. This device pairs with open-source software such as IMSProg or AsProgrammer to send I²C commands and flash custom data. For SPD-specific operations, Thaiphoon Burner provides a user-friendly interface to read, edit, and reprogram EEPROM contents, including support for DDR4 and DDR5 modules, though its writing features require a paid license. These tools enable precise byte-level modifications but demand careful pin mapping to avoid short circuits. Primary use cases encompass factory programming, where manufacturers encode module-specific parameters like capacity, speed, and timings into the first 128 bytes of the EEPROM immediately after assembly to comply with JEDEC layouts. Advanced users may modify timings for overclocking or compatibility tweaks, such as adjusting voltage or latency values to enable XMP profiles on non-standard hardware, though this carries significant risks of instability. In rare repair contexts, firmware updates to vendor-specific profiles can restore functionality on mismatched modules. Protections against unauthorized or erroneous writes include hardware features like a dedicated write-protect pin on the , which must be pulled low to enable writing, and software-based temporary or permanent write locks that safeguard critical sections, such as the initial 128 bytes containing JEDEC-mandated data. Some SPD EEPROMs, like STMicroelectronics' M34E02 series, incorporate settable fuses for permanent protection after initial programming. Additionally, modern / implementations often enforce "SPD Write Disable" settings to block runtime modifications, preventing boot-time alterations that could destabilize the system. JEDEC standards emphasize one-time programming of SPD EEPROMs post-module assembly to embed immutable configuration data, ensuring reliable system detection without subsequent user intervention. Repeated write operations accelerate EEPROM degradation due to limited endurance—typically 100,000 to 4 million cycles per byte before cell reliability declines—potentially leading to data corruption over time. Modifying SPD data typically voids the memory module's warranty, as it alters factory-calibrated settings and exposes the hardware to potential failure. Incorrect programming, such as failing to recalculate the CRC (bytes 126–127 for DDR4 base configuration), can render the module unrecognizable to the BIOS, resulting in boot failures or complete bricking where the system refuses to initialize the memory.

Special Features and Applications

Integrated Lighting Control

Integrated lighting control emerged in the mid-2010s alongside the rise of gaming-oriented DDR4 modules, where vendors began incorporating RGB and addressable RGB (ARGB) LEDs to enhance aesthetic appeal. Systems detect hardware via SMBus access to an onboard LED controller at a distinct address separate from the SPD (e.g., 0x72 for controller vs. 0x52 for SPD). The control mechanism relies on an extension of the SMBus (a two-wire I²C variant used for SPD access), enabling communication with onboard LED controllers at distinct I²C addresses separate from the SPD EEPROM. These controllers support synchronization with popular protocols like Aura Sync and MSI Mystic Light, with software applying color modes, effects, and sync parameters via direct bus communication. However, some RGB software has been known to improperly write to the SPD EEPROM, potentially causing and boot issues; enabling SPD write protection is recommended to mitigate this. In practice, vendors such as Corsair implement this in products like the Vengeance RGB series, where the iCUE software queries the LED controller via SMBus for control of lighting capabilities and applies dynamic effects across multiple zones. This integration allows seamless coordination with other system components, though it requires BIOS settings like SPD write enablement for full functionality. Despite its popularity, integrated lighting remains an optional, vendor-proprietary feature outside JEDEC standards, lacking mandatory specifications in core SPD definitions. Power consumption can reach up to 3 W per module due to the LEDs and controller, potentially impacting thermal performance in densely populated systems. Compatibility often demands specific BIOS or firmware support to access the SMBus extensions reliably. As of 2025, the feature has evolved in DDR5 modules to support advanced ARGB setups with per-LED addressing, enabling finer-grained control over individual LEDs (e.g., 10 zones per Corsair Vengeance DDR5 stick) for more complex patterns and synchronization.

Compatibility with Legacy Systems

In the pre-SPD of the 1990s, systems such as those based on I and II processors typically employed Fast Page Mode (FPM) or Extended Data Out () memory modules using 72-pin SIMMs with Parallel Presence Detect (PPD), a resistor-based method limited to basic speed and size identification via dedicated pins. These platforms ignored any SPD present on modules, as lacked the capability to read serial from it, necessitating manual configuration of in the setup to stability. By the early 2000s, with the adoption of 168-pin DIMMs for SDRAM and DDR memory on platforms like Socket 478 motherboards for Pentium 4 processors, partial SPD support emerged, allowing BIOS to read EEPROM data for automatic timing configuration. However, if the SPD data was incompatible or unreadable, systems often reverted to conservative default settings to avoid instability, potentially underutilizing module capabilities. Common issues in mixed or legacy environments include boot loops or failure to initialize memory when SPD data is corrupted, as the BIOS misinterprets timings or module parameters, leading to repeated restarts. High-density modules, such as DDR3 installed in DDR2 slots on older chipsets, may fail recognition entirely due to mismatched electrical or protocol expectations. Workarounds for such incompatibilities involve BIOS options to disable SPD reading and enforce manual timings, effectively bypassing the EEPROM for user-defined parameters. In server environments, some firmware supports virtual SPD emulation to simulate compatible data, while third-party blank EEPROM replacements can mimic pre-SPD modules by providing no detectable serial information. In modern legacy scenarios, such as virtual machine hypervisors or retro builds using adapters, SPD-equipped modules face ongoing challenges; for instance, DDR5 is fully incompatible with pre-2014 platforms designed for DDR3 or earlier due to distinct physical slot keying and signaling requirements. As of 2025, these issues remain relevant primarily for hardware collectors and enthusiasts, with no major new developments, though open-source firmware like enhances support through customizable SPD handling on older platforms.

References

  1. https://www.jedec.org/sites/default/files/docs/4_01_02R19.pdf
  2. https://www.vikingtechnology.com/wp-content/uploads/2021/03/AN0034_SPD_Whitepaper.pdf
  3. https://www.memtest86.com/tech_ram-spd.html
  4. https://www.jedec.org/standards-documents/docs/jesd400-5d
  5. https://www.atpinc.com/tw/blog/DDR5-Compatibility-with-SPD-BIOS-UEFI
  6. https://www.jedec.org/standards-documents/docs/jesd406-5b
  7. https://www.ti.com/lit/ug/smmu001/smmu001.pdf
  8. https://bitsavers.org/components/intel/spd/SPD_Spec_1.2B_199911.pdf
  9. https://www.lenovo.com/us/en/glossary/spd/
  10. https://www.jedec.org/standards-documents/docs/spd-4010211
  11. https://www.jedec.org/sites/default/files/docs/4_01_02_AnnexL-3R25.pdf
  12. https://www.jedec.org/about-jedec/jedec-history
  13. https://www.jedec.org/news/pressreleases/jedec%25C2%25AE-announces-annual-update-ddr5-serial-presence-detect-spd-contents-standard
  14. https://www.jedec.org/news/pressreleases/jedec-releases-new-standard-lpddr55x-serial-presence-detect-spd-contents
  15. https://www.jedec.org/sites/default/files/docs/4_01_02_12R23A.pdf
  16. https://www.mouser.com/datasheet/2/671/ddr5_rdimm_core-3310292.pdf
  17. https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocuments/DataSheets/AT34C02D-2-Kbit-I2C-SPD-EEPROM-Data-Sheet-DS20006480.pdf
  18. https://www.jedec.org/sites/default/files/docs/4_01_03R17.pdf
  19. https://www.ablic.com/en/doc/datasheet/dimm_serial_eeprom_spd/S34HTS08AB_E.pdf
  20. https://www.giantec-semi.com/juchen1123/uploads/pdf/GT34C02_DS_Au.pdf
  21. https://ww1.microchip.com/downloads/aemDocuments/documents/MPD/ProductDocuments/DataSheets/AT34C04_I2C-Compatible_4-Kbit_Serial_EEPROM_with_Reversible_Software_Write_Protection_20006416A.pdf
  22. https://www.simmtester.com/News/PublicationArticle/184
  23. https://www.micron.com/products/memory/dram-modules/rdimm/part-catalog/part-detail/spd-data/mta36asf8g72pz-2g9e1
  24. https://www.jedec.org/sites/default/files/docs/JESD79F.pdf
  25. https://www.jedec.org/sites/default/files/21C_TOCR29.pdf
  26. https://www.jedec.org/sites/default/files/docs/JESD79-2F.pdf
  27. https://www.jedec.org/sites/default/files/docs/4_01_02_10R17.pdf
  28. https://www.jedec.org/sites/default/files/docs/JESD79-3F.pdf
  29. https://www.jedec.org/sites/default/files/docs/4_01_02_11R21A.pdf
  30. https://www.jedec.org/sites/default/files/docs/JESD79-4.pdf
  31. https://www.jedec.org/sites/default/files/docs/4_20_28R24.pdf
  32. https://www.jedec.org/sites/default/files/docs/JESD209-5C.pdf
  33. https://www.jedec.org/standards-documents/docs/spd412l-3
  34. https://www.nvidia.com/content/epp/epp_specifications.pdf
  35. https://www.pcworld.com/article/547528/intels-xmp-memory-overclocking-gets-its-first-substantial-upgrade-since-2007.html
  36. https://www.intel.cn/content/dam/doc/white-paper/extreme-memory-profile-ddr3-technology-paper.pdf
  37. https://skatterbencher.com/intel-extreme-memory-profile-2-0/
  38. https://www.intel.com/content/www/us/en/gaming/extreme-memory-profile-xmp.html
  39. https://www.amd.com/en/products/processors/technologies/expo.html
  40. https://videocardz.com/newz/amd-preparing-expo-extended-profiles-for-overclocking-for-ryzen-7000-ddr5-memory-overclocking
  41. https://www.techpowerup.com/forums/threads/amd-confirms-ddr5-6000-as-sweetspot-memory-oc-frequency-for-ryzen-7000.298436/
  42. https://www.gskill.com/community/1584933243/1646978599/About-Memory-Overclocking
  43. https://www.corsair.com/us/en/explorer/diy-builder/memory/how-to-set-up-corsair-ddr5-memory-in-icue/
  44. https://www.youtube.com/watch?v=9A2omlNc5ws
  45. https://semiconductor.samsung.com/news-events/tech-blog/optimized-ddr5-dimm-solutions-powering-leading-edge-server-memory-modules/
  46. https://serverorbit.com/samsung-m321ryga0pb2-ccpwf-96gb-ram/
  47. https://www.jedec.org/news/pressreleases/jedec%C2%AE-announces-annual-update-ddr5-serial-presence-detect-spd-contents-standard
  48. https://www.gskill.com/community/1584933243/1646893264/How-to-Enable-XMP-EXPO-for-DDR4-DDR5
  49. https://skatterbencher.com/intel-extreme-memory-profile-3-0/
  50. https://videocardz.com/newz/hwinfo-lists-intel-xmp-3-0-for-ddr5-memory-in-upcoming-software-changes
  51. https://www.pcgamer.com/what-are-xmp-profiles-and-how-do-i-use-them/
  52. https://www.overclock.net/threads/amd-ddr5-oc-and-24-7-daily-memory-stability-thread.1800926/page-269
  53. https://www.pcworld.com/article/394250/why-xmp-and-memory-overclocking-are-ok-even-if-they-void-your-warranty.html
  54. https://www.xda-developers.com/myths-amd-expo-intel-xmp/
  55. https://www.onsemi.com/download/data-sheet/pdf/n34c04-d.pdf
  56. https://electronics.stackexchange.com/questions/554703/spd-i2c-address-for-ddr4-sodimm
  57. https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/smbus-controller-i2c-devices-paper.pdf
  58. https://stackoverflow.com/questions/63159663/how-does-bios-initialize-dram
  59. https://www.binarytides.com/check-ram-timings-spd-data-on-linux/
  60. https://hackaday.com/2023/04/18/linux-fu-reading-your-memorys-memory/
  61. https://github.com/bigbigmdm/IMSProg
  62. https://thaiphoonburner.com/
  63. https://www.st.com/en/memories/spd-eeprom.html
  64. https://www.st.com/resource/en/selection_guide/sgeeprom0921_web.pdf
  65. https://www.overclock.net/threads/how-do-i-read-modify-flash-spd-xmp-profiles-on-ddr4-eeprom.1627823/
  66. https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/SMBusAccess.md
  67. https://www.gskill.us/forum/forum/product-discussion/ddr4/trident-z-rgb/13195-aura-g-skill-software-corrupts-spd-s
  68. https://help.corsair.com/hc/en-us/articles/4424077074189-iCUE-What-to-do-if-iCUE-cannot-detect-your-Corsair-RGB-memory-or-control-its-RGB-lighting
  69. https://www.corsair.com/us/en/p/memory/cmh32gx5m2x6400c38/vengeance-rgb-32gb-2x16gb-ddr5-dram-6400mhz-c38-memory-kit-black-cmh32gx5m2x6400c38
  70. https://www.pctechguide.com/computer-memory/memory-presence-detection
  71. https://www.overclock.net/threads/corrupted-ddr5-spd-fix-tutorial.1795935/
  72. https://download.gigabyte.com/FileList/Manual/mb_manual_Z790-AORUS-XTREME-X-ICE_BIOS_e.pdf
  73. https://www.wired.com/story/ddr4-vs-ddr5-explainer/
  74. https://www.coreboot.org/end_users.html
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.