Ramulator: Cycle-Accurate DRAM Simulator

• Ramulator is a cycle-accurate DRAM simulator that models DRAM and memory-controller operations using precise timing constraints and a modular design.
• It supports various DRAM standards like DDR5, LPDDR5, and HBM3 through a configurable architecture that enables rapid design-space exploration.
• It facilitates performance, security, and reliability studies by integrating with larger simulation environments via Python-based interfaces and code generation.

Searching arXiv for Ramulator-related papers to ground the article in current literature. Ramulator is a family of cycle-accurate DRAM simulators used to model DRAM and memory-controller behavior for current and emerging memory systems. In the recent literature, Ramulator 2.0 is described as a “highly modular and extensible DRAM simulator” that abstracts key components of a DRAM-based memory system into shared interfaces and independent implementations, while Ramulator 2.1 is described as “a composable memory system simulator for modern DRAM systems” that extends the framework toward broader DRAM-feature coverage, a Python-based modeling interface, and more comprehensive testing and validation workflows (Luo et al., 2023, Luo et al., 11 Jun 2026). Across these versions, Ramulator is positioned as an infrastructure for performance, security, and reliability studies, as well as for integration into larger simulation environments and end-to-end accelerator analysis (Luo et al., 2023, Raj et al., 21 Apr 2025).

1. Definition and scope

Ramulator is a cycle-accurate DRAM simulator that models DRAM and memory-controller operations at command granularity. The literature characterizes Ramulator 2.0 as enabling “rapid and agile implementation and evaluation of design changes in the memory controller and DRAM,” and as maintaining a modular decomposition in which modeled functions are exposed through shared interfaces and independent implementations (Luo et al., 2023). Ramulator 2.1 retains this orientation while emphasizing composability, modern DRAM support, and improved usability through code generation and Python-level composition (Luo et al., 11 Jun 2026).

In architectural terms, Ramulator models the microarchitectural components of a modern DRAM system, including channel, rank, bank, row buffer, command arbiter, and data buses (Esmaili-Dokht et al., 18 Apr 2026). The simulator enforces standard timing constraints such as $tRCD$, $tRAS$, $tRP$, $tRC$, $tCCD$, $tRRD$, and $tFAW$, and schedules commands such as ACT, PRE, READ, WRITE, and REFRESH subject to those constraints (Esmaili-Dokht et al., 18 Apr 2026, Luo et al., 17 Oct 2025). A plausible implication is that Ramulator occupies the methodological space between analytic memory models and full hardware implementation, supplying sufficient timing detail for command-level studies while remaining configurable enough for design-space exploration.

The family is also explicitly open-source. Ramulator 2.0 is released under the permissive MIT license and hosted at the CMU-SAFARI repository (Luo et al., 2023). Ramulator 2.1 is likewise described as open-source and under active development (Luo et al., 11 Jun 2026).

2. Core architecture and simulation model

Ramulator 2.0 is described as having a cycle-accurate event-driven core with a single global “current cycle” counter; at each cycle, pending events such as command issue, refresh start or end, and data-bus transfers are delivered to the appropriate module (Bostanci et al., 12 Jun 2026). Every DRAM command is scheduled in cycle-level detail, subject to inter-command timing constraints including $tRCD$, $tRP$, $tRAS$, $tRAS$0, and $tRAS$1 (Bostanci et al., 12 Jun 2026). The same general view appears in related evaluation work, which describes Ramulator as enforcing relations such as

$tRAS$2

$tRAS$3

and

$tRAS$4

for command scheduling (Esmaili-Dokht et al., 18 Apr 2026).

