LPDDR5X-PIM Simulator Overview

• LPDDR5X-PIM Simulator is a cycle-accurate tool that unifies LPDDR5X protocol timing, hardware datapaths, and software orchestration to model in-DRAM processing.
• It employs a detailed JESD209-5C timing model to execute GEMV kernels, achieving 5×–6× speedup over conventional non-PIM baselines.
• The simulator co-designs hardware scheduling and tile mapping strategies to maximize energy efficiency, resource utilization, and overall system performance.

LPDDR5X-PIM Simulator denotes a class of simulators that model processing-in-memory on LPDDR5X devices, and, in the most specific published form, refers to Samsung Electronics’ “LP5X-PIM Sim,” a cycle-accurate, hardware/software integrated simulator for LPDDR5X-PIM (Cha et al., 30 May 2026). It was introduced to address a gap in public tooling: LPDDR5X-based PIM moves compute into the DRAM device, but there had not been a public, high-fidelity simulator that reflected both Samsung’s LPDDR5X-PIM hardware implementation and the LPDDR5X protocol/timing behavior. The published system therefore unifies hardware datapaths, control logic, and software orchestration in a single co-simulation, with the stated purpose of enabling precise evaluation of system performance and energy efficiency while maximizing PIM resource utilization (Cha et al., 30 May 2026).

1. Motivation and scope

Modern memory-bound workloads are described as being dominated by data movement rather than arithmetic, so energy and latency spent on off-chip transfers become the critical bottleneck (Cha et al., 30 May 2026). Within that framing, LPDDR5X-based PIM is presented as a mechanism for converting off-chip data movement into in-DRAM execution. The simulator’s immediate target is GEMV, characterized as a representative bandwidth-bound kernel, and its reported experiments are conducted under LPDDR5X‑9600 with four channels and strict JESD209‑5C timing (Cha et al., 30 May 2026).

The scope is explicitly broader than a DRAM-only timing model. LP5X-PIM Sim models the hardware datapaths and control of Samsung’s LPDDR5X-PIM together with the software control layer, including the PIM kernel, runtime, and tiling/data placement, in a single, cycle-accurate co-simulation (Cha et al., 30 May 2026). This makes the simulator a HW/SW co-design instrument rather than a narrow command-trace emulator. The significance is that software-driven resource scheduling, including tiling, mode switching, and fences, is treated as materially affecting utilization and end-to-end speedup, so those policies are included inside the simulation boundary rather than left to external scripts (Cha et al., 30 May 2026).

This scope also places LP5X-PIM Sim within a wider simulator lineage. “Ramulator 2.1” provides support for LPDDR5/6, a Python-based modeling and configuration interface, a comprehensive testing and validation infrastructure, and a DRAM command trace visualizer (Luo et al., 11 Jun 2026). That broader infrastructure is relevant because LP5X-PIM Sim is built on DRAMSim3 and Ramulator, but its distinguishing claim is refinement against Samsung’s internal LP5X-PIM specifications and exact preservation of the 1:1 mapping of PIM blocks to banks, the sequencing of SRF loads, MAC accumulation, and register flushes (Cha et al., 30 May 2026).

2. Integrated architecture

LP5X-PIM Sim is organized as two tightly coupled hardware modules plus a software control plane that interact every cycle (Cha et al., 30 May 2026).

Component	Role
Memory Controller	Accepts host or PIM-kernel requests, translates them to LPDDR5X commands, and schedules them under strict timing
LP5X-PIM Device	Conventional LPDDR5X device augmented with PIM blocks, with a 1:1 mapping between DRAM banks and PIM blocks
PIM Kernel	Prepares PIM-aware layout, generates IRF-level device code, orchestrates mode transitions, and synchronizes execution

The Memory Controller is built on DRAMSim3 and Ramulator. It accepts host or PIM-kernel requests, translates them to LPDDR5X commands, schedules ACT, RD/WR, PRE, REF, and related operations under strict timing, issues PIM-mode transitions, and coordinates multi-bank parallel execution when the device is in PIM mode (Cha et al., 30 May 2026). The LP5X-PIM Device is described as a conventional LPDDR5X device augmented with PIM blocks, where each DRAM bank has a dedicated PIM block in a 1:1 mapping. Those PIM blocks integrate internal compute units and specialized PIM registers, including a source register file (SRF) for inputs and accumulation registers for partial sums (Cha et al., 30 May 2026).

