MemorySim: RTL DRAM Simulator

• MemorySim is an RTL-native DRAM simulator integrated into the Chisel ecosystem, offering cycle-accurate modeling of DRAM operations.
• It employs detailed finite state machines to simulate precise DRAM commands, such as ACTIVATE, READ, WRITE, and PRECHARGE for accurate timing.
• The simulator bridges the gap between software-side simulators and hardware-native design flows, targeting memory bottlenecks in AI accelerators.

Searching arXiv for the cited MemorySim paper and closely related memory-simulation work. MemorySim is an RTL-native DRAM memory-system simulator model for the Chisel ecosystem, introduced to let hardware designers study memory bottlenecks in AI accelerators with a model that is both timing-aware and functionally correct at the register-transfer level. It is motivated by the observation that modern AI workloads, especially transformers and LLMs, are often limited by the memory subsystem rather than by compute, and by the practical gap between software-side DRAM simulators and hardware-native Chisel/Chipyard workflows. MemorySim is implemented in Chisel, integrates with Chisel and generated Verilog simulations, and is presented as compatible with Chipyard and downstream evaluation flows such as FireSim (Chaurasia, 18 Aug 2025).

1. Historical setting and problem definition

MemorySim is positioned against a class of established memory simulators used for architectural exploration, including DRAMSim2, DRAMSim3, Ramulator, USIMM, and DRAMSys. In the MemorySim formulation, these tools are useful for timing studies, but become less suitable when a designer requires an RTL-integrated model that participates directly in Chisel or Verilog simulation, preserves cycle-accurate handshakes, and fits naturally into Chipyard and FireSim flows. The paper identifies three concrete shortcomings in this context: timing abstraction that can miss low-level effects under bursty accelerator traffic, lack of RTL-accurate resource modeling for handshake-level backpressure and bit-true correctness corner cases, and loosely coupled power estimation via offline trace-based tools (Chaurasia, 18 Aug 2025).

The resulting problem definition is narrow and specific. MemorySim is not proposed as a universal replacement for software DRAM simulators, nor primarily as a silicon-validated DRAM model. Rather, it addresses an integration boundary: the need for a synthesizable, RTL-level memory simulator that can be embedded in the same hardware-native design and emulation flow as the accelerator under study. This suggests that its main contribution is infrastructural: bringing memory-system timing and protocol behavior into the same simulation domain as Chisel-native accelerator development.

2. Design goals and top-level organization

MemorySim is organized around three explicit goals: RTL-level integration, timing accuracy, and functional correctness. RTL-level integration is achieved by implementing the simulator in Chisel and exposing it through generated RTL to Chisel and Verilog-oriented environments. Timing accuracy is pursued by modeling explicit DRAM command flows—ACTIVATE, READ, WRITE, PRECHARGE, REFRESH, SELF REFRESH, and SELF REFRESH EXIT—through cycle-counted finite-state machines and configurable timing parameters. Functional correctness is pursued through cycle-accurate handshake protocols, request and response queues, bank schedulers, and explicit DRAM timing states (Chaurasia, 18 Aug 2025).

Architecturally, MemorySim has a frontend and a backend. The frontend accepts either memory traces or requests from surrounding RTL. In standalone trace-driven use, each request is represented as

$R = \{\mathbf{addr},\, t\},$

where $t$ is the cycle at which the request is issued. At cycle $t$, the request enters the global reqQueue; if the controller is not back-pressured, it is dispatched in the next cycle. The backend contains a memory controller and a hierarchical physical memory model. The controller decodes the address into rank and bank information, forwards the request to the appropriate bank scheduler, and later collects the resulting completion token in respQueue for return to the frontend (Chaurasia, 18 Aug 2025).

The physical memory hierarchy is organized as channels, ranks, bank groups, and banks. Channels, ranks, and bank groups behave largely as queueing and arbitration layers, while bank-level timing logic resides in the DRAM timing model itself. A plausible implication is that MemorySim treats contention and pipelining as first-class structural phenomena, rather than collapsing the memory system into a single aggregate latency element.