The 2.0 architecture is presented as a modular layering composed of a frontend, a memory controller, and a channel-plus-DRAM model (Bostanci et al., 12 Jun 2026). The frontend accepts either pre-recorded memory-access streams or dynamically generates requests according to user-supplied patterns such as pointer-chase, streaming with NOPs, or the Mess Request Generator (Bostanci et al., 12 Jun 2026). The memory controller receives high-level read and write requests, allocates Miss-Status-Holding-Registers (MSHRs), performs cache-backing lookups, and enqueues DRAM commands into per-channel command queues; it also implements pluggable scheduling policies including FRFCFS, scheduled refresh interleaving, and write draining (Bostanci et al., 12 Jun 2026). The channel model is structured as a pipeline of command-queue $tRAS$5 rank $tRAS$6 bank $tRAS$7 subarray $tRAS$8 data queue, with JEDEC-compliant timing parameters encapsulated in a DRAM class (Bostanci et al., 12 Jun 2026).

Other descriptions of Ramulator 2.0 present a closely related hierarchy: frontend, memory controller, channel, rank, bank-group, bank, row or column queues, and a DRAM device model that includes a timing-constraint checker and event queues for ACT, PRE, READ, WRITE, and REFRESH (Luo et al., 17 Oct 2025). Read and write queues are described as completely decoupled, and FR-FCFS scheduling is defined as selecting the oldest ready command while prioritizing row hits over row misses (Luo et al., 17 Oct 2025). Refresh is modeled as all-bank auto-refresh every $tRAS$9, with precharge required before scheduled refresh (Luo et al., 17 Oct 2025).

This design is coupled to configuration-driven operation. Ramulator 2.0 accepts plain-text or JSON-style configuration files; an example DDR5-4800 configuration specifies DRAM type, channel count, channel width, frequency, timing parameters, refresh interval, MSHR count, cache-to-memory latency, and the scheduler (Bostanci et al., 12 Jun 2026). A separate configuration example for DDR5-4800AN specifies channel_count = 16, channel_width_bits = 32, scheduler = FR_FCFS, refresh_policy = all_bank, and explicit read and write queue sizes of 32 (Luo et al., 17 Oct 2025).

3. Modularity, extensibility, and supported standards

A defining property of Ramulator 2.0 is its modularity. The 2023 description states that the simulator “abstracts and models key components in a DRAM-based memory system and their interactions into shared interfaces and independent implementations,” enabling easy modification and extension of the modeled functions of the memory controller and DRAM (Luo et al., 2023). Its DRAM specification syntax is described as concise and human-readable, and the implementation includes “a library of reusable templated lambda functions” for modeling DRAM-command functionality, which is intended to simplify implementation of new DRAM standards including DDR5, LPDDR5, HBM3, and GDDR6 (Luo et al., 2023).

The same modularity is reflected in extension mechanisms described elsewhere. To add a new scheduler in Ramulator 2.0, one implements a C++ class derived from the Scheduler interface; to add a new DRAM standard, one subclasses DRAM and fills in the JEDEC timing tables (Bostanci et al., 12 Jun 2026). A concrete demonstration of extensibility is the implementation of “a wide variety of RowHammer mitigation techniques” as separate modular implementations that do not require modification of the baseline memory-controller code (Luo et al., 2023). This suggests that Ramulator 2.0 treats controller policies and DRAM mechanisms as exchangeable modules rather than monolithic simulator logic.

Ramulator 2.1 generalizes this direction. It introduces a “Python-based modeling and configuration interface backed by a two-way code-generation framework” that hides low-level C++ code behind high-level DRAM specifications written in Python and automatically creates Python proxies for all simulator components (Luo et al., 11 Jun 2026). In 2.1, the core architecture is organized around a single abstract controller base class, and new DRAM-standard or controller mechanisms are inserted as small subclasses that inject additional protocol logic via “filtering predicates” expressed as C++ lambdas (Luo et al., 11 Jun 2026). Example features implemented this way include parallel row or column issue in HBM3, HBM4, and GDDR7; split two-phase activation in LPDDR5 and LPDDR6; and dynamic WCK or RCK clock synchronization (Luo et al., 11 Jun 2026).

