Ramulator 2: Cycle-Accurate DRAM Simulator

• Ramulator 2 is a modern, cycle-accurate DRAM simulator that abstracts key memory system components into modular interfaces for rapid prototyping of controller policies and DRAM features.
• It implements detailed timing models for modern standards like DDR5, LPDDR5, HBM3, and GDDR6, enabling precise simulation of performance, security, and reliability metrics.
• The simulator integrates with full CPU-memory stacks, facilitating controlled experiments on scheduling, refresh, and RowHammer mitigation while ensuring validation against real-system behavior.

Ramulator 2 denotes the modern line of cycle-accurate DRAM simulators built around Ramulator 2.0 and extended by Ramulator 2.1. Ramulator 2.0 is a “highly modular and extensible DRAM simulator” that abstracts key components in a DRAM-based memory system and their interactions into shared interfaces and independent implementations, enabling rapid implementation and evaluation of design changes in the memory controller and DRAM for performance, security, and reliability research. It is used both as a standalone DRAM and memory-controller simulator and as a backend in integrated CPU-memory simulation stacks, where its scientific value depends not only on DRAM timing fidelity but also on correct configuration, correct statistic selection, and correct CPU-memory interfacing (Luo et al., 2023, Esmaili-Dokht et al., 18 Apr 2026).

1. Scope and role in memory-systems research

Ramulator 2.0 is described as a modern, modular, cycle-accurate DRAM and memory-controller simulator. In the memory-systems community, simulators of this class are used to evaluate new memory architectures, controller policies, and system designs before hardware exists. Ramulator 2.0 extends the original Ramulator with detailed timing models for modern standards such as DDR5, configurable memory-controller policies such as FR-FCFS, and a pluggable frontend interface so it can be driven by CPUs, trace generators, or synthetic request generators (Luo et al., 17 Oct 2025).

The original Ramulator 2.0 paper emphasizes modularity and extensibility as first-order design goals. Its abstractions are intended to make it easier to modify controller functions, extend DRAM standards, and prototype mechanisms that target performance, security, and reliability. The paper also states that Ramulator 2.0 implements a concise and human-readable DRAM specification syntax and a library of reusable templated lambda functions for DRAM command functionality, and that it is rigorously validated while maintaining fast simulation speed compared to existing cycle-accurate DRAM simulators (Luo et al., 2023).

This positioning places Ramulator 2 in a specific methodological niche: it is neither only a trace player nor a full-system simulator. Rather, it is a DRAM-centric substrate that can be studied in isolation or embedded in larger stacks. A plausible implication is that claims about “Ramulator 2 accuracy” are meaningful only when the evaluation level is specified precisely: DRAM-internal timing, CPU-memory interface behavior, or application-visible performance.

2. Architectural principles and extensibility

The central architectural claim of Ramulator 2.0 is that key memory-system components and their interactions are abstracted into shared interfaces and independent implementations. That decomposition is intended to support rapid and agile implementation of design changes in the memory controller and DRAM, including new standards and controller mechanisms, without rewriting a monolithic codebase (Luo et al., 2023).

The same paper identifies several concrete mechanisms behind that extensibility. Ramulator 2.0 uses a concise and human-readable DRAM specification syntax, and it implements reusable templated lambda functions to model DRAM commands. The standards explicitly named in the abstract are DDR5, LPDDR5, HBM3, and GDDR6. The paper further showcases modularity by implementing a variety of RowHammer mitigation techniques as separate implementations that do not require changing code in the baseline memory-controller implementation (Luo et al., 2023).

A later redesign, Ramulator 2.1, makes these extensibility goals more explicit by introducing a Python-based modeling and configuration interface backed by a two-way code-generation framework. In Ramulator 2.1, high-level DRAM specifications are written in Python, Python proxies are automatically created for simulator components, and users can rapidly create variants of DRAM standards and automate design-space-exploration workflows. The 2.1 paper also reports reductions in non-blank, non-comment source lines for listed standards from 3,199 to 1,079, including DDR5 from 402 to 132, and shows that a DDR5 extension with a Victim Row Refresh command can be written in 18 lines in the DDR5_VRR example (Luo et al., 11 Jun 2026).

The overall significance of this architecture is not only software engineering convenience. It affects what kinds of research can be done. When controller policies, DRAM standards, and mitigation mechanisms are separable modules, Ramulator 2 becomes a platform for controlled experiments on scheduling, refresh, RowHammer mitigation, and new protocol features rather than only a fixed-model benchmark target.

3. Frontends, integrated stacks, and validation perspectives

Ramulator 2 can be driven in different ways. The literature describes a pluggable frontend interface in Ramulator 2.0 and later discusses Ramulator 2 as part of a full CPU-memory simulation stack. In “Different Perspectives of Memory System Simulation,” Ramulator 2 is integrated with ZSim through a custom interface and is evaluated not just by DRAM-internal statistics but by how well the integrated simulator reproduces real load-to-use latencies seen by applications (Luo et al., 17 Oct 2025, Esmaili-Dokht et al., 18 Apr 2026).