3. Controller, bank schedulers, and address mapping

The bank scheduler is the central control unit for each DRAM bank. Ownership is determined by a fixed address mapping:

$$\mathbf{address} \longleftarrow \{\mathbf{remaining\ bits}, \mathbf{rank\ idx}, \mathbf{bankgroup\ idx}, \mathbf{bank\ idx}\}.$$

Rank, bank-group, and bank-index bits identify the target bank scheduler, and the remaining upper bits form the rest of the address (Chaurasia, 18 Aug 2025).

A consequential design choice is the use of a closed-page policy. Every request incurs an ACTIVATE before data transfer and a PRECHARGE afterward, regardless of potential row reuse. The paper highlights this because it distinguishes MemorySim from the DRAMSim3 baseline used in evaluation; the authors report that DRAMSim3 effectively behaved like an open-page simulator despite attempted closed-page configuration, which contributes to a systematic latency gap.

For reads, the scheduler begins in an IDLE state, checks refresh proximity, issues ACTIVATE, waits for ACTIVATE acknowledgment, issues READ, waits for READ acknowledgment, issues PRECHARGE, waits for PRECHARGE acknowledgment, and returns to IDLE. Writes follow the same structure with WRITE replacing READ. Refresh is handled by issuing REFRESH and waiting for acknowledgment. If a bank remains idle for 1,000 cycles, the design triggers self-refresh; a later incoming request causes exit via SREF EXIT (Chaurasia, 18 Aug 2025).

At the controller level, incoming requests are distributed from the global request queue into per-bank local queues. Intermediate commands emitted by bank schedulers pass through a round-robin arbiter into a memory command queue. Responses from the physical memory channel are broadcast back to all bank schedulers, and the scheduler whose address mapping and request ID match the response accepts it. The paper presents this broadcast-and-filter return path as a hardware-friendly mechanism for preserving correctness without a more complex response-routing network.

4. DRAM timing model and supported workflows

The DRAM timing model mirrors the bank-scheduler FSM rather than making independent high-level scheduling decisions. Given a command and the relevant timing parameter, it enters a state such as READ, WRITE, REFRESH, PRECHARGE, SELF REFRESH, or SELF REFRESH EXIT, waits the prescribed number of cycles, and then emits the corresponding response. The timing model is therefore embodied as FSM state durations rather than as a closed-form analytical latency model (Chaurasia, 18 Aug 2025).

The implemented timing parameters are listed explicitly:

Parameter	Value
$tRP$	14
$tFAW$	30
$tRRDL$	6
$tRCDRD$	14
$tCCDL$	2
$tWTR$	8
$t$0	14
$t$1	260
$t$2	3600

The supported workflows fall into three tiers. First, MemorySim can be used in standalone trace-based simulation, where traces of the form $t$3 are injected to study latency, queueing, and scheduling behavior in isolation. Second, it can be instantiated directly inside larger Chisel repositories and simulated with the same toolchain as surrounding RTL. Third, because it is Chisel/FIRRTL/RTL-native, it is presented as compatible with Chipyard-generated systems and downstream FireSim-style accelerated simulation. The paper emphasizes that this compatibility is a core contribution, but it also states that no concrete FireSim deployment experiment, FPGA resource report, or acceleration number is provided (Chaurasia, 18 Aug 2025).

The same caution applies to power. Although the abstract mentions support for performance and power estimates, the body does not provide an analytical energy model, command-energy formula, or explicit power equation. MemorySim should therefore be understood primarily as a timing and architectural exploration tool with hooks for future power-oriented use, rather than as a validated quantitative power model.

5. Evaluation methodology, results, and validation limits

The evaluation compares MemorySim against DRAMSim3 as an “ideal software simulator” baseline. Traces are generated with Valgrind from four microbenchmarks—conv2d.c, multihead_attention.c, trace_example.c, and vector_similarity.c—chosen to approximate convolutional locality, transformer-like reuse, sequential sanity-check behavior, and irregular similarity-search accesses. All simulations run for 100,000 cycles. The principal metric is the cycle difference

$t$4

