PaperlayerView exact revision on arXiv

Source-linked AI summary

A gem5-based Simulation Framework for Computing-in-DRAM

Alexander Kusnezoff, João Paulo C. de Lima, Jeronimo Castrillon, Asif Ali Khan

arXiv:2610.08186v1cs.ARcs.ET

TL;DR

Memory-bound CIMD needs operand placement and full-application simulation, but existing options are costly or trace-based, and the available full-application simulator uses outdated gem5. gem5-CIMD extends current gem5 with broader CIM instructions, memory management, and refresh modeling; it matches an analytical timing model within 0.2–12%, while MIMDRAM’s cycle estimates diverge in the reported comparisons.

  • Problem

    CIMD evaluation lacks an accessible full-application simulator on current gem5: FPGA testbeds are costly and labor-intensive, trace-based simulators cannot run applications, and MIMDRAM uses outdated gem5 and toolchains.

    Source: §I · p. 1

  • Method

    gem5-CIMD extends gem5 with sixteen CIM instructions, subarray-aware allocation and mapping, explicit refresh scheduling, and a C/C++ standard library intended as a compiler target.

    Source: §I · p. 2, §V · p. 7

  • Results

    gem5-CIMD matches the analytical model within 0.2–12%; MIMDRAM reports up to 33% fewer cycles for short microprograms and 23% more for the 16K-command 32-bit multiplication.

    Source: 1) Comparison with MIMDRAM and an… · p. 6

  • Takeaways & Limitations

    The framework provides a full-application CIMD platform that represents subarray placement and mandatory refresh operations in simulation.

    Source: §I · p. 2, §V · p. 7

    The implementation currently uses gem5 SE mode, and all reported simulated results are for a single bank.

    Source: §V · p. 7

Abstract

from arXiv · show

Computing-in-Memory using DRAM (CIMD) has demonstrated substantial energy and throughput gains for memory-bound workloads consisting of bulk-bitwise operations, by performing computation directly within DRAM subarrays. Realizing CIMD, however, requires a redesign of the memory controller and careful mapping of operands onto the memory arrays. Presently, accurate FPGA-based testbeds exist, but they are costly and labor-intensive, while open-source simulators are largely trace-based and cannot execute full application runs. The only full-application CIMD simulator available, included with MIMDRAM, is built on an outdated version of gem5 and its toolchains. We present gem5-CIMD, a full-application CIMD simulation framework built on the latest version of gem5. We extend the simulated instruction set from four bitwise operations to sixteen CIM instructions spanning arithmetic, relational, conditional, and utility operations across a range of data types and bitwidths (4 to 64 bits). A complete memory-management stack comprising multi-level huge-page support, a CIM-aware allocator, and a subarray-aware address-mapping scheme ensures that CIM operands are co-located in the same DRAM subarray. In addition, gem5-CIMD is aware of the DRAM refresh interval and faithfully models and schedules the mandatory refresh operations when needed. We provide a CIM standard library intended as a compiler target and evaluate gem5-CIMD on multiple case studies including an end-to-end KNN workload. The simulator sources, including the evaluated workloads, are publicly available.

I. INTRODUCTION

Data movement dominates memory-bound workloads, motivating computation within or near memory, but existing CIMD validation options are limited. gem5-CIMD addresses the simulator gap with a full-application framework that extends the instruction set and adds memory-management and refresh support.

I. INTRODUCTION

  • Over 62% of total system energy consumption is attributed to moving operands between memory and the processor across machine-learning, database, and graph-processing applications.PIM performs computation within or close to memory to reduce or eliminate those transfers.Source: §I · p. 1
  • FPGA testbeds are accurate but costly and labor-intensive, while available trace-driven simulators cannot execute full application runs.The MIMDRAM full-application simulator is built on outdated gem5 and toolchains and lacks memory-management support for guaranteeing subarray co-location.Source: §I · pp. 1–2
  • gem5-CIMD extends the instruction set from four bitwise operations to sixteen arithmetic, relational, conditional, and utility instructions across 4- to 64-bit widths.Each instruction is backed by a precomputed Ambit microprogram per supported bitwidth and executed with cycle-accurate DRAM timing.Source: §I · p. 2
  • A huge-page stack, CIM-aware allocator, and subarray-aware mapping place operands for a computation in the same subarray, while the simulator models intermediate refreshes.The framework also exposes its instruction set through a C/C++ standard library intended as a compiler target.Source: §I · p. 2