That work introduces a three-perspectives methodology. The memory simulator view concerns DRAM request completion times and bandwidth as seen at the memory controller. The CPU-memory interface view concerns the latency and throughput perceived at the boundary between ZSim and the DRAM simulator. The application view concerns load-to-use latency as experienced by CPU cores. The paper’s principal conclusion is that these views can diverge sharply, and that application-level performance is often decoupled from internal simulator statistics because the CPU-memory interface is the primary source of inaccuracies (Esmaili-Dokht et al., 18 Apr 2026).

Two integration issues are especially important. First, the work identifies incorrect cross-clocking between a CPU at 2.1 GHz and a DDR4-2666 DRAM backend, and replaces integer freqRatio scheduling with time-based tick scheduling in picoseconds. Second, it identifies a mismatch between ZSim’s immediate-response memory approximation in its bound phase and the cycle-accurate DRAM model in its detailed phase. To reduce that mismatch, it updates the immediate-response latency with a proportional-integral-style rule:

$$L_{\text{IR}}^{(k+1)} = 0.95 \cdot L_{\text{IR}}^{(k)} + 0.05 \cdot L_{\text{DRAM}}^{(k)} .$$

The same paper also identifies realistic address mapping, a more realistic NoC model, and data prefetchers as additional factors that materially affect end-to-end fidelity (Esmaili-Dokht et al., 18 Apr 2026).

This body of work reframes Ramulator 2 from an isolated DRAM timing engine to one component in a layered performance model. This suggests that validation against real hardware should be performed at more than one abstraction boundary and that internal DRAM timing correctness, while necessary, is not sufficient for trustworthy system-level conclusions.

4. Correct configuration for latency-bandwidth characterization

A detailed re-evaluation of Ramulator 2.0 constructs a controlled setup for the Mess benchmark entirely inside Ramulator 2.0. Instead of using a CPU model, it adds a synthetic “Mess Request Generator” frontend. Random requests emulate pointer-chase-like behavior by issuing a new random read only when the previous one completes, while streaming accesses emulate Stream-like behavior with a configurable mix of reads and writes and configurable NOP insertion to vary memory intensity. This frontend directly drives the memory-controller queues and isolates DRAM and controller effects from CPU pipeline artifacts (Luo et al., 17 Oct 2025).

Component	Configuration	Measurement role
Frontend	Mess Request Generator	Random reads measured; Stream-like reads/writes plus NOP frequency
DRAM	DDR5-4800AN, 16 channels, 1 rank per channel, 8 bank groups, 4 banks per group	Realistic 16-channel DDR5 system
Controller and sweep	FR-FCFS, all-bank refresh, read queue 32, write queue 32, write-to-read forwarding disabled; 20,000 random reads; read ratio 0.5 to 1.0; NOP frequency 1 to 10,000	Latency-bandwidth curve generation

The paper models refresh explicitly. For a 16-channel DDR5-4800 system, the theoretical peak is

$$BW_{\text{theoretical}} = 16 \times 19.2\ \text{GB/s} = 307.2\ \text{GB/s}.$$

With

$$REF_{\text{penalty}} = t_{RTP} + t_{RP} + t_{RFC} + t_{RCD},$$

the achievable bandwidth is modeled as

$$BW_{\text{achievable}} = BW_{\text{theoretical}} \cdot \left(1 - \frac{REF_{\text{penalty}}}{t_{REFI}}\right).$$

Using DDR5-4800AN parameters, the paper reports $BW_{\text{achievable}} \approx 281.2\ \text{GB/s}$, and the measured maximum bandwidth in Ramulator 2.0 is 281.1 GB/s under 100% reads and NOP frequency 1 (Luo et al., 17 Oct 2025).

The resulting latency-bandwidth curves exhibit the expected behavior. Used bandwidth rises as NOP frequency decreases and then saturates near 281.1 GB/s. Random-access latency increases monotonically with used bandwidth because queueing delays grow at the memory controller. As the write fraction increases, bandwidth decreases and latency rises because read-to-write and write-to-read switching introduces bus turn-around delays. The re-evaluation states that these curves are qualitatively and quantitatively similar to the real-system curves reported for correctly configured systems (Luo et al., 17 Oct 2025).

5. The Mess controversy and the correction of negative claims

A major controversy in the Ramulator 2 literature concerns the MICRO 2024 paper “A Mess of Memory System Benchmarking, Simulation and Application Profiling,” which concluded that Ramulator 2.0 “poorly resembles the actual system performance,” reported “unrealistically low” simulated latency, and reported a maximum simulated bandwidth of 126 GB/s versus 292 GB/s on a real ARM-based DDR5 system. “Cleaning up the Mess” and the later extended abstract “Re-Evaluating the Real-System Modeling Accuracy of Ramulator 2.0” argue that these negative conclusions were caused by configuration and usage errors rather than intrinsic deficiencies in Ramulator 2.0 (Luo et al., 17 Oct 2025, Bostanci et al., 12 Jun 2026).