The software model is the PIM Kernel. Its two subsystems are the Data Mapper and the PIM Executor. The Data Mapper is offline: it prepares a PIM-aware data layout by partitioning matrices into PIM tiles and placing tiles across channels, bank groups, and banks to maximize bank-level parallelism and row-buffer locality. The PIM Executor is runtime: it generates device code, described as IRF-level PIM instructions and configuration, orchestrates mode transitions between Single-Bank (SB) and Multi-Bank (MB), and runs a GEMV kernel that manages the per-tile pipeline and flush-out steps (Cha et al., 30 May 2026).

Architecturally, this division is significant because it treats placement, command scheduling, and device control as inseparable. A plausible implication is that the simulator is intended less as a generic memory model than as an implementation-faithful model of a specific LPDDR5X-PIM stack, where algorithmic tiling and protocol timing are coupled at cycle granularity.

3. Timing model and protocol fidelity

A defining property of LP5X-PIM Sim is strict adherence to JESD209‑5C timing and command rules (Cha et al., 30 May 2026). In the reported experiments it runs at LPDDR5X‑9600 with four channels, and the model enforces command sequences and constraints for ACT, RD, WR, PRE, REF, bank-group constraints and command spacing, read/write turnarounds, intra-/inter-bank timings, prefetch and burst behavior, and channel/bus contention (Cha et al., 30 May 2026).

The timing model includes representative parameters drawn from an LPDDR5X configuration table: command clock $tCK$, activate-to-read/write $tRCD$, precharge $tRP$, active time $tRAS$, row cycle $tRC$, bank-to-bank ACT spacing $tRRD$, four-ACT window $tFAW$, column-to-column delay $tCCD$, write-to-read turnaround $tWTR$, refresh timing, and bank-group-specific relaxations where applicable (Cha et al., 30 May 2026). Mode management is explicit: SB is used for standard DRAM operations, MB for parallel PIM, and transitions between them are timed operations included in end-to-end latency (Cha et al., 30 May 2026).

The simulator’s modeling style is cycle-accurate. Timing is evaluated at DRAM command granularity with cycle-level enforcement of LPDDR5X constraints, and PIM internal operations are integrated into per-bank state machines and scheduled in lockstep with command issuance (Cha et al., 30 May 2026). Contention modeling covers bank conflicts, bus contention, read/write turnaround, and inter-bank spacing under bank-group rules; PIM compute in one bank can overlap with standard DRAM commands to other banks subject to timing constraints (Cha et al., 30 May 2026).

Within the broader memory-simulator literature, this emphasis on generated state machines and protocol-faithful scheduling is consonant with Ramulator 2.1’s device models, which are constructed as hierarchical per-rank, per-bank, and per-bankgroup state machines with timing arcs, and whose controller variants inject protocol-specific constraints through composable filtering predicates (Luo et al., 11 Jun 2026). The distinction is that LP5X-PIM Sim adds PIM-specific datapath behavior and software-visible control semantics while preserving Samsung’s intended hardware sequencing (Cha et al., 30 May 2026).

4. Execution pipeline, operation set, and data mapping

The simulator models the operation set required to execute GEMV tiles inside DRAM. Its in-memory compute primitive is MAC on data resident in bank-local arrays using data fetched into the SRF and accumulated into bank-local registers. Supported data formats include integer W8A8, W4A4, W8A16, W4A8, W4A16 and floating-point W8A8 and W8A16 (Cha et al., 30 May 2026). It also models register operations, including moves and loads from DRAM to SRF, accumulation-register management, and flush to DRAM, as well as kernel sequencing and synchronization through IRF-level device code and explicit memory fences (Cha et al., 30 May 2026).