Support for DRAM standards also expands in 2.1. The paper lists DDR3, DDR4, DDR5, LPDDR5, LPDDR6, GDDR6, HBM1, HBM2, HBM3, HBM4, and GDDR7 (Luo et al., 11 Jun 2026). Timing declarations are represented as Python objects, for example TimingConstraint(level="Bank", preceding=["ACT"], following=["RD"], latency="tRCD"), and common relationships such as

$tRP$0

and

$tRP$1

are stated explicitly (Luo et al., 11 Jun 2026).

4. Validation, accuracy, and methodological disputes

Ramulator’s recent literature includes a substantial discussion of validation methodology and of disagreements over modeling accuracy. Ramulator 2.0 is described in its original presentation as “rigorously validated” while maintaining “a fast simulation speed compared to existing cycle-accurate DRAM simulators” (Luo et al., 2023). Later work, however, argues that evaluation of simulator accuracy depends critically on correct configuration, correct interpretation of reported statistics, and correct CPU-memory interface modeling (Bostanci et al., 12 Jun 2026, Esmaili-Dokht et al., 18 Apr 2026, Luo et al., 17 Oct 2025).

Two 2025–2026 papers directly contest negative claims made in “A Mess of Memory System Benchmarking, Simulation and Application Profiling,” referred to as “the Mess paper” (Bostanci et al., 12 Jun 2026, Luo et al., 17 Oct 2025). Their central argument is that the Mess paper’s results for Ramulator 2.0 are incorrect because of configuration and usage errors. The errors identified include a channel-width or bandwidth extrapolation error, in which a single DDR5 channel with m_channel_width=32 bits was extrapolated as though each channel were 64 bits wide and then multiplied by 8 rather than 16 for comparison against a 16-channel real system (Bostanci et al., 12 Jun 2026). A second reported error is the use of unrealistically low CPU or memory-controller latency settings, specifically hard-coding cache-to-memory latency to 0 CPU cycles and assigning each core 1024 MSHRs, which is said to compress end-to-end latency below realistic CPU-to-DRAM round-trip times (Bostanci et al., 12 Jun 2026).

Under corrected configuration, the papers report that Ramulator 2.0 reproduces both the shape and the absolute values of DDR5-4800 bandwidth-latency curves. One analysis gives a theoretical peak of $tRP$2 GB/s for $tRP$3 channels, an effective peak of approximately $tRP$4 GB/s after accounting for periodic all-bank refresh, and simulated behavior that reaches peak bandwidth around $tRP$5 GB/s with latencies rising from about $tRP$6 ns to about $tRP$7 ns as load increases (Bostanci et al., 12 Jun 2026). Another analysis gives more detailed corrected points: peak simulated bandwidth of $tRP$8 GB/s for $tRP$9 reads at maximum load with simulated MLAT of $tRC$0 ns, and at a $tRC$1 read ratio peak bandwidth of $tRC$2 GB/s with MLAT of $tRC$3 ns; these are described as lying within $tRC$4 of real-system measurements across the entire curve (Luo et al., 17 Oct 2025).

A separate line of work broadens the critique from configuration mistakes to interface fidelity. “Different Perspectives of Memory System Simulation” argues that accuracy must be evaluated from three complementary perspectives: the memory simulator view, the CPU-memory interface view, and the application view (Esmaili-Dokht et al., 18 Apr 2026). In the baseline Ramulator integration with ZSim via DAMOV, the paper reports that these views diverged sharply: the memory simulator view roughly followed hardware; the interface view showed inflated bandwidth and reduced latency due to a clock-scaling bug; and the application view collapsed to an unrealistically constant latency because ZSim’s immediate-response model allowed dependent accesses to overlap (Esmaili-Dokht et al., 18 Apr 2026). The paper attributes the primary source of inaccuracy to the CPU-memory interface and proposes corrections including timestamp-driven clock synchronization, an immediate-response latency controller, corrected address mapping, realistic NoC modeling, and prefetcher emulation (Esmaili-Dokht et al., 18 Apr 2026).

