---
title: 'Ramulator: Cycle-Accurate DRAM Simulator'
url: https://www.emergentmind.com/topics/ramulator
type: topic
---

# Ramulator: Cycle-Accurate DRAM Simulator

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 [2308.11030] [2606.13844]. 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 [2308.11030] [2504.15377].

## 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 [2308.11030]. Ramulator 2.1 retains this orientation while emphasizing composability, modern DRAM support, and improved usability through code generation and Python-level composition [2606.13844].

In architectural terms, Ramulator models the microarchitectural components of a modern DRAM system, including channel, rank, bank, row buffer, command arbiter, and data buses [2604.16965]. 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 [2604.16965] [2510.15744]. 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 [2308.11030]. Ramulator 2.1 is likewise described as open-source and under active development [2606.13844].

## 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 [2606.14566]. Every DRAM command is scheduled in cycle-level detail, subject to inter-command timing constraints including \(tRCD\), \(tRP\), \(tRAS\), \(tCCD\), and \(tWTR\) [2606.14566]. The same general view appears in related evaluation work, which describes Ramulator as enforcing relations such as
\[
T_{\mathrm{next\_ACT}} \ge T + tRC,
\]
\[
T_{\mathrm{next\_RD/WR}} \ge T_{\mathrm{ACT}} + tRCD,
\]
and
\[
T_{\mathrm{next\_PRE}} \ge T_{\mathrm{ACT}} + tRAS
\]
for command scheduling [2604.16965].

The 2.0 architecture is presented as a modular layering composed of a frontend, a memory controller, and a channel-plus-DRAM model [2606.14566]. 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 [2606.14566]. 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 [2606.14566]. The channel model is structured as a pipeline of command-queue \(\rightarrow\) rank \(\rightarrow\) bank \(\rightarrow\) subarray \(\rightarrow\) data queue, with JEDEC-compliant timing parameters encapsulated in a DRAM class [2606.14566].

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 [2510.15744]. 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 [2510.15744]. Refresh is modeled as all-bank auto-refresh every \(tREFI\), with precharge required before scheduled refresh [2510.15744].

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 [2606.14566]. 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 [2510.15744].

## 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 [2308.11030]. 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 [2308.11030].

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 [2606.14566]. 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 [2308.11030]. 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 [2606.13844]. 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 [2606.13844]. 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 [2606.13844].

Support for DRAM standards also expands in 2.1. The paper lists DDR3, DDR4, DDR5, LPDDR5, LPDDR6, GDDR6, HBM1, HBM2, HBM3, HBM4, and GDDR7 [2606.13844]. Timing declarations are represented as Python objects, for example `TimingConstraint(level="Bank", preceding=["ACT"], following=["RD"], latency="tRCD")`, and common relationships such as
\[
tRC = tRAS + tRP
\]
and
\[
tRAS \ge tRCD + tRP
\]
are stated explicitly [2606.13844].

## 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” [2308.11030]. 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 [2606.14566] [2604.16965] [2510.15744].

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” [2606.14566] [2510.15744]. 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 [2606.14566]. 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 [2606.14566].

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 \(307.2\) GB/s for \(16\) channels, an effective peak of approximately \(281.2\) GB/s after accounting for periodic all-bank refresh, and simulated behavior that reaches peak bandwidth around \(281\) GB/s with latencies rising from about \(50\) ns to about \(200\) ns as load increases [2606.14566]. Another analysis gives more detailed corrected points: peak simulated bandwidth of \(281.1\) GB/s for \(100\%\) reads at maximum load with simulated MLAT of \(40.3\) ns, and at a \(50\%\) read ratio peak bandwidth of \(260.4\) GB/s with MLAT of \(50.8\) ns; these are described as lying within \(5\%\) of real-system measurements across the entire curve [2510.15744].

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 [2604.16965]. 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 [2604.16965]. 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 [2604.16965].

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 [2604.16965]. 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 [2606.14566] [2510.15744].

## 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 [2606.14566]. The load is swept by varying read/write ratio and NOP frequency, and two primary metrics are measured: throughput \(B\) in GB/s and average request latency \(L\) in ns, where
\[
L = \frac{1}{N}\sum_{i=1}^{N}\bigl(t_{\mathrm{resp},i} - t_{\mathrm{issue},i}\bigr)
\]
[2606.14566].

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 \(64\) B used by default [2510.15744]. The Mess-style latency-bandwidth curve is then constructed by sweeping `--mess.nop_frequency` from \(1\) to \(10\,000\) and measuring MLAT versus bandwidth [2510.15744]. 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` [2510.15744].

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 [2606.13844]. 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 [2606.13844]. At system level, 2.1 uses latency-throughput curves based on long “streaming” sequences to set target throughput \(\lambda\) and serialized “probe” requests to measure access latency \(L\), producing the characteristic knee shape of memory-system saturation [2606.13844].

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 [2606.14566]. 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 [2510.15744].

## 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 [2504.15377]. In this workflow, SCALE-Sim first generates a time-ordered memory-demand trace of \((\text{cycle\_issue}, \text{address}, R/W)\), 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 [2504.15377]. 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 [2504.15377].

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 \(21\%\) 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 \(30.1\%\) lower total execution cycles once DRAM stalls are included [2504.15377]. The paper attributes this reversal to bank conflicts created by the access pattern, underscoring that detailed DRAM modeling can alter system-level architectural conclusions [2504.15377].

Ramulator is also discussed as part of integrated CPU-memory simulation with ZSim and DAMOV [2604.16965]. 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 [2604.16965]. 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 [2308.11030]. 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 [2308.11030]. 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 [2606.13844].

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 [2606.13844]. Across all \(11\) supported standards, Ramulator 2.1 reports reproducing peak bandwidth and knee behavior within less than \(1\%\) of expected real-device values in its system-level validation workflow [2606.13844].

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 [2606.14566] [2510.15744]. 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 [2308.11030] [2604.16965].

Source: https://www.emergentmind.com/topics/ramulator