II. BACKGROUND AND RELATED WORK

DRAM operations follow a hierarchy of commands and timing constraints, while CIMD uses in-place command sequences to compute on stored data. Operand placement and refresh timing are important because computation requires suitable row locations and long microprograms can span refresh intervals.

A. CIM using DRAM

  • DRAM cells sit in subarrays arranged within banks, ranks, and channels; ACT, RD/WR, PRE, and periodic REF commands govern access and data retention.Commands are subject to timing constraints including t_RAS, t_RCD, and t_RC.Source: A. CIM using DRAM · p. 2
  • Ambit computes a three-input majority by activating three rows simultaneously and precharging; fixing an input to 0 or 1 yields AND or OR, while a dual-contact cell provides NOT.Participating rows must be in the same subarray, and operands are typically copied into reserved compute rows before destructive operations.Source: A. CIM using DRAM · p. 2, Figure 1
  • A 64-bit addition expands to 597 AP/AAP commands, so long microprograms can exceed the refresh interval and require interleaved REF commands for faithful timing.Higher-level operations are sequences of AP and AAP primitives; the figure shows Ambit microprograms for AND and NOT.Source: A. CIM using DRAM · pp. 2–3

B. The gem5 Simulator

gem5 is a modular, cycle-accurate simulator that executes unmodified binaries and reports detailed component statistics. Its memory hierarchy provides the extension points used by gem5-CIMD to introduce CIM commands and microprogram execution.

B. The gem5 Simulator

  • gem5 executes unmodified binaries and reports detailed per-component statistics, including per-rank DRAM energy across ACT, PRE, read, and write commands.Target systems are configured with Python scripts exposing CPU, cache, and memory parameters.Source: B. The gem5 Simulator · p. 3
  • Full-System mode boots a complete OS image, while Syscall-Emulation mode uses lightweight stubs and an EmulationPageTable to simplify setup and reduce runtime.Source: B. The gem5 Simulator · p. 3
  • The memory hierarchy runs from AbstractMemory through MemInterface and DRAMInterface to MemCtrl, where gem5-CIMD adds CIM command primitives and microprogram execution.DRAMInterface provides DRAM timing parameters and helpers that issue ACT/PRE commands; MemCtrl schedules requests onto the interface.Source: B. The gem5 Simulator · p. 3

C. Related Work

Existing trace-based simulators cannot execute full applications, while MIMDRAM can but lacks newer infrastructure and exposes only four bitwise primitives. gem5-CIMD ports and extends MIMDRAM with a full-application execution path, memory management, and a library interface for CIM operations.

C. Related Work

  • MIMDRAM is the only cited simulator that runs complete binaries, but its 2015 gem5 base and missing modern CIM features limit its usefulness for validating real workloads.Other cited simulators model memory-command traces and omit non-memory instructions, so they cannot run full applications.Source: C. Related Work · p. 3

III. THE GEM5-CIMD FRAMEWORK

  • gem5-CIMD ports and extends MIMDRAM with an extended 16-instruction ISA, subarray-level operand placement, memory management, and refresh interleaving.The port also required substantial API changes for current gem5.Source: §III · p. 3
  • Input code invokes the standard library, which emits custom x86 opcodes that pass through the cache hierarchy to the memory controller for AP/AAP execution.The memory-management stack allocates operands so those participating in an operation share a DRAM subarray.Source: §III · p. 3