A common misconception, therefore, is that simulator accuracy can be inferred directly from internal DRAM statistics. The literature argues instead that correctness depends on both simulator-internal timing and the fidelity of the interface between CPU and memory models (Esmaili-Dokht et al., 18 Apr 2026). Another misconception is that a “reproducible” artifact is necessarily correct; the Ramulator 2.0 evaluation papers explicitly distinguish reproducibility from correctness and emphasize complete disclosure of configuration files, source revisions, and trace or generator inputs (Bostanci et al., 12 Jun 2026, Luo et al., 17 Oct 2025).

5. Workflows, metrics, and practical use

Ramulator is used in both standalone DRAM studies and integrated end-to-end simulation workflows. For Ramulator 2.0, one documented methodology drives the simulator with the Mess Request Generator, which reproduces a mixed workload containing a Stream pattern of sequential read or write bursts with inserted NOPs and a Pointer-chase pattern of fully random reads that enforce high row-buffer miss rates (Bostanci et al., 12 Jun 2026). The load is swept by varying read/write ratio and NOP frequency, and two primary metrics are measured: throughput $tRC$5 in GB/s and average request latency $tRC$6 in ns, where

$tRC$7

(Bostanci et al., 12 Jun 2026).

A related Ramulator 2.0 evaluation uses three named metrics: MLAT for the average memory access latency of dependent pointer-chase requests, REQ/s for aggregate request throughput, and Bandwidth (GB/s), defined as REQ/s multiplied by bytes per request, with $tRC$8 B used by default (Luo et al., 17 Oct 2025). The Mess-style latency-bandwidth curve is then constructed by sweeping --mess.nop_frequency from $tRC$9 to $tCCD$0 and measuring MLAT versus bandwidth (Luo et al., 17 Oct 2025). The same source provides a concrete reproduction workflow using system.ini, the MessRequestGenerator frontend, and scripts such as parse_stats.py and plot_latency_bw.py (Luo et al., 17 Oct 2025).

Ramulator 2.1 moves much of this workflow into Python. Users instantiate proxies such as TrafficGenerator, FRFCFSController, and DDR5, compose them into a Simulation, and call run() to invoke the compiled C++ engine (Luo et al., 11 Jun 2026). The framework also supports authoring DRAM standards in Python and regenerating the affected C++ modules, while a pytest-based unit-test harness is used for fine-grained validation of command sequences and timing behavior (Luo et al., 11 Jun 2026). At system level, 2.1 uses latency-throughput curves based on long “streaming” sequences to set target throughput $tCCD$1 and serialized “probe” requests to measure access latency $tCCD$2, producing the characteristic knee shape of memory-system saturation (Luo et al., 11 Jun 2026).

The literature also records explicit best practices. Four are stated for Ramulator 2.0 users and developers: read the JEDEC standard and simulator documentation; understand the tool’s memory organization and configuration API; know exactly what statistics the simulator reports; and contact simulator authors when unexpected results are observed (Bostanci et al., 12 Jun 2026). Additional reproducibility guidance includes publishing the exact system.ini, validating peak bandwidth against the JEDEC theoretical formula, using built-in statistics outputs rather than ad hoc parsers, cross-checking against hardware microbenchmarks, and bundling frontends, configs, build scripts, and analysis tools with the artifact (Luo et al., 17 Oct 2025).

6. Integrations, applications, and research uses

Ramulator is not limited to isolated DRAM experiments. One documented use is integration into SCALE-Sim v3, where Ramulator replaces a fixed-latency “black-box” memory model with a cycle-accurate, parameterizable subsystem for accelerator studies (Raj et al., 21 Apr 2025). In this workflow, SCALE-Sim first generates a time-ordered memory-demand trace of $tCCD$3, passes that trace to Ramulator through its C++ API in trace-driven mode, and then replays the original compute timeline while stalling processing elements until the corresponding memory requests complete (Raj et al., 21 Apr 2025). The Ramulator timing core is left unmodified; a thin wrapper around the Request class captures request-completion time, latency, and row-buffer hit or miss statistics (Raj et al., 21 Apr 2025).