The first reported error is a DDR5 channel-count and bandwidth-extrapolation error. The re-evaluation states that Mess ran Ramulator 2.0 as a single-channel DDR5 system, then extrapolated by multiplying bandwidth by 8 rather than 16. In Ramulator 2.0, a DDR5 channel is modeled as 32 bits wide, not 64 bits. On that basis, the re-evaluation argues that the Mess scripts effectively labeled an 8-channel equivalent configuration as a 16-channel system and then compared it against a real 16-channel DDR5-4800 system. The second reported error is an unrealistic frontend configuration: SimpleO3 with cache latency set to 0 CPU cycles and 1024 MSHRs per core. The papers argue that these choices radically reduce effective round-trip latency and suppress CPU-side blocking, thereby producing the “unrealistically low” latency that Mess attributed to the DRAM simulator (Luo et al., 17 Oct 2025, Bostanci et al., 12 Jun 2026).

The re-evaluation also identifies a methodological inconsistency. According to the analysis, real-system measurements in Mess followed the intended two-workload mix of pointer-chase plus stream and measured pointer-chase latency under interference, whereas simulator runs did not run pointer-chase at all and instead measured the average memory latency of the Stream workload alone. The same paper characterizes that comparison as “apples to oranges.” In its discussion of DAMOV, it further reports that the Mess scripts computed “average memory latency” using zsim L1-D statistics, specifically latGETnl / mGETs, rather than DRAM latency from Ramulator, which explains the reported flat latency of about 25 ns as an artifact of using the wrong statistic (Luo et al., 17 Oct 2025).

The controversy also has a reproducibility dimension. The re-evaluation states that, at publication time, the Mess artifacts did not contain the Ramulator 2.0 source code used by Mess, the Mess benchmark traces used for Ramulator, or some necessary configuration files; that scripts referenced simulator executables and directories that did not exist in the public artifacts; and that the Ramulator 2.0 sources and traces needed for reproduction were added 10 months later. The extended abstract distills four best practices from this episode: grounding configurations in standards and simulator documentation, understanding memory organization and configuration, understanding methodology and statistics, and communicating with simulator developers when unexpected results are observed (Luo et al., 17 Oct 2025, Bostanci et al., 12 Jun 2026).

A common misconception, therefore, is that the Mess paper established a fundamental modeling failure in Ramulator 2.0. The later papers argue instead that the episode primarily demonstrated the sensitivity of memory-system simulation to channel definitions, frontend assumptions, benchmark equivalence, and statistic provenance.

6. Transition to Ramulator 2.1 and continuing significance

Ramulator 2.1 is presented as a major overhaul of Ramulator 2.0 that advances the line in three directions: support for modern and emerging DRAM and memory-controller features, better usability and extensibility, and more comprehensive tests and validation workflows. The standards and features explicitly named include HBM3/4, LPDDR5/6, and GDDR7; separate command/address buses for row and column commands; split activation in LPDDR5/6 with $t_{\text{AAD}}$; high-speed data clocks such as WCK and RCK that can be turned on and off dynamically; and controller-side support for BlockHammer, PRAC, and user-extensible Victim Row Refresh (Luo et al., 11 Jun 2026).

The 2.1 paper also formalizes the composability that Ramulator 2.0 pursued. It describes a common abstract DRAM controller base class, controller variants that inject protocol-specific behavior through filtering predicates in the form of lambdas, declarative timing constraints in Python, and a pytest-based unit-test framework that probes prerequisites, timing correctness, readiness, and row state. At the system level, it includes latency-throughput validation using a traffic-generator frontend and reports that, for all standards modeled in Ramulator 2.1, the simulated memory system can reach theoretical peak throughput and exhibits the expected low-latency region and knee-shaped saturation behavior (Luo et al., 11 Jun 2026).

The line’s significance is therefore twofold. First, Ramulator 2 remains a research instrument for DRAM timing, scheduling, refresh, RowHammer mitigation, and emerging protocol features. Second, the literature around Ramulator 2 has become a case study in simulation methodology itself. The papers from 2025 and 2026 argue that trustworthy use of Ramulator 2 requires not only correct DRAM timing parameters and controller policies but also validated CPU-memory interfacing, realistic address mapping, realistic frontend behavior, and fully reproducible artifacts. The open-source repositories associated with these efforts, including https://github.com/CMU-SAFARI/ramulator2, https://github.com/CMU-SAFARI/ramulator2/tree/mess, and https://github.com/CMU-SAFARI/Cleaning-up-the-Mess, reflect that dual role as both simulator and methodological reference point (Luo et al., 2023, Luo et al., 17 Oct 2025, Luo et al., 11 Jun 2026).