Back to Portfolio
EN TR
Hardware Architecture Domain-Specific Accelerator

MDX — Molecular Dynamics Accelerator Architecture

A correctness-first, pre-silicon domain-specific accelerator architecture for classical molecular-dynamics workloads.

Selman Ali Dokumacı

Independent Hardware Research Project | 2026

Current Evidence: Reference models through v0.12, subsystem and integrated-path RTL verification, bounded validation-workload replay, and Phase 8J.3B deterministic real-workload mapping.

Overview

MDX is an independently developed, pre-silicon domain-specific accelerator architecture for classical molecular-dynamics workloads. The current MDX-1 baseline explores a multi-tile architecture for nonbonded interaction processing, contribution generation, force accumulation/reduction, and ownership-aware routing and persistence.

The high-level scope of the architecture also encompasses critical aspects of MD computations, including periodic geometry handling, spatial pair selection, Verlet-list reuse and rebuild logic, and explicit lifecycle orchestration.

It is important to emphasize that while MDX is designed for classical MD algorithms, the architecture is intrinsically generalized and is not inherently GROMACS-specific, allowing potential integration with a wide variety of molecular dynamics engines and software ecosystems.

Architecture Baseline

MDX-1 Fabric

  • Fabric Configuration: 4 × 4
  • Scale: 4 × 4 / 16-tile architectural baseline
  • Target Workload: Classical Molecular Dynamics

The MDX-1 baseline defines a 4 × 4, 16-tile architectural namespace. At the current evidence level, the executable models specify architectural accounting and correctness semantics. Concrete routing topology, physical mapping, queueing, memory organization, timing, and datapath choices remain unresolved.

Correctness-First Design

The MDX development methodology relies strictly on a correctness-first paradigm. In hardware accelerator design for scientific computing, silent numerical errors or precision drift can render long-running simulations completely invalid. Therefore, the architecture is being developed with absolute priority on deterministic numerical correctness over speculative performance optimizations.

Each currently modeled correctness domain, from interaction accounting to periodic geometry and lifecycle behavior, is defined through explicit contracts and checked against executable reference models.

Reference-Model Progression (v0.1 – v0.12)

The architectural specifications have evolved systematically through version 0.12, establishing a verified baseline through successive conceptual stages:

Architectural accounting and lifecycle

Established the foundational state machine and lifecycle tracking for particle assignments and task distribution across the fabric.

Numerical pair/workload reference

Defined deterministic evaluation logic for pairwise interactions, establishing the numerical baseline for force and energy calculations.

Spatial and periodic geometry

Integrated minimum-image conventions and spatial mapping rules required for accurately handling periodic boundary conditions in dense molecular systems.

Verlet-list reuse and periodic workload integration

Introduced correctness models for stored-list construction, conservative reuse/rebuild eligibility, and validated periodic workload composition.

Explicit lifecycle and configuration-transition orchestration

Adds explicit caller-controlled periodic configuration transition with mandatory fresh rebuild and optional immediate evaluation, while preserving earlier lifecycle boundaries.

Validation Strategy

The validation strategy uses executable golden/reference models as software correctness oracles for the behaviors defined by each specification. They provide deterministic comparison targets for future implementation work, but they are not timing models or evidence of physical hardware.

Keeping algorithmic correctness contracts separate from future RTL allows later implementations to be checked against explicit reference behavior without implying that RTL or silicon has already been validated.

RTL Verification Evidence

Banked force accumulator

  • • RTL simulation PASS
  • • 110,089 total accepted
  • • 0 errors

Validation-workload replay

  • • Verilator PASS
  • • 238,528 accepted updates
  • • 0 force/status/epoch mismatches
  • • 0 N3L/protocol errors

Writeback conservation

  • • 67,957 enqueued
  • • 67,957 committed

Real-workload mapping

  • • Phase 8J.3B
  • • GROMACS-derived state → deterministic MDX mapping
  • • 16 dense sources / 0 gaps / 0 duplicates
  • Mapping evidence, not RTL replay

Verification results are simulation/testbench evidence and are not measured physical-hardware performance.

Current Boundaries

Evidence Boundary Constraints

The MDX project adheres to strict evidence-based reporting. The following boundaries define the current state of the architecture as of specification v0.12:

  • Silicon Status: Pre-silicon. The project is in the architectural definition and reference modeling phase.
  • RTL Scope: Subsystem and integrated-path RTL verification evidence is available; full MDX-1 real-workload RTL integration remains in progress.
  • Performance: There is no validated hardware performance model.
  • Metrics: No measured hardware performance, speedup, throughput, frequency, power, area, FPGA, or ASIC results are currently reported.

Engineering Roadmap

1

Reference Specifications & Golden Models

Established

2

Force Arithmetic RTL

Verified blocks

3

Banked Force Accumulator

RTL simulation verified

4

Validation-Workload Replay

Verilator PASS

5

Tile / Cross-Tile Fabric

Prototype & integration evidence

6

GROMACS-Derived Workload Mapping

Phase 8J.3B established

7

Real-Workload RTL Replay

In progress

8

FPGA Demonstration

Future

9

Measured Hardware Performance / Energy

Future

10

ASIC Feasibility

Future