For controller queueSize = 128, the reported averages are as follows (Chaurasia, 18 Aug 2025).

Benchmark	Read difference	Write difference
conv2d.c	+102 cycles	+171 cycles
multihead-attention.c	+114 cycles	+110 cycles
trace-example.c	+117 cycles	+111 cycles
exp-vector-similarity.c	+110 cycles	+109 cycles

Averaged across benchmarks, MemorySim incurs about $t$5 extra cycles for reads and $t$6 extra cycles for writes relative to DRAMSim3. The paper attributes this chiefly to policy mismatch—MemorySim’s enforced closed-page policy versus DRAMSim3’s effectively open-page behavior—and to the absence of caching and request reordering in the current design.

The ablation study identifies queueing as the dominant source of overhead. On conv2d, average latency stays near 110 cycles for roughly the first 500 cycles and then rises above 200 cycles as traffic increases. Varying queueSize from 2 to 1024 produces what the authors describe as exponential latency growth: a queue size of 2 yields sub-80-cycle average latency, while a queue size of 1024 produces average latency above 250 cycles. The paper further claims that, as queue size increases, backpressure in the centralized reqQueue accounts for approximately 100% of the added latency. This leads to a throughput-latency tradeoff: smaller queues lower latency but can starve bank schedulers, while deeper queues improve bank utilization at the cost of longer residency and head-of-line blocking (Chaurasia, 18 Aug 2025).

Validation claims remain deliberately moderate. Functional correctness is supported structurally through handshake protocols, explicit queues, per-bank FSMs, and address-matched response acceptance; trace_example.c is used as a basic sequencing and returned-data workload. Timing fidelity is assessed relative to DRAMSim3 under trace-driven simulation. However, the paper explicitly reports no formal verification, no waveform-based proof of protocol equivalence, no JEDEC conformance suite, no real-hardware correlation, and no explicit bit-error or data-integrity report. Correctness is therefore argued from architecture and test traces, not exhaustively demonstrated.

6. Position in the simulator landscape and stated limitations

MemorySim’s distinguishing property is not greater architectural completeness than software simulators, but implementation directly in RTL. In the paper’s comparison, DRAMSim3 remains a cycle-accurate, thermal-capable, object-oriented C++ simulator with support for many DRAM protocols, full-system and trace-driven modes, configurable schedulers, and optional power or thermal modeling; MemorySim instead prioritizes synthesizability, handshake fidelity, and seamless interoperability with FIRRTL-based generation, Chipyard, and FireSim-style flows (Chaurasia, 18 Aug 2025).

This creates a clear tradeoff against other strands of memory-simulation research. A more recent example such as Ramulator 2.1 emphasizes composable cycle-level DRAM modeling, Python-based standard authoring, and extensive testing infrastructure, but remains a software DRAM-system simulator rather than an RTL-native component in a Chisel design flow (Luo et al., 11 Jun 2026). MemorySim occupies the complementary position: less feature-rich as a generic DRAM simulator, but substantially closer to the hardware description environment in which many accelerators are designed.

The paper is explicit about current limitations. MemorySim assumes fixed address mapping into rank, bank group, and bank bits. It enforces a closed-page policy throughout. It does not support row caching or request reordering. The evaluation is described as rough and is benchmarked against an idealized DRAMSim3 setup rather than a hardware memory controller. Queue-depth sensitivity makes reqQueue backpressure a first-order artifact of the current implementation. Self-refresh is modeled only at bank level after 1,000 idle cycles, and rank-level self-refresh optimization is deferred. The strongest forward-looking directions named in the paper are dynamic backpressure control, row caching, request reordering, and improved refresh policies (Chaurasia, 18 Aug 2025).

Taken together, these characteristics define MemorySim as an infrastructure contribution for AI-hardware design in the Chisel ecosystem. Its primary significance lies in demonstrating a viable RTL-level architecture for timing-aware memory simulation that can coexist with accelerator RTL, expose handshake-level backpressure, and participate in Chipyard-style workflows, while also making explicit where such an RTL-native design currently loses performance and where further controller sophistication is required.