A Fast and Extensible DRAM Simulator, with built-in support for modeling many different DRAM technologies including DDRx, LPDDRx, GDDRx, WIOx, HBMx, and various academic proposals. Described in the IEEE CAL 2015 paper by Kim et al. at http://users.ece.cmu.edu/~omutlu/pub/ramulator_dram_simulator-ieee-cal15.pdf
We have released an updated version of Ramulator, called Ramulator 2.0, in August 2023. Ramulator 2.0 is easier to use, extend, and modify. It also has support for the latest DRAM standards at the time (e.g., DDR5, LPDDR5, HBM3 GDDR6). We suggest that you use Ramulator 2.0 and welcome your feedback and bug/issue reports.
Ramulator is a fast and cycle-accurate DRAM simulator [1, 2] that supports a
wide array of commercial, as well as academic, DRAM standards:
The initial release of Ramulator is described in the following paper:
Y. Kim, W. Yang, O. Mutlu.
“Ramulator: A Fast and Extensible DRAM Simulator”.
In IEEE Computer Architecture Letters, March 2015.
For information on new features, along with an extensive memory characterization using Ramulator, please read:
S. Ghose, T. Li, N. Hajinazar, D. Senol Cali, O. Mutlu.
“Demystifying Complex Workload–DRAM Interactions: An Experimental Study”.
In Proceedings of the ACM International Conference on Measurement and Modeling of Computer Systems (SIGMETRICS), June 2019 (slides).
In Proceedings of the ACM on Measurement and Analysis of Computing Systems (POMACS), 2019.
[1] Kim et al. Ramulator: A Fast and Extensible DRAM Simulator. IEEE CAL
2015.
[2] Ghose et al. Demystifying Complex Workload–DRAM Interactions: An Experimental Study. SIGMETRICS 2019.
[3] Kim et al. A Case for Exploiting Subarray-Level Parallelism (SALP) in
DRAM. ISCA 2012.
[4] Lee et al. Tiered-Latency DRAM: A Low Latency and Low Cost DRAM
Architecture. HPCA 2013.
[5] Seshadri et al. RowClone: Fast and Energy-Efficient In-DRAM Bulk Data
Copy and Initialization. MICRO
2013.
[6] Chang et al. Improving DRAM Performance by Parallelizing Refreshes with
Accesses. HPCA 2014.
Ramulator supports three different usage modes.
<num-cpuinst> <addr-read>: For a line with two tokens, the first token
represents the number of CPU (i.e., non-memory) instructions before
the memory request, and the second token is the decimal address of a
read.
<num-cpuinst> <addr-read> <addr-writeback>: For a line with three tokens,
the third token is the decimal address of the writeback request,
which is the dirty cache-line eviction caused by the read request
before it.
For some of the DRAM standards, Ramulator is also capable of reporting
power consumption by relying on either VAMPIRE [8] or DRAMPower [9]
as the backend.
[7] The gem5 Simulator System.
[8] Ghose et al. What Your DRAM Power Models Are Not Telling You:
Lessons from a Detailed Experimental Study. SIGMETRICS 2018.
[9] Chandrasekar et al. DRAMPower: Open-Source DRAM Power & Energy
Estimation Tool. IEEE CAL 2015.
Ramulator requires a C++11 compiler (e.g., clang++, g++-5).
Memory Trace Driven
$ cd ramulator
$ make -j
$ ./ramulator configs/DDR3-config.cfg --mode=dram dram.trace
Simulation done. Statistics written to DDR3.stats
# NOTE: dram.trace is a very short trace file provided only as an example.
$ ./ramulator configs/DDR3-config.cfg --mode=dram --stats my_output.txt dram.trace
Simulation done. Statistics written to my_output.txt
# NOTE: optional --stats flag changes the statistics output filename
CPU Trace Driven
$ cd ramulator
$ make -j
$ ./ramulator configs/DDR3-config.cfg --mode=cpu cpu.trace
Simulation done. Statistics written to DDR3.stats
# NOTE: cpu.trace is a very short trace file provided only as an example.
$ ./ramulator configs/DDR3-config.cfg --mode=cpu --stats my_output.txt cpu.trace
Simulation done. Statistics written to my_output.txt
# NOTE: optional --stats flag changes the statistics output filename
gem5 Driven
Requires SWIG 2.0.12+, gperftools (libgoogle-perftools-dev package on Ubuntu)
$ 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
# Compile gem5
# Run gem5 with `--mem-type=ramulator` and `--ramulator-config=configs/DDR3-config.cfg`
By default, gem5 uses the atomic CPU and uses atomic memory accesses, i.e. a detailed memory model like ramulator is not really used. To actually run gem5 in timing mode, a CPU type need to be specified by command line parameter --cpu-type. e.g. --cpu-type=timing
Ramulator will report a series of statistics for every run, which are written
to a file. We have provided a series of gem5-compatible statistics classes in
Statistics.h.
Memory Trace/CPU Trace Driven: When run in memory trace driven or CPU trace
driven mode, Ramulator will write these statistics to a file. By default, the
filename will be <standard_name>.stats (e.g., DDR3.stats). You can write
the statistics file to a different filename by adding --stats <filename> to
the command line after the --mode switch (see examples above).
gem5 Driven: Ramulator automatically integrates its statistics into gem5.
Ramulator’s statistics are written directly into the gem5 statistic file, with
the prefix ramulator. added to each stat’s name.
NOTE: When creating your own stats objects, don’t place them inside STL
containers that are automatically resized (e.g, vector). Since these
containers copy on resize, you will end up with duplicate statistics printed
in the output file.
For debugging and verification purposes, Ramulator can print the trace of every
DRAM command it issues along with their address and timing information. To do
so, please turn on the print_cmd_trace variable in the configuration file.
For comparing Ramulator against other DRAM simulators, we provide a script that
automates the process: test_ddr3.py. Before you run this script, however, you
must specify the location of their executables and configuration files at
designated lines in the script’s source code:
test_ddr3.py lines 39-40test_ddr3.py lines 54-55test_ddr3.py lines 66-67test_ddr3.py lines 78-79Please refer to their respective websites to download, build, and set-up the
other simulators. The simulators must to be executed in saturation mode (always
filling up the request queues when possible).
All five simulators were configured using the same parameters:
Finally, execute test_ddr3.py <num-requests> to start off the simulation.
Please make sure that there are no other active processes during simulation to
yield accurate measurements of memory usage and CPU time.
Please use the CPU traces (SPEC 2006) provided in the cputraces folder to run
CPU trace driven simulations.
For estimating power consumption, Ramulator can record the trace of every DRAM
command it issues to a file in DRAMPower [8] format. To do so, please turn
on the record_cmd_trace variable in the configuration file. The resulting
DRAM command trace (e.g., cmd-trace-chan-N-rank-M.cmdtrace) should be fed
into a compatible DRAM energy simulator such as
VAMPIRE [8] or
DRAMPower [9] with the correct configuration
(standard/speed/organization) to estimate energy/power usage for a single rank
(a current limitation of both VAMPIRE and DRAMPower).
We thank the SAFARI group members who have contributed to
the initial development of Ramulator, including Kevin Chang, Saugata
Ghose, Donghyuk Lee, Tianshi Li, and Vivek Seshadri. We also
thank the anonymous reviewers for feedback. This work was
supported by NSF, SRC, and gifts from our industrial partners,
including Google, Intel, Microsoft, Nvidia, Samsung, Seagate
and VMware.