A. CIM Standard Library

  • The standard library provides allocation and computation layers, while MIMDRAM requires programmers to spell out carry logic even when macros loop over bit positions.A 32-bit multiplication can still expand to over 16K AP/AAP commands in MIMDRAM, whereas gem5-CIMD expresses it as one library call.Source: A. CIM Standard Library · pp. 3–4

B. ISA Extension

gem5-CIMD adds a broad CIM instruction set and routes operations through the memory controller to DRAM microprograms. The controller also checks operand placement and schedules refreshes during long operations, while leaving microprogram optimization outside its scope.

B. ISA Extension

  • Sixteen custom instructions cover bitwise, arithmetic, relational, conditional, and utility operations at 4-, 8-, 16-, 32-, and 64-bit widths.The implementation provides 80 precomputed Ambit microprograms, one per instruction and supported bitwidth.Source: B. ISA Extension · p. 4

C. Memory Controller and Refresh Handling

  • The controller decodes ROWOP requests, verifies operands share a rank, bank, and subarray, and prioritizes pending CIM operations over regular memory accesses.Statistics track TRA commands and RowClone operations.Source: C. Memory Controller and Refresh… · p. 4
  • For each CIM instruction, the controller executes the corresponding precomputed AP/AAP microprogram, with files replaceable or addable at runtime.The DRAM interface implements AP as a TRA operation and AAP as a RowClone operation.Source: C. Memory Controller and Refresh… · p. 4
  • gem5-CIMD does not optimize microprogram generation; it is designed to faithfully simulate the microprograms it is given.The design is intended to remain orthogonal to logic synthesis.Source: C. Memory Controller and Refresh… · p. 5
  • A 64-bit addition requires 597 AP/AAP steps, so gem5-CIMD inserts synchronous refreshes after the DRAM refresh interval; omitting them gives optimistic long-operation latency estimates.Each refresh follows an all-bank precharge and blocks the rank for tRFC.Source: C. Memory Controller and Refresh… · p. 5

D. Memory Management Stack

gem5-CIMD coordinates address mapping and allocation so CIM operands can reside in the same DRAM subarray, a requirement of CIM operations.

  • CIM operations require all operands to share a DRAM subarray, but standard malloc offers no such guarantee and bank-interleaving can scatter consecutive elements across banks.The framework addresses this constraint through three coordinated mechanisms.Source: D. Memory Management Stack · p. 5
  • RaBaSuRoCh mapping decomposes physical addresses so consecutive bytes in a row share a subarray, co-locating properly aligned CIM arrays.The mapping is applied uniformly to CIM and non-CIM traffic to avoid conflicts.Source: 1) Address Mapping · p. 5

2) Huge-page Pool:

The huge-page pool provides contiguous physical memory and subarray-sized allocation regions for CIM operands. Its allocator groups requests by label to construct co-location and tracks free row ranges.

2) Huge-page Pool:

  • A reserved pool of 2 MiB huge pages is allocated eagerly from contiguous physical memory, avoiding demand-paging non-determinism.A multi-level page table supports variable page sizes, with 2 MiB pages ending translation at the PMD level.Source: 2) Huge-page Pool · p. 5
  • cim_malloc() binds each subarray label to one allocation region, so identically labeled operands are co-located by construction and checked again by the memory controller.Each 2 MiB page contains 256 rows of 8 KiB in one subarray; metadata tracks free row ranges and coalesces freed blocks.Source: 3) CIM-aware Allocator · p. 5

IV. EVALUATION

  • The evaluation compares gem5-CIMD timing with an analytical command model and MIMDRAM, and demonstrates end-to-end simulation with a KNN classifier.The passage identifies the evaluation scope but does not report outcomes.Source: §IV · p. 5

A. Experimental Setup

The evaluation uses a configured gem5-CIMD system and workloads spanning the instruction set. gem5-CIMD’s cycle counts track an analytical AP/AAP model, while MIMDRAM’s estimates differ depending on operation length and instruction overhead.

