Memory Controller Checklist

The last gatekeeper before off‑chip — where three structural erasures happen in rapid succession and no one is watching.

Session Context#

Overview#

The memory controller is the gateway between Tier 3 (on‑chip LLC) and Tier 4 (off‑chip DRAM). It is the single point through which every evicted cache line, every DMA write, and every coherency writeback must pass before leaving the SoC.

It is also the point where three structural erasures happen in rapid succession:

From LLC / NoC
═══════════════╗
               ║
┌──────────────▼──────────────────────────────────────┐
│  1. Transaction Queue                               │
│     ⚠ TEMPORAL REORDERING                           │
│     Transactions rearranged for row‑buffer locality,│
│     bank pipelining, and QoS priority.              │
│     Original issue order is gone.                   │
├─────────────────────────────────────────────────────┤
│  2. Scheduler / Address Mapper                      │
│     ⚠ SOURCE FLATTENING                             │
│     Requests mapped to physical ranks, banks, rows. │
│     Initiator identity replaced by physical address.│
├─────────────────────────────────────────────────────┤
│  3. PHY Interface                                   │
│     ⚠ CLOCK DOMAIN SHIFT                            │
│     On‑chip clock → memory clock.                   │
│     Temporal reference frame changes.               │
└──────────────┬──────────────────────────────────────┘
               ║
═══════════════╝ → To DIMM / HBM
                   (see DIMM_Module_Checklist.md)

Other D369 files acknowledge these erasures. This document goes inside the memory controller and specifies what structural observability looks like at each internal stage.

Why the Memory Controller Is Special#

The memory controller is the only SoC block where all three structural erasures happen within a single functional unit:

No other block concentrates this much structural information loss in this small a functional area. The NoC distributes its erasures across the fabric. The DIMM's erasures are spread across ranks, banks, and refresh cycles. The memory controller does all three in pipeline order, in nanoseconds.

Memory Controller Internal Architecture#

Expanded Block Diagram#

-
┌──────────────────────────────────────────────────────────────────────┐
│  Memory Controller — Internal Structural View                        │
│                                                                      │
│  From NoC / LLC / DMA                                                │
│  ══════════╗                                                         │
│            ║                                                         │
│  ┌─────────▼────────────────────────────────────────────────────────┐│
│  │  Request Ingress                                                 ││
│  │  · Receives read/write requests from NoC                         ││
│  │  · Each request carries: address, data, size, request type       ││
│  │  · ⚠ Does NOT carry: initiator source ID (unless NoC preserves)  ││
│  └─────────┬────────────────────────────────────────────────────────┘│
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  Transaction Queue (Read + Write)                               │ │
│  │  · Buffers pending requests                                     │ │
│  │  · ⚠ Reorders for efficiency:                                   │ │
│  │    - Row‑buffer hit prioritization                              │ │
│  │    - Bank‑level parallelism                                     │ │
│  │    - Read‑over‑write priority                                   │ │
│  │    - QoS/urgency class arbitration                              │ │
│  │  · ⚠ Original issue order lost after reordering                 │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  Write Combining / Coalescing                                   │ │
│  │  · Merges multiple partial writes to the same address           │ │
│  │  · ⚠ Multi‑source writes collapsed into single transaction      │ │
│  │  · ⚠ Per‑write source identity destroyed if sources differ      │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  Address Mapper / Scrambler                                     │ │
│  │  · Maps logical address → physical (channel, rank, bank, row)   │ │
│  │  · ⚠ Address scrambling for security / wear distribution        │ │
│  │  · ⚠ Source identity fully replaced by physical coordinates     │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  Scheduler                                                      │ │
│  │  · Issues commands to the DRAM interface                        │ │
│  │  · Manages timing constraints (tRCD, tRP, tRAS, tFAW, etc.)     │ │
│  │  · Inserts refresh commands (REF, per‑bank REF)                 │ │
│  │  · ⚠ Refresh is a controller‑initiated phase transition         │ │
│  │  · ⚠ Refresh timing interleaves with data commands              │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  ECC Engine (Controller‑Side)                                   │ │
│  │  · Generates ECC on writes; checks/corrects on reads            │ │
│  │  · ⚠ Controller‑side ECC is distinct from on‑die ECC (ODECC)    │ │
│  │  · ⚠ Corrections are unattributed — clean data returned         │ │
│  │  · ⚠ Error syndrome info may be logged but not source‑tagged    │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  Prefetch Engine                                                │ │
│  │  · Speculatively fetches data from DRAM into controller buffers │ │
│  │  · ⚠ Prefetched data has no explicit requester                  │ │
│  │  · ⚠ If consumed, appears identical to demand‑fetched data      │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  PHY (DDR / LPDDR / HBM Interface)                              │ │
│  │  · Converts controller‑domain signals to memory‑domain          │ │
│  │  · ⚠ Clock domain crossing: core_clk → mem_clk                  │ │
│  │  · ⚠ Serialization, training, calibration                       │ │
│  │  · ⚠ Temporal reference frame changes at this boundary          │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            │                                                         │
│  ┌─────────▼───────────────────────────────────────────────────────┐ │
│  │  Channel Interface (per‑channel)                                │ │
│  │  · One or more independent DRAM channels                        │ │
│  │  · ⚠ Multi‑channel interleaving = another source merge point    │ │
│  │  · ⚠ Channel assignment may differ from original request path   │ │
│  └─────────┬───────────────────────────────────────────────────────┘ │
│            ║                                                         │
│  ══════════╝ → To DIMM / HBM                                         │
│                                                                      │
│  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─           │
│  D369 Structural Metadata Channel: Meta_MEM                          │
│  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─           │
│                                                                      │
│  ┌──────────────────────────────────────────────────────────────────┐│
│  │  Structural Metadata (reserved, optional, dark by default)       ││
│  │                                                                  ││
│  │  · Per‑transaction source attribution log                        ││
│  │  · Reordering annotation (original vs. scheduled sequence)       ││
│  │  · Write‑combining source collision flag                         ││
│  │  · Refresh event log (timing, bank/rank, count)                  ││
│  │  · ECC correction event log (syndrome, location, not content)    ││
│  │  · Prefetch vs. demand‑fetch distinction tag                     ││
│  │  · PHY clock domain reference annotation                         ││
│  │  · Channel assignment log                                        ││
│  │  · Power state transition log (CKE, self‑refresh entry/exit)     ││
│  └──────────────────────────────────────────────────────────────────┘│
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