The execution pipeline is divided into offline tile layout, runtime setup, tile execution, synchronization, and iteration. Offline, given an $H \times W$ matrix and a data type, the Data Mapper chooses tile shape $tRCD$0 subject to SRF and accumulator capacities, then maps tiles to channel, rank, bank group, and bank (Cha et al., 30 May 2026). Runtime setup emits PIM device code and configuration, switches the device to MB mode for parallel PIM execution or SB when needed, and injects requests into the memory controller. During tile execution, inputs are written into SRF, the PIM MAC datapath runs across selected banks in parallel, partial sums accumulate in on-bank registers, and the kernel flushes accumulation registers back to DRAM (Cha et al., 30 May 2026). When strict ordering is required, a memory fence enforces order at the cost of added latency; the experiments use a representative 150 ns fence latency measured on high-performance mobile APs (Cha et al., 30 May 2026).

Dataflow is governed by three mapping strategies. Vertical interleaving distributes tile rows across channel, rank, bank group, and bank to exploit bank-level parallelism and channel bandwidth. Horizontal grouping places adjacent sub-tiles in the same bank to increase row-buffer hits during sequential access inside a tile. Column-based reshape partitioning extends row-only tiling by splitting both $tRCD$1 and $tRCD$2 to keep more PIM blocks busy for small matrices (Cha et al., 30 May 2026). The simulator measures the effects of these choices through PIM block occupancy, bank-level concurrency, command issue rate, and tile pipeline efficiency (Cha et al., 30 May 2026).

These concerns recur in adjacent PIM simulators aimed at LLM inference. PIM-AI models a logic-die architecture with a control interface, descriptor-driven PIM operations, and internal DRAM–logic links of up to 102.4 GB/s per chip (Ortega et al., 2024). LoL-PIM models token-parallel partitioning, DPA-based dynamic memory management, and ping-pong buffering to overlap I/O and compute (Kwon et al., 2024). LP5X-PIM Sim differs in workload focus and disclosure level, but the common theme is that simulator fidelity depends on making placement, synchronization, and internal movement first-class timing events rather than post hoc annotations.

5. Evaluation methodology and reported results

The published evaluation uses GEMV across a range of shapes and data types, with a non-PIM, sequential read system with four LPDDR5X channels as the baseline (Cha et al., 30 May 2026). The simulator collects throughput and speedup over baseline, latency per tile and total latency decomposed into control, queuing, memory, and compute components, bandwidth utilization and command issue rate, and PIM block occupancy and bank-level concurrency (Cha et al., 30 May 2026). The methodology also introduces a roofline-style bound and a parameterized energy model that separates standard DRAM command energy, in-DRAM PIM compute, and static power (Cha et al., 30 May 2026).

The reported results are centered on LPDDR5X‑9600 with four channels. For 4096-dimension baselines, large tile shapes—W8A8, W4A4, and W8A8 FP—achieve 6.0×–6.2× speedup without fences relative to the non-PIM sequential read baseline. Smaller tile shapes—W8A16, W4A16, and W8A16 FP—reach 5.7×–5.8×, with the stated limitation being more frequent SRF input writes per tile (Cha et al., 30 May 2026). With a 150 ns memory fence, most configurations at dimension 4096 retain $tRCD$3 speedup, while W4A16 drops to 4.1× because smaller tiles incur more frequent fences (Cha et al., 30 May 2026). For small matrices, such as $tRCD$4, column-based reshape improves performance by up to 1.65× over row-only partitioning by increasing active PIM blocks and register utilization (Cha et al., 30 May 2026).

The paper’s interpretation of those results is explicit. Larger dimensions amortize fixed overheads such as mode transitions, pipeline flushes, and register-to-DRAM writes. Fence overhead is a fixed cost per tile boundary, so larger tiles or coarser synchronization reduce the penalty. Mapping that maximizes bank-level parallelism and row-buffer locality directly correlates with occupancy and throughput (Cha et al., 30 May 2026). The practical usage guidelines follow from the same measurements: choose tile sizes that fit SRF and accumulator capacities while maximizing $tRCD$5, enable reshape for small matrices, exploit vertical interleaving and horizontal grouping, minimize fences, and interpret metrics holistically by preferring high PIM occupancy, high bus efficiency $tRCD$6, and a latency profile dominated by compute rather than control or memory (Cha et al., 30 May 2026).