A. Experimental Setup

  • The simulated system uses an out-of-order X86O3CPU at 4 GHz with private L1 instruction and data caches, an L2 cache, and single-channel, single-rank DDR4_2400_8x8.CIM operands use a reserved huge-page pool mapped via RaBaSuRoCh for same-subarray placement.Source: A. Experimental Setup · pp. 5–6, Table III · p. 6
  • The workload set covers four bitwise, four arithmetic, five relational, one conditional, and two utility operations, with 8-, 16-, and 32-bit integer arrays of 8K, 40K, and 500K elements.KNN is included as an end-to-end application case study.Source: A. Experimental Setup · p. 6

B. Validation

  • Validation covers microprogram execution time against an analytical model and MIMDRAM, misaligned-operand detection, and refresh modeling.The analytical model sequences AP/AAP commands using their DRAM timings and includes refresh overhead when the refresh interval elapses.Source: B. Validation · p. 6, 1) Comparison with MIMDRAM and an… · p. 6

1) Comparison with MIMDRAM and an Analytical Model:

  • gem5-CIMD matches the analytical model within 0.2–12%; MIMDRAM reports up to 33% fewer cycles for short programs but 23% more for a 32-bit multiplication.The multiplication comprises 16K commands, where per-command instruction overhead dominates.Source: 1) Comparison with MIMDRAM and an… · p. 6, Table IV · p. 6

2) Misalignment Detection:

gem5-CIMD detects operands that do not share a DRAM subarray and models refreshes during long operations. The case studies span multiple workloads and include an end-to-end KNN implementation with parallel distance computation in CIM.

2) Misalignment Detection:

  • A misaligned 32K-element INT32 allocation silently produces bit-corrupted output in MIMDRAM, while gem5-CIMD asserts when operands fail its bank, rank, and subarray checks.The assertion is triggered at write-queue insertion time.Source: 2) Misalignment Detection · p. 6

3) Refresh Handling Fidelity:

  • A 64-bit addition takes about 29.5 μs and triggers three synchronous REF commands, adding about 1.1 μs per operation.Its 597 AP/AAP steps span about 3.8 refresh intervals; MIMDRAM does not refresh within a multi-command row operation issued as one request.Source: 3) Refresh Handling Fidelity · p. 6

C. Case Studies

  • Figure 4 reports throughput for 11 microworkloads across 8K, 40K, and 500K operand sizes and 8-, 16-, and 32-bit widths.The evaluation focuses on validating simulation results and handling diverse workloads, rather than comparing against CPU or GPU systems.Source: C. Case Studies · p. 6, Figure 4 · p. 7
  • The KNN implementation stores each feature column in a CIM-allocated array and computes squared Euclidean distances across training samples in parallel within one DRAM subarray.The host CPU performs top-K selection and majority voting.Source: C. Case Studies · p. 7

V. CONCLUSION AND FUTURE WORK

gem5-CIMD extends current gem5 with a broader CIM instruction set, subarray-aware memory management, refresh modeling, and a C/C++ library, with validation against an analytical model and an end-to-end KNN run. The reported results are limited to syscall-emulation mode and a single bank; the authors identify broader system and DRAM modeling as future work.

V. CONCLUSION AND FUTURE WORK

  • gem5-CIMD supports 16 CIM instructions, a memory-management stack that co-locates operands in one subarray, mandatory refresh modeling, and a C/C++ compiler-target library.Its cycle counts match an analytical AP/AAP model within 0.2–12%, and an end-to-end KNN workload runs in syscall-emulation mode.Source: §V · p. 7
  • All reported results use a single bank and syscall-emulation mode; full-system and multi-process support, cross-bank CIM and data movement, and other ISAs and CIMD designs remain future work.The authors also plan to make data layouts explicit and configurable.Source: §V · p. 7
Loading 2610.08186v1…