The Eight Controller Failure Modes#

Each internal stage has a specific failure mode. These extend the module's failure mode taxonomy alongside the DIMM failure modes (FM‑1–FM‑5) and NoC erasures (N‑1–N‑5).

MC‑1: Transaction Queue Reordering#

What happens: The transaction queue reorders pending requests for efficiency — row‑buffer hits before misses, bank‑level parallelism, read‑over‑write priority. The issue order from the NoC is discarded.

What's lost: Causal sequence. If Request A was issued before Request B, but B hits an open row and A doesn't, B executes first. Post‑hoc analysis cannot reconstruct the original order.

Structural parallel: N‑3 (NoC QoS reordering) — same erasure, different location.

Preservation requirement: If structural observability requires temporal reconstruction, the controller must log the mapping between original issue order and scheduled execution order (or at minimum a sequence number per request at ingress).

MC‑2: Source Identity Replacement#

What happens: The address mapper converts a logical address to physical coordinates (channel, rank, bank, row, column). The request's initiator identity — which core, which accelerator, which DMA engine — is not part of the physical address. It is discarded.

What's lost: Source provenance. The DRAM sees an address and data. It does not know who wrote.

Structural parallel: N‑1 (NoC source flattening); FM‑1 (DIMM rank interleaving).

Preservation requirement: Source ID must be preserved as a metadata sideband through the controller pipeline. It does not need to reach the DIMM (the DIMM has no concept of source) — but it must be loggable in Meta_MEM before it is discarded at the PHY boundary.

MC‑3: Write Combining / Coalescing#

What happens: Multiple partial writes to the same cache line or address range are combined into a single full‑width write. This is correct for functional data. For structural metadata, it creates a problem: if Core 0 writes the first half and the AI accelerator writes the second half, the combined write appears as a single transaction with no multi‑source attribution.

What's lost: Per‑write source identity in combined transactions.

Structural parallel: Board Rule 4 (carry provenance through aggregation) — write combining is aggregation at the controller level.

Preservation requirement: When writes from different sources are combined, the metadata channel should flag the combination as a multi‑source write and log the contributing source IDs. The combined data itself is correct — but the provenance must reflect that multiple sources contributed.