Within the broader LPDDR-PIM literature, similar simulator-driven performance arguments appear in architecture-specific studies, but on different workloads and hardware. CD-PIM reports average speedups of 11.42× and 4.25× against a GPU-only baseline and state-of-the-art PIM designs in HBCEM mode, and 1.12× for LBIM relative to HBCEM at low batch sizes, but those results are tied to pseudo-bank segmentation and low-batch LLM acceleration on edge devices (Lin et al., 18 Jan 2026). LP5X-PIM Sim’s published contribution is narrower and more protocol-specific: it is a faithful LPDDR5X-PIM performance model centered on GEMV, timing compliance, and HW/SW co-optimization (Cha et al., 30 May 2026).

6. Configuration, interfaces, limitations, and related simulator landscape

LP5X-PIM Sim exposes three classes of input parameters: LPDDR5X device configuration, PIM device configuration, and kernel configuration (Cha et al., 30 May 2026). The memory configuration includes the timing table, burst and prefetch settings, bank groups, rank, channel count, bus width, and data rate. The PIM configuration includes per-op compute latencies, SRF and accumulator capacities, mode-switch latencies, and IRF instruction timing. The kernel configuration includes tile shape, data type and precision, reshape enable or disable, fence policy, and fence latency (Cha et al., 30 May 2026). The runtime API concepts in the tech note are given as allocate_pim_tensor, configure_pim, launch_gemv, and wait, with a minimal pseudo-code example showing offline mapping, device-code generation, MB-mode configuration, batched tile launches, and an optional 150 ns fence (Cha et al., 30 May 2026).

The simulator’s fidelity claims are bounded by explicit assumptions. Circuit-level micro-architectural details such as gate-level power and analog design are abstracted; detailed PIM ISA opcodes are represented as device-level IRF code with timing consistent with internal specs; and energy values are parameterized rather than derived from circuit simulation (Cha et al., 30 May 2026). The paper states that detailed error margins versus silicon are not disclosed. It also limits its evaluation to GEMV, reserving broader kernel support, detailed ISA disclosure, and silicon-correlated energy numbers for future work (Cha et al., 30 May 2026). These constraints are important because they clarify that the simulator is behaviorally and temporally faithful, but not a circuit simulator.

The topic sits inside a larger ecosystem of PIM-capable simulation frameworks and workload-specific models. Ramulator 2.1 is an open-source, composable memory-system simulator that adds support for LPDDR5/6, a two-way Python/C++ code-generation framework, pytest-based validation at command granularity and system level, and a DRAM command trace visualizer (Luo et al., 11 Jun 2026). PIM-AI develops a simulator for DDR5/LPDDR5 PIM aimed at LLM inference without modifying the memory controller or DDR/LPDDR memory PHY (Ortega et al., 2024). LoL-PIM models a multi-node DRAM-PIM system with an MLIR-based compiler, a DPA controller, and Ramulator-based cycle-level timing validated against AiM-SDK (Kwon et al., 2024). LP-Spec presents an LPDDR5 hybrid PIM simulator with a near-data memory controller, a 4 KB PIM global buffer, hardware-aware draft token pruning, and dynamic workload scheduling for speculative inference (He et al., 10 Aug 2025). PIM-GPT uses an event-driven clock-cycle accurate simulator for a GDDR6-based PIM accelerator with ASIC support for non-linear functions (Wu et al., 2023). Taken together, these systems indicate that “LPDDR5X-PIM simulator” is no longer a single design point but a research category spanning JEDEC-timed memory models, bank-local or logic-die compute models, compiler/runtime co-design, and workload-specialized execution policies.

A plausible implication is that LP5X-PIM Sim occupies the most implementation-aligned point in that space for Samsung’s LPDDR5X-PIM block. Its distinguishing feature is not merely that it simulates PIM, but that it unifies JEDEC-accurate LPDDR5X timing, a bank-mapped PIM datapath, and a resource-aware software kernel—tiling, mode control, instruction synthesis, and fencing—inside a single cycle-accurate execution model (Cha et al., 30 May 2026).