This integration exposes concrete effects of DRAM timing on accelerator conclusions. SCALE-Sim v3 reports that Ramulator-based DRAM analysis changes dataflow comparisons that would appear different under idealized memory assumptions: whereas SCALE-Sim v2 shows a $tCCD$4 reduction in compute cycles for six ResNet18 layers using weight-stationary dataflow compared to output-stationary, SCALE-Sim v3 with Ramulator finds that output-stationary exhibits $tCCD$5 lower total execution cycles once DRAM stalls are included (Raj et al., 21 Apr 2025). The paper attributes this reversal to bank conflicts created by the access pattern, underscoring that detailed DRAM modeling can alter system-level architectural conclusions (Raj et al., 21 Apr 2025).

Ramulator is also discussed as part of integrated CPU-memory simulation with ZSim and DAMOV (Esmaili-Dokht et al., 18 Apr 2026). In that setting, the emphasis is not only on DRAM timing itself but on synchronization across simulators, address mapping fidelity, NoC latency, and prefetcher effects, all of which influence whether application-visible behavior matches actual hardware (Esmaili-Dokht et al., 18 Apr 2026). This suggests that Ramulator’s utility depends both on its internal timing model and on how rigorously it is embedded into larger simulation stacks.

A broader application area is security and reliability research. Ramulator 2.0 explicitly showcases RowHammer mitigation techniques that require different memory-controller design changes, each added as a separate implementation without changes to the baseline controller (Luo et al., 2023). This is consistent with the simulator’s modular formulation, in which controller policies, timing mechanisms, and DRAM-standard features can be varied independently.

7. Evolution of the framework

The recent sequence of papers portrays Ramulator as evolving from a modular DRAM simulator toward a broader composable memory-system framework. Ramulator 2.0 emphasizes shared interfaces, independent implementations, human-readable specification syntax, reusable templated lambda functions for command functionality, and support for standards such as DDR5, LPDDR5, HBM3, and GDDR6 (Luo et al., 2023). Ramulator 2.1 is presented as a “major overhaul” that improves the simulator in three directions: support for modern and emerging DRAM and memory-controller features, better usability and extensibility, and more comprehensive tests and validation workflows (Luo et al., 11 Jun 2026).

The added 2.1 infrastructure is substantial. It includes the Python-based modeling and configuration interface, two-way code generation, auto-generated Python proxies for all components, fine-grained validation of timing constraints and scheduling behavior, system-level latency-throughput validation, and a DRAM command trace visualizer with panels for bus utilization and command timelines (Luo et al., 11 Jun 2026). Across all $tCCD$6 supported standards, Ramulator 2.1 reports reproducing peak bandwidth and knee behavior within less than $tCCD$7 of expected real-device values in its system-level validation workflow (Luo et al., 11 Jun 2026).

At the same time, the evaluation literature around Ramulator has shifted attention toward artifact quality, configuration transparency, and post-publication correction. The extended abstract “Re-Evaluating the Real-System Modeling Accuracy of Ramulator 2.0” and the full paper “Cleaning up the Mess” explicitly argue for more stringent artifact completeness, mechanisms for errata, and post-publication artifact updates (Bostanci et al., 12 Jun 2026, Luo et al., 17 Oct 2025). A plausible implication is that Ramulator has become not only a simulator but also a focal case in broader debates about validation standards for computer architecture tools.

Taken together, these papers define Ramulator as a technically detailed, openly extensible, and actively scrutinized simulation platform for DRAM-based memory systems. Its significance lies both in the command-level fidelity of its DRAM modeling and in the methodological demands it imposes: accurate results require correct timing parameters, correct interface integration, correct interpretation of statistics, and complete disclosure of experimental configuration (Luo et al., 2023, Esmaili-Dokht et al., 18 Apr 2026).