MC‑4: Address Scrambling#

What happens: Many controllers scramble the logical‑to‑physical address mapping for security (preventing row‑hammer attacks), thermal distribution, or wear leveling. The scrambling function is typically secret and non‑invertible from outside the controller.

What's lost: The relationship between logical address and physical location. Post‑hoc analysis cannot determine which physical row/bank/rank stored a value without knowing the scrambling function.

Structural impact: Address scrambling does not directly erase source, lifecycle, or time — but it makes physical forensics impossible without controller cooperation. If a DIMM reports an ECC error at physical row X, the system cannot determine which logical address (and therefore which data structure) was affected without unscrambling.

Preservation requirement: D369 does not require exposing the scrambling function (that would be a security risk). But the controller metadata channel should log enough information to map physical error reports back to logical addresses — either by logging the inverse mapping for error events, or by providing a diagnostic interface for authorized unscrambling.

MC‑5: Refresh Scheduling#

What happens: The memory controller issues refresh commands to DRAM on a regular schedule (typically every 7.8 µs per row in DDR4, with variations for DDR5 and temperature‑dependent refresh). Refresh is a maintenance operation that preserves data — but it is also a controller‑initiated phase transition that:

• Temporarily blocks data access to the refreshed bank.
• Resets the retention clock for every cell in the refreshed row.
• Is invisible to software and to the data itself.

What's lost: This is the controller‑side origin of FM‑2 (DIMM refresh as invisible phase transition). The controller decides when to refresh, but the fact that a refresh occurred — and how many times a particular region has been refreshed — is not recorded or exposed.

Preservation requirement: The controller metadata channel should log refresh events: which bank/rank was refreshed, when, and optionally how many refresh cycles have occurred since a given region was last written. This enables downstream analysis of refresh frequency per region — a signal relevant to aging, reliability, and data residency analysis.

MC‑6: Controller‑Side ECC#

What happens: On writes, the controller generates ECC check bits and appends them to the data. On reads, it checks and (if needed) corrects. Corrected data is returned to the requester as if no error occurred.

What's lost: The fact that an error occurred. The error syndrome (which bits were wrong). The frequency of corrections per address region. The distinction between controller‑side ECC and on‑die ECC (ODECC).

Structural parallel: FM‑3 (DIMM ECC as unattributed correction). The controller is actually the first ECC layer — before ODECC and before any module‑level ECC. All three layers mask errors independently.

Preservation requirement: The controller metadata channel should log ECC correction events: address region, syndrome type (single‑bit correctable, multi‑bit detected), and timestamp. The log should not include corrected data content (that would be a functional data exposure). Correction frequency per region is a first‑class structural signal for aging and reliability analysis.

MC‑7: Prefetch Misattribution#

What happens: The prefetch engine speculatively fetches data from DRAM into controller buffers based on access pattern prediction. If the predicted data is later requested by a core, it is served from the buffer instead of DRAM — faster, but with no explicit requester for the original fetch.

What's lost: The distinction between demand‑fetched data (explicitly requested by a source) and speculatively prefetched data (fetched by the controller's prediction engine). If a prefetched value is consumed, it looks identical to a demand fetch in every way — but its provenance is different. The controller decided to fetch it, not the consuming core.

Preservation requirement: Prefetched data should carry a distinguishing tag in the metadata channel: "this fill was initiated by the prefetch engine, not by a core request." This enables post‑hoc analysis to distinguish cache fills driven by actual workload from fills driven by speculation.

MC‑8: Multi‑Channel Interleaving#

What happens: Multi‑channel controllers distribute requests across two or more independent DRAM channels for bandwidth. Channel assignment is typically based on address bits — but the assignment logic means that sequential logical addresses may land on different physical channels.

What's lost: The relationship between request locality and channel locality. A burst of writes from a single source may be interleaved across channels, making per‑channel analysis unable to reconstruct per‑source behavior.

Structural parallel: FM‑1 (DIMM rank interleaving) and FM‑5 (LRDIMM data buffer rank flattening) — the same source‑flattening problem at the channel level.

Preservation requirement: The controller metadata channel should log channel assignment per transaction. When multi‑channel interleaving distributes a source's writes across channels, the metadata should preserve the source‑to‑channel mapping so that per‑source analysis can be reconstructed from per‑channel data.

