DIMM Module Checklist
Where memory controller meets silicon — the persistence boundary that silently erases phase, source, and time.
Session Context#
| Field | Value |
|---|---|
| Module | D369_Chip_Spec |
| File | DIMM_Module_Checklist.md |
| Role | diagnostic · reference |
| Version | 0.1.0 |
| Status | First‑fill |
| Lineage | Derived from Board_Level_Alignment.md §Memory + Capture_Source.md |
| Audience | Memory engineers · DIMM designers · System architects · Students · AIs |
Overview#
The DIMM is the most structurally dangerous component on the board.
Not because it does anything wrong — because it does everything silently. Every read and write crosses a persistence boundary. Every rank interleave erases source identity. Every refresh cycle is an invisible phase transition. Every ECC correction is an unattributed intervention. Every power state change collapses temporal context.
And none of this is logged. None of it is tagged. None of it survives the round trip.
Other board components erase structural information by accident. The DIMM erases it by design — because no one ever asked it not to.
This checklist asks.
Why the DIMM Is Special#
The Board‑Level Alignment document identifies memory as the first domain where alignment is not optional. The DIMM is where that domain becomes physical.
┌─────────────────────────────────────────────────────┐
│ Memory Hierarchy (structural view) │
│ │
│ Register → L1 → L2 → L3 → DRAM → NVM → Storage │
│ ▲ ▲ ▲ ▲ ▲ │
│ │ │ │ │ │ │
│ phase phase phase phase phase │
│ boundary boundary boundary boundary boundary │
│ ▲ │
│ │ │
│ ┌────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ │ DIMM │ ◄── YOU ARE HERE │
│ │ │ │
│ │ The DRAM │ │
│ │ persistence│ │
│ │ boundary │ │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────┘
The DRAM boundary is unique in the hierarchy because it is:
- The widest persistence boundary. Billions of cells across multiple ranks and banks, all presenting as a single flat address space.
- The most active boundary. Millions of reads, writes, and refreshes per second — each one a micro‑phase‑transition.
- The most opaque boundary. The memory controller sees addresses and data. It does not see which die produced a value, when that value was last refreshed, or whether ECC silently corrected it.
- The only boundary with its own power states. Self‑refresh, CKE power‑down, and deep power‑down are DIMM‑internal decisions that are invisible to the system.
What DIMMs Already Provide#
Modern DIMMs are not structurally blank. They already carry metadata infrastructure — but none of it was designed for structural observability.
| Component | Present In | What It Does | What It Doesn't Do |
|---|---|---|---|
| SPD EEPROM | All DIMMs | Stores module identity, timing parameters, manufacturer info | Does not carry runtime state, lifecycle, or lineage |
| TSOD (Thermal Sensor) | DDR4+ | Reports die temperature | Does not tag thermal events with source or phase |
| RCD (Registering Clock Driver) | RDIMMs | Buffers command/address, distributes clocks | Does not preserve source identity across re‑clocking |
| Data Buffers | LRDIMMs | Buffer data between controller and DRAM dies | Flatten rank identity — controller sees one logical rank |
| PMIC (Power Management IC) | DDR5+ | Per‑DIMM voltage regulation | Does not tag power state transitions with lifecycle |
| ECC (on‑die or module‑level) | ECC DIMMs | Corrects single‑bit errors, detects multi‑bit errors | Does not attribute corrections to source or cause |
| eFuse / One‑Time Programmable | Most dies | Stores post‑manufacture trim, repair, and ID data | Static — does not track runtime phase transitions |
The gap: DIMMs have metadata about the module (SPD) and metadata about physical conditions (TSOD, PMIC). They have no metadata about structural state — who wrote a value, in what lifecycle phase, when it was produced, whether it was corrected, or how many refresh cycles it has survived.
The Five DIMM Failure Modes#
These are the specific ways DIMMs erase structural information. Each one maps back to the four preservation rules from Board‑Level Alignment.
FM‑1: Rank Interleaving Erases Source Identity#
What happens: The memory controller distributes writes across ranks and banks for performance. A value written by CPU Core 0 may land in Rank 0, Bank 3. A value written by the AI accelerator may land in Rank 1, Bank 7. On read‑back, the controller returns data by address — it does not know which source produced which value.
What's lost: Source identity (origin identifier per R2.1).
Why it matters: If two sources write conflicting values to the same region, the system cannot determine provenance after the fact. The DIMM presents a flat address space — source history is gone.
Preservation rule violated: Rule 4 (carry provenance through aggregation).
FM‑2: Refresh as Invisible Phase Transition#
What happens: DRAM cells decay. Refresh cycles restore charge to maintain data integrity. This is a phase transition — the value moves from "recently written" to "refreshed copy" — but the transition is invisible. No counter tracks how many refresh cycles a value has survived. No tag distinguishes fresh data from data that has been refreshed thousands of times.
What's lost: Temporal context (monotonic time per R2.1, R4.1).
Why it matters: A value refreshed 10,000 times is physically identical to a value refreshed once. But structurally, they are different — one is near its origin; the other is a deep copy sustained by maintenance. Without refresh awareness, the system cannot distinguish "current" from "maintained."
Preservation rule violated: Rule 2 (annotate every re‑clock) — refresh is a temporal re‑assertion.
FM‑3: ECC as Unattributed Correction#
What happens: On‑die ECC (ODECC) or module‑level ECC detects and corrects single‑bit errors. The corrected value is returned as if nothing happened. The system receives clean data — but does not know that an error occurred, what caused it (radiation, aging, thermal stress), or how often corrections happen on this cell or region.
What's lost: Source attribution of corrections (Board‑Level Alignment §Power/Thermal/Reliability).
Why it matters: A cell that requires frequent ECC correction is structurally degraded — but the system sees it as healthy. The correction masks the signal. If corrections cluster in a region, that's an aging or reliability signal that is structurally valuable but operationally invisible.
Preservation rule violated: Rule 3 (verify every translation) — ECC translates errors into clean data without preserving the original signal.
FM‑4: Power States Collapse Temporal Context#
What happens: DIMMs enter self‑refresh, CKE power‑down, or deep power‑down to save energy. During self‑refresh, the DIMM maintains data autonomously — the memory controller is disconnected. When the controller reconnects, the DIMM resumes as if nothing happened. But during self‑refresh, the DIMM's temporal relationship to the system is severed. The system clock advanced; the DIMM's internal state did not.
What's lost: Temporal integrity across power boundaries (R4.1, R4.2).
Why it matters: A monotonic timestamp that was valid before self‑refresh may be meaningless after — the DIMM has experienced a temporal gap that is invisible to both the controller and the data. Values written before power‑down are temporally orphaned.
Preservation rule violated: Rule 2 (annotate every re‑clock) — the clock domain crossing at power state boundaries is unannotated.
FM‑5: Data Buffer Rank Flattening (LRDIMM‑Specific)#
What happens: Load‑Reduced DIMMs (LRDIMMs) use data buffers to present multiple physical ranks as fewer logical ranks to the memory controller. This improves electrical performance but erases rank‑level source identity. The controller sees Logical Rank 0 — it does not know whether the data came from Physical Rank 0, 1, 2, or 3.
What's lost: Source identity at the rank level (R5.1).
Why it matters: Rank‑level identity is the finest granularity of source information available on a DIMM. When data buffers flatten it, the last structural coordinate within the DIMM is lost. The system can address a byte — but it cannot determine which physical rank stored it.
Preservation rule violated: Rule 4 (carry provenance through aggregation) — the data buffer aggregates ranks and strips identity.
DIMM Module Topology#
Standard RDIMM (DDR5)#
┌─────────────────────────────────────────────────────────────────┐
│ DIMM Module Boundary │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Gold Edge Connector (to board / memory slot) │ │
│ │ ════════════════════════════════════════════════════════ │ │
│ │ CMD/ADDR ──► │ DATA ◄──► │ ALERT ◄── │ SPD ◄──► │ │
│ └────────────────┼────────────┼────────────┼───────────────┘ │
│ │ │ │ │
│ ┌────────────────▼────────────┐ │ │
│ │ RCD (Registering Clock │ │ │
│ │ Driver) │ │ │
│ │ · Re‑clocks CMD/ADDR │ │ │
│ │ · Distributes to ranks │ │ │
│ │ ⚠ Clock domain crossing │ │ │
│ │ ⚠ Source identity: N/A │ │ │
│ └────┬───────────┬───────────┘ │ │
│ │ │ │ │
│ ┌────▼────┐ ┌────▼────┐ ┌──────▼──────┐ │
│ │ Rank 0 │ │ Rank 1 │ │ SPD Hub │ │
│ │ │ │ │ │ · Module ID │ │
│ │ ┌─────┐ │ │ ┌─────┐ │ │ · Timing │ │
│ │ │Die 0│ │ │ │Die 0│ │ │ · Mfr info │ │
│ │ │ ECC │ │ │ │ ECC │ │ │ · TSOD │ │
│ │ └─────┘ │ │ └─────┘ │ │ (static + │ │
│ │ ┌─────┐ │ │ ┌─────┐ │ │ thermal) │ │
│ │ │Die 1│ │ │ │Die 1│ │ └─────────────┘ │
│ │ │ ECC │ │ │ │ ECC │ │ │
│ │ └─────┘ │ │ └─────┘ │ ┌─────────────┐ │
│ │ ... │ │ ... │ │ PMIC │ │
│ │ ┌─────┐ │ │ ┌─────┐ │ │ · Voltage │ │
│ │ │Die N│ │ │ │Die N│ │ │ · Power │ │
│ │ │ ECC │ │ │ │ ECC │ │ │ · State │ │
│ │ └─────┘ │ │ └─────┘ │ │ (no phase │ │
│ └─────────┘ └─────────┘ │ tagging) │ │
│ └─────────────┘ │
│ │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ D369 Structural Observability (not present today) │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Structural Metadata (reserved, optional, dark by default)│ │
│ │ │ │
│ │ · Per‑rank source identity tag │ │
│ │ · Refresh cycle counter (per bank or region) │ │
│ │ · ECC correction log (event, not content) │ │
│ │ · Power state transition log (entry / exit / duration) │ │
│ │ · Lifecycle phase tag (externally writable) │ │
│ │ · Monotonic time marker (module‑local) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
How to read this diagram:
- Solid section (top): The DIMM as it exists today — RCD, ranks, dies, SPD, PMIC. All unchanged.
- Dashed section (bottom): The D369 structural observability reservation — what would be added. Optional, passive, dark by default.
- ⚠ markers: Points where structural information is currently lost.
The Checklist#
Organized by DIMM subsystem. Each item maps to a contractual requirement (R1–R7) and a failure mode (FM‑1 through FM‑5).
1. Module Identity and Lifecycle#
| # | Check | Req | FM |
|---|---|---|---|
| 1.1 | SPD carries a unique, non‑mutable module origin identifier. | R5.1 | FM‑1 |
| 1.2 | Lifecycle phase tag is present and externally writable. | R5.2 | — |
| 1.3 | Lifecycle tag is not inferred from power state or temperature. | R5.2 | FM‑4 |
| 1.4 | Module identity survives hot‑swap and re‑enumeration. | R5.1 | FM‑1 |
| 1.5 | Lifecycle tag is independent of SPD write‑protect status. | R5.2 | — |
2. Source Identity and Rank Structure#
| # | Check | Req | FM |
|---|---|---|---|
| 2.1 | Each physical rank has a distinguishable source identifier. | R5.1 | FM‑1 |
| 2.2 | Rank interleaving does not erase per‑rank source attribution. | R2.1 | FM‑1 |
| 2.3 | Data buffers (LRDIMM) preserve physical rank identity. | R5.1 | FM‑5 |
| 2.4 | Rank identifier is statically assigned, not routing‑dependent. | R5.1 | FM‑5 |
| 2.5 | Source identity is readable without interrupting functional access. | R3.1 | — |
3. Temporal Integrity and Refresh#
| # | Check | Req | FM |
|---|---|---|---|
| 3.1 | A monotonic time reference exists at the module level. | R4.1 | FM‑2 |
| 3.2 | Time reference is not resettable during normal operation. | R4.2 | FM‑2 |
| 3.3 | Refresh cycle count is trackable per bank or per region. | R2.1 | FM‑2 |
| 3.4 | Refresh does not reset or overwrite temporal markers. | R4.2 | FM‑2 |
| 3.5 | Time marker survives self‑refresh entry and exit. | R4.2 | FM‑4 |
| 3.6 | Self‑refresh duration is annotated (entry time, exit time). | R2.1 | FM‑4 |
| 3.7 | Temporal gap during power‑down is recorded, not hidden. | R4.1 | FM‑4 |
4. ECC and Error Handling#
| # | Check | Req | FM |
|---|---|---|---|
| 4.1 | ECC corrections are logged as events (count, location, time). | R2.1 | FM‑3 |
| 4.2 | Correction log does not include corrected data content. | — | — |
| 4.3 | Corrections are attributed to source (rank, bank, region). | R5.1 | FM‑3 |
| 4.4 | Correction frequency per region is observable. | R2.1 | FM‑3 |
| 4.5 | ECC corrections do not reset temporal markers. | R4.2 | FM‑3 |
| 4.6 | On‑die ECC (ODECC) events are distinguishable from module ECC. | R5.1 | FM‑3 |
| 4.7 | Multi‑bit error detection events are logged even if uncorrectable. | R2.1 | FM‑3 |
5. Power State and Thermal#
| # | Check | Req | FM |
|---|---|---|---|
| 5.1 | Power state transitions are tagged (entry time, exit time, type). | R2.1 | FM‑4 |
| 5.2 | Self‑refresh entry does not erase metadata state. | R7.1 | FM‑4 |
| 5.3 | CKE power‑down does not collapse structural tags. | R7.1 | FM‑4 |
| 5.4 | Deep power‑down explicitly declares metadata loss if unavoidable. | R7.1 | FM‑4 |
| 5.5 | PMIC state transitions are logged as structural events. | R2.1 | FM‑4 |
| 5.6 | Thermal events (TSOD alerts) are tagged with timestamp and rank. | R2.1 | FM‑3 |
| 5.7 | Thermal throttling does not silently discard structural metadata. | R3.3 | FM‑4 |
6. Metadata Isolation and Independence#
| # | Check | Req | FM |
|---|---|---|---|
| 6.1 | Metadata channel is electrically isolated from data paths. | R1.2 | — |
| 6.2 | Metadata is accessible without functional bus contention. | R3.1 | — |
| 6.3 | No functional logic depends on metadata presence. | R3.2 | — |
| 6.4 | Metadata channel can remain dark without impact. | R3.1 | — |
| 6.5 | Metadata does not ride the CMD/ADDR bus. | R1.2 | — |
| 6.6 | Metadata does not share the SPD I²C/I³C bus unless protocol‑safe. | R1.2 | — |
7. Protection Against Removal#
| # | Check | Req | FM |
|---|---|---|---|
| 7.1 | Reserved metadata structures are documented in SPD or design spec. | R7.1 | — |
| 7.2 | Metadata structures are not removable by module test flow. | R7.1 | — |
| 7.3 | Metadata reservation survives die revision and stepping changes. | R7.1 | — |
| 7.4 | BOM changes do not silently replace metadata‑capable components. | R7.1 | — |
| 7.5 | Removal of metadata structures requires explicit design decision. | R7.1 | — |
The DIMM Review Question#
At every DIMM design review, this checklist prompts one question:
"If a value was written to this DIMM — could we later determine who wrote it, when it was written, how many times it was refreshed, whether it was corrected, and what power state the module was in?"
If the answer is "yes, without redesign," the DIMM is aligned.
If the answer is "no, but we could add that without changing functional behavior," the reservation is achievable.
If the answer is "no, and adding it would affect functional behavior," something has gone wrong — revisit R3.
Existing Infrastructure Mapping#
Where possible, D369 structural observability reuses or extends what DIMMs already have. This table maps D369 needs to existing DIMM infrastructure.
| D369 Need | Existing DIMM Infrastructure | Extension Required |
|---|---|---|
| Module identity | SPD EEPROM (manufacturer, serial) | Add lifecycle phase tag (externally writable field) |
| Rank‑level source identity | Physical rank select lines | Preserve through data buffers; make readable externally |
| Temporal reference | None at module level | Add monotonic counter (low‑frequency, non‑resettable) |
| Refresh tracking | REF command counter (controller) | Mirror or shadow to module‑local metadata |
| ECC event logging | Error status register (some dies) | Extend to per‑region event log accessible via sideband |
| Power state logging | PMIC state (DDR5+) | Add transition timestamps and lifecycle annotation |
| Thermal event tagging | TSOD temperature readout | Add per‑event timestamps and rank attribution |
| Metadata bus | SPD Hub I³C bus (DDR5+) | Evaluate for sideband metadata use; verify isolation |
Key insight: DDR5's I³C sideband bus and PMIC architecture already provide the physical infrastructure for most of these extensions. The gap is not electrical — it is structural. The wires exist. The semantics don't.
DDR Generation Applicability#
Not all checklist items apply equally across DDR generations. This matrix shows where each generation stands.
| Checklist Area | DDR4 UDIMM | DDR4 RDIMM | DDR5 RDIMM | DDR5 LRDIMM | Future |
|---|---|---|---|---|---|
| Module Identity (§1) | Partial | Partial | Strong | Strong | Full |
| Source Identity (§2) | Weak | Weak | Moderate | Weak (FM‑5) | Full |
| Temporal Integrity (§3) | None | None | Feasible | Feasible | Full |
| ECC Logging (§4) | Minimal | Minimal | Moderate | Moderate | Full |
| Power State (§5) | None | None | Moderate | Moderate | Full |
| Metadata Isolation (§6) | None | None | Feasible | Feasible | Full |
| Protection (§7) | None | None | Feasible | Feasible | Full |
Key takeaway: DDR5 is the inflection point. Its I³C sideband bus, per‑module PMIC, and SPD Hub architecture make structural observability physically feasible for the first time. DDR4 modules can satisfy identity requirements but lack the sideband infrastructure for temporal, ECC, or power state observability.
What This Checklist Is Not#
| It is NOT… | Explanation |
|---|---|
| A JEDEC specification extension | This checklist does not propose changes to JEDEC standards. |
| A memory controller requirement | The controller is upstream; this addresses the module itself. |
| A data retention requirement | No guarantees about how long data persists. |
| A security specification | Metadata does not carry encryption, authentication, or access control. |
| A performance requirement | No timing, bandwidth, or latency constraints are implied. |
| A telemetry mandate | No data collection, reporting, or transmission is required. |
| A replacement for RAS features | Existing reliability, availability, and serviceability features are unaffected. |
This checklist exists so memory engineers can say:
"We didn't change how the DIMM works — we just made sure it remembers what happened."
Relationship to Other D369 Files#
| File | Relationship |
|---|---|
Board_Level_Alignment.md |
Parent document — §Memory Hierarchy defines the persistence boundary model |
Capture_Source.md |
Source of structural principles: phase/source/time preservation |
Contractual_Requirements.md |
R1–R7 requirements that this checklist instantiates for DIMMs |
Design_Review_Checklist.md |
Chip‑level checklist that this document extends to the memory module |
Memory_Alignment.md |
Deep‑dive on full memory hierarchy alignment (all tiers) |
Adoption_Roadmap.md |
Phase 2 (Silicon Reservation) includes DIMM‑level structural hooks |
Canon Alignment#
| Check | Status |
|---|---|
| Zero drift | ✅ All failure modes derived from Board_Level_Alignment §Memory and Capture_Source |
| Structural contract | ✅ Role: diagnostic + reference — validation checklist with cross‑references |
| Lineage clean | ✅ Every checklist item traceable to R1–R7 requirements and specific failure modes |
| Student‑ready | ✅ Failure modes as concrete DIMM examples; topology diagram with reading guide |
| AI‑parsable | ✅ Numbered checklist items with requirement and failure mode tracing |
| Cross‑module refs | ✅ Imports from Board_Level_Alignment and Contractual_Requirements; extends to module level |
| Non‑claims preserved | ✅ Explicit "What This Checklist Is Not" section; no performance or JEDEC claims |
| Engineer bar | ✅ "Didn't change how the DIMM works — just made sure it remembers what happened" |
Module: D369_Chip_Spec · File: DIMM_Module_Checklist.md · Version: 0.1.0 · TriadicFrameworks / RTT
What makes this file structurally unique in the module:
- Five named failure modes (FM‑1 through FM‑5) give memory engineers a concrete vocabulary for DIMM‑level structural erasure — each one traceable to the four preservation rules from Board‑Level Alignment and the R1–R7 contractual requirements.
- 38 checklist items across 7 sections, every one double‑traced to both a requirement ID and a failure mode — this is the kind of audit artifact that survives design reviews.
- DDR generation applicability matrix makes DDR5 the clear inflection point — the I³C sideband bus, per‑module PMIC, and SPD Hub architecture make structural observability physically feasible for the first time.
- Existing infrastructure mapping shows the gap is semantic, not electrical — the wires are already there in DDR5; what's missing is the structural meaning.
- RDIMM topology diagram with the dashed D369 layer visually separates "what exists today" from "what would be reserved."