This is an automated archive made by the Lemmit Bot.

The original was posted on /r/opensource by /u/Wonderful-Chain4375 on 2026-03-04 15:12:19+00:00.

Helloo! I’m building an open hardware project called the Open Memory Initiative (OMI). The short version: I’m trying to publish a fully reviewable, reproducible DDR4 UDIMM reference design, plus the validation artifacts needed for other engineers to independently verify it.

Quick clarification up front because it came up in earlier discussions: yes, JEDEC specs and vendor datasheets exist, and there are open memory controllers. What I’m aiming at is narrower and more practical: an open, reproducible DIMM module implementation, going beyond the JEDEC docs by publishing the full build + validation package (schematics, explicit constraints and layout intent, bring-up procedure, and shared test evidence/failure logs) so someone else can independently rebuild and verify it without NDA/proprietary dependencies.

What OMI is / isn’t

Is: correctness-first, documentation-first, “show your work” engineering.

Isn’t: a commercial DIMM, a competitor to memory vendors, or a performance/overclocking project.

v1 target (intentionally limited)

  • DDR4 UDIMM reference design
  • 8 GB, single rank (1R)
  • x8 DRAM devices, non-ECC (64-bit bus) The point is to keep v1 tight enough that we can finish the loop with real validation evidence.

Where the project is today

The “paper design” phases are frozen so that review can be stable:

  • Stage 5 - Architecture Decisions: DDR4 UDIMM baseline locked
  • Stage 6 - Block Decomposition: power, CA/CLK, DQ/DQS, SPD/config, mechanical, validation plan
  • Stage 7 - Schematic Capture: complete and frozen (power/PDN, CA/CLK, DQ/DQS byte lanes with per-DRAM naming, SPD/config, full 288-pin edge map)

We’ve now entered:

Stage 8 - Validation & Bring-Up Strategy (in progress)

This stage is about turning “looks right” into “can be proven right” by defining:

  • the validation platform(s) (host selection + BIOS constraints + what to log)
  • a bring-up procedure that someone else can follow
  • success criteria and a catalog of expected failure modes
  • review checklists and structured reporting templates

We’re using a simple “validation ladder” to avoid vague claims:

  • L0: artifact integrity (ERC sanity, pin map integrity, naming consistency)
  • L1: bench electrical (continuity, rails sane, SPD bus reads)
  • L2: host enumeration (SPD read in host, BIOS plausible config)
  • L3: training + boot (training completes, OS boots and uses RAM)
  • L4: stress + soak (repeatability, long tests, documented failures)

What I’m asking from experienced folks here

If you have DDR/SI/PI/bring-up experience, I’d really value critique on specific assumptions and “rookie-killer” failure modes, especially:

  1. SI / topology / constraints
  • What are the most common module-level mistakes that still “sort of work” but collapse under training/temperature/platform variance?
  • Which constraints absolutely must be explicit before layout (byte lane matching expectations, CA/CLK considerations, stub avoidance, etc.)?
  1. PDN / decoupling reality checks
  • What are the first-order PDN mistakes you’ve seen on DIMM-class designs?
  • What measurements are most informative early (given limited lab gear)?
  1. Validation credibility
  • What minimum evidence would convince you at each ladder level?
  • What should we explicitly not claim without high-end equipment?

Also: I’m trying to keep the project clean on openness. If an input/model can’t be publicly documented and shared, I’d rather not make it a hidden dependency (e.g., vendor-gated models or “trust me” simulations).

Links (if you want to skim first)

If you think this approach is flawed, I’m fine with that :)

I’d just prefer concrete critique (what assumption is wrong, what failure mode it causes, what evidence would resolve it).