Failure Mode Summary Table#

The Checklist#

Organized by controller subsystem. Each item maps to a contractual requirement (R1–R7), a controller failure mode (MC‑1–MC‑8), and where applicable a downstream DIMM failure mode or board preservation rule.

§1 — Request Ingress and Source Attribution#

§2 — Transaction Queue and Temporal Ordering#

§3 — Write Combining and Coalescing#

§4 — Address Mapping and Scrambling#

§5 — Refresh Scheduling#

§6 — ECC and Error Handling#

§7 — Prefetch Engine#

§8 — PHY and Clock Domain#

§9 — Power State Management#

§10 — Metadata Channel Independence#

The Memory Controller Review Question#

At every design review involving the memory controller, this checklist prompts one question:

"If a value passed through the memory controller — could we later determine who initiated the transaction, when it was issued vs. when it was scheduled, whether it was combined with other writes, whether it was corrected by ECC, and what the memory clock domain was at the time?"

If the answer is "yes, without redesign," the controller is aligned.

If the answer is "no, but we could log it without changing the data path," the reservation is achievable — return to the failing items.

If the answer is "no, and logging it would affect the data path," something has gone wrong — R3 (independence) has been violated. Escalate.

Handoff Points#

The memory controller sits between two other D369 checklists:

-
  ┌────────────────────────────────────┐
  │  Internal Design‑Review Checklist  │
  │  (SoC‑wide, items 2.10–2.12)       │
  │  Covers: NoC source attribution,   │
  │  DMA tagging, cache coherency      │
  └──────────────┬─────────────────────┘
                 │
                 ▼ (requests arrive at memory controller)
  ┌────────────────────────────────────┐
  │  Memory Controller Checklist       │  ◄── YOU ARE HERE
  │  (this document, 55 items)         │
  │  Covers: everything between NoC    │
  │  ingress and PHY output            │
  └──────────────┬─────────────────────┘
                 │
                 ▼ (data leaves the SoC)
  ┌────────────────────────────────────┐
  │  DIMM Module Checklist             │
  │  (38 items)                        │
  │  Covers: everything from gold edge │
  │  connector to die‑internal state   │
  └────────────────────────────────────┘

Upstream handoff: The memory controller inherits source IDs from the NoC. If the NoC strips source IDs (erasure N‑1), the controller cannot recover them. Item 1.1 depends on the Internal Design‑Review Checklist items 2.10 and 2.12.

Downstream handoff: The memory controller's PHY output connects to the DIMM. Everything logged in Meta_MEM before the PHY is on‑chip information. Everything the DIMM tracks (per DIMM_Module_Checklist.md) is off‑chip information. The PHY is the boundary between the two checklists.

What This Checklist Is Not#

This checklist exists so memory controller engineers can say:

"We didn't change how the controller moves data — we just made sure it remembers what happened along the way."

Relationship to Other D369 Files#

Canon Alignment#

Module: D369_Chip_Spec · File: Memory_Controller_Checklist.md · Version: 0.1.0 · TriadicFrameworks / RTT

Structural Summary — What This File Adds to D369#

New taxonomy introduced: MC‑1 through MC‑8 — eight named controller failure modes that extend the module's erasure catalog alongside N‑1–N‑5 (NoC) and FM‑1–FM‑5 (DIMM). Two are unique to the controller (MC‑4 address scrambling, MC‑7 prefetch misattribution); the rest have structural parallels to existing failure modes at different hierarchy levels.

55 checklist items across 10 sections, organized by controller subsystem — each traceable to a specific R‑requirement and MC failure mode. The sections cover the full internal pipeline: ingress → transaction queue → write combining → address mapping → refresh → ECC → prefetch → PHY → power management → metadata independence.

Meta_MEM expanded — the metadata channel spec from Diagram_SoC now has nine concrete log types (source attribution, reordering annotation, write‑combining collision flag, refresh events, ECC corrections, prefetch tags, PHY clock reference, channel assignment, power state transitions).

Handoff chain completed — the three‑checklist cascade is now explicit: Internal Design‑Review Checklist (SoC‑wide) → Memory Controller Checklist (on‑chip gateway) → DIMM Module Checklist (off‑chip). The PHY boundary is the dividing line between the last two.