Ramulator: cycle-accurate DRAM simulation for trace, CPU and gem5 modes

The first generation Ramulator that points at its own successor

The repository at CMU-SAFARI/ramulator holds the original release of the simulator introduced by Kim, Yang and Mutlu in the March 2015 issue of IEEE Computer Architecture Letters. The very first thing the README does is point somewhere else: an updated version called Ramulator 2.0 was released in August 2023, and the text says it is easier to use, extend and modify while covering newer standards such as DDR5, LPDDR5, HBM3 and GDDR6, then suggests using that version and welcomes feedback and issue reports.

That makes this checkout a superseded but live branch rather than an abandoned one. The last push was on 2026-07-24, the repository carries a single release, v.0 (MORDOR artifact evaluation v.0), dated the same day, and the repository is not archived. The original supports DDR3, DDR4, LPDDR3, LPDDR4, GDDR5, WIO, WIO2 and HBM, plus academic proposals such as SALP, TL-DRAM, RowClone and DSARP. If you need the newest DRAM standards you have to move to the 2.0 codebase. If you need the exact behaviour behind the published studies, this is where it lives.

One DRAM model fed by three different request sources

Ramulator models the DRAM subsystem only, so it needs something to generate memory requests, and the project offers three ways to supply one. In memory trace driven mode it reads a file where every line is a hexadecimal address followed by R for a read or W for a write:

  - 0x12345680 R
  - 0x4cbd56c0 W

CPU trace driven mode reads instruction traces instead and simulates a simplified model of a core that turns them into DRAM requests. A line with two tokens gives the number of non-memory instructions before the request and the decimal address of a read, while a line with three tokens adds the decimal address of a writeback, meaning the dirty cache line eviction caused by the read that came before it. The third mode runs the simulator inside gem5, which forwards memory requests as it generates them. Keeping the DRAM timing model identical across all three entry points is what makes a trace replay and a gem5 run comparable.

Building the binary and replaying a memory trace

The build needs a C++11 compiler such as clang++ or g++-5, and it is a plain make from the repository root:

        $ cd ramulator
        $ make -j

The Makefile selects clang++ and compiles with -O3 -std=c++11 -g -Wall, producing a single ramulator binary and offering a static libramulator.a target. A first run replays a trace against a shipped configuration and writes its statistics to DDR3.stats:

        $ ./ramulator configs/DDR3-config.cfg --mode=dram dram.trace
        Simulation done. Statistics written to DDR3.stats

The optional --stats flag redirects that output to a name you choose, which is what you want once you are running batches:

        $ ./ramulator configs/DDR3-config.cfg --mode=dram --stats my_output.txt dram.trace
        Simulation done. Statistics written to my_output.txt

Switching to --mode=cpu consumes a CPU trace in the two or three token format instead. The repository ships dram.trace and cpu.trace, and both are described as very short example files, so a first run finishes almost immediately and tells you nothing about realistic behaviour. Configuration lives under configs/, and the top level also carries a mappings/ directory, a plot.py script, a trace_generator/ directory and three Python test files, though the README does not document how those pieces are meant to be driven.

The gem5 integration is pinned to a 2014 stable revision

gem5 support is the part with the sharpest edges. The instructions require SWIG 2.0.12 or newer and gperftools, noted as the libgoogle-perftools-dev package on Ubuntu, then check out a specific old gem5 stable revision and apply the patch stored in the repository:

        $ hg clone http://repo.gem5.org/gem5-stable
        $ cd gem5-stable
        $ hg update -c 10231  # Revert to stable version from 5/31/2014 (10231:0e86fac7254c)
        $ patch -Np1 --ignore-whitespace < /path/to/ramulator/gem5-0e86fac7254c-ramulator.patch
        $ cd ext/ramulator
        $ mkdir Ramulator
        $ cp -r /path/to/ramulator/src Ramulator

The patch file name pins the target revision, and the checkout is a Mercurial clone of a 2014 stable branch. A first gem5 run also does nothing interesting by default, because gem5 uses the atomic CPU and atomic memory accesses, so a detailed memory model like this one is not really used unless a CPU type is given on the command line, for example --cpu-type=timing. The model is then selected with --mem-type=ramulator and --ramulator-config=configs/DDR3-config.cfg. Planning to run current gem5 means redoing this integration by hand, because the documented path ends in a decade-old release.

clang++ by default and an explicit exclusion of g++ 4.x

The build file is opinionated in ways that will hurt people on older toolchains. The compiler variable is set to clang++, with g++-5 left commented out beside it, and a comment states that g++ 5.1+ or clang++ 3.4+ are supported while g++ 4.x will not work because of an internal compiler error when processing lambda functions. The C++11 flag is not optional, and the same line passes optimisation, debug symbols and warnings. On a machine where only an older g++ is on the path, the fix is a toolchain change, not a Makefile tweak, because the offending code path is inside the library rather than the build script.

A checkout can also be exercised without writing traces of your own, since the repository includes test_ddr3.py, test_ramulator.py and test_spec.py. The documentation does not say what those scripts assert, which interpreter they expect or how they are invoked, so treat them as a starting point for your own checks rather than a test suite you can rely on.

Power figures arrive from VAMPIRE or DRAMPower, not from the simulator

Reported power consumption is not computed by Ramulator itself. For some of the DRAM standards the project can report power by relying on either VAMPIRE or DRAMPower as the backend, both cited as external tools. The practical consequence is a two-project dependency: the DRAM timing behaviour comes from Ramulator, while the energy numbers come from a separate model that has to be pointed at the same access stream for the pair to mean anything.

Statistics are the other output worth understanding. The project provides a series of gem5-compatible statistics classes in Statistics.h, and a run in memory trace or CPU trace mode writes its statistics to a file. That compatibility is the reason to prefer the built-in file format over parsing console output, because the same numbers can be fed into an existing gem5 measurement pipeline. The result of a trace run is a statistics file, not a validated prediction about your own DRAM part.

Where this Ramulator is the wrong tool

Several situations make this checkout a poor fit. If you need DDR5, LPDDR5, HBM3 or GDDR6 coverage, the successor described at the top of the README covers those and this repository does not list them among its standards. If you want an energy number without wiring up VAMPIRE or DRAMPower, the simulator will not hand you one. If you are starting a fresh gem5 study, the documented path pulls a 2014 stable revision over Mercurial and applies a patch, which is archaeology rather than setup. If you have no workload trace, the shipped example traces are too short to say anything useful, and the README does not document a workload generation or trace collection pipeline beyond the trace_generator/ directory the repository contains.

The MIT licence removes the usual friction for academic and commercial use, and the cited papers give a traceable account of the model. A simulator that represents a specific set of standards still produces predictions about timing and energy, not measurements of the hardware on your desk, so treat any number it prints as an output of the model until you validate it against real parts.

Editorial conclusion

Use this branch when you need to reproduce or extend the DRAM behaviour behind the 2015 Ramulator paper and the 2019 workload study, and when you already work with the pinned 2014 gem5 revision and the patched src tree. Do not pick it for DDR5, LPDDR5, HBM3 or GDDR6 coverage, for standalone energy figures, or for a fresh gem5 integration, since the project itself recommends Ramulator 2.0 for those cases. Before committing, check three things: that your toolchain satisfies the documented clang++ 3.4+ or g++ 5.1+ requirement, that the trace you plan to replay matches the two or three token formats, and that the statistics file written to DDR3.stats is the output your analysis pipeline expects.

Frequently asked questions

Official sources

1. CMU-SAFARI/ramulator on GitHub
2. Issues
3. License: MIT
4. README
5. Releases