LP5X-PIM Sim: Cycle-Accurate LPDDR5X PIM Simulator

• LP5X-PIM Sim models commercial LPDDR5X-PIM behavior with cycle-accurate simulation, enforcing JEDEC LPDDR5X timing and proprietary PIM operation schedules.
• The simulator integrates a hardware modeling layer with a PIM Kernel, combining a Data Mapper and PIM Executor to optimize matrix tiling and bank-level parallelism.
• Evaluation on GEMV workloads shows up to 6.2× acceleration, demonstrating effective mapping, dynamic mode switching, and realistic performance validation.

Searching arXiv for LP5X-PIM Sim and closely related LPDDR5X/LPDDR5 PIM simulation work. LP5X-PIM Sim is a cycle-accurate simulator developed by Samsung Electronics to model the precise behavior of Samsung’s commercial LPDDR5X-based Processing-in-Memory technology. It is described as a high-fidelity model of both the hardware data paths and the software control layers of the LPDDR5X-PIM block, 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). The simulator is positioned as an integrated hardware-software environment rather than a DRAM-only timing model: it refines existing simulation frameworks to align with actual hardware implementation, enforces JEDEC-standard DRAM timing together with proprietary PIM operation timelines, and mirrors the software interface and execution ordering of actual LPDDR5X-PIM chips within the bounds of available documentation and specifications (Cha et al., 30 May 2026).

1. Architectural scope and modeled system

LP5X-PIM Sim models two principal hardware entities: the Memory Controller and the internal LP5X-PIM Device. The Memory Controller analyzes host memory requests and schedules them while strictly enforcing LPDDR5X timing. The LP5X-PIM Device augments standard LPDDR5X with internal compute units, mapping each PIM block 1:1 to a DRAM bank, and uses specialized internal data paths via PIM registers to enable direct data movement and computation within DRAM (Cha et al., 30 May 2026).

This bank-aligned organization is central to the simulator’s representation of PIM execution. Because each PIM block is mapped 1:1 to a DRAM bank, resource utilization, bank-level parallelism, and mode transitions become first-order simulation objects rather than secondary annotations. The simulator therefore captures not only DRAM command sequencing but also the internal register-level data movement that mediates PIM execution (Cha et al., 30 May 2026).

The stated aim is fidelity to Samsung’s commercial LPDDR5X-PIM technology rather than an abstract PIM model. In that sense, LP5X-PIM Sim is not a generic accelerator simulator; it is a behaviorally aligned model of a specific LPDDR5X-PIM implementation, including bus/DRAM command ordering, memory-controller scheduling, and internal register file organization (Cha et al., 30 May 2026).

2. Integrated hardware-software execution model

A defining feature of LP5X-PIM Sim is its explicit software modeling layer, termed the PIM Kernel. This layer controls hardware utilization, data layout, and scheduling, and is divided into a Data Mapper and a PIM Executor (Cha et al., 30 May 2026).

Component	Role	Key functions
Hardware Modeling Layer	Models controller and device	Memory scheduling, LPDDR5X timing, internal datapaths
Data Mapper	Offline mapping stage	PIM-aware tiling and placement for DRAM banks
PIM Executor	Runtime orchestration	IRF code generation, HW configuration, mode control, GEMV execution

The Data Mapper operates offline and generates PIM-aware data tiling and placement for DRAM banks based on input matrix or data properties. The PIM Executor orchestrates runtime behavior through Device Code Gen, PIM Control, and the GEMV Kernel. Device Code Gen generates PIM-specific instructions, referred to as IRF code, together with hardware-configuration code adapted to compute, math, and block sizes. PIM Control manages operating modes, specifically Single-Bank for standard DRAM and Multi-Bank for parallel PIM execution, as well as system-wide scheduling. The GEMV Kernel implements General Matrix-Vector multiply on a per-tile basis with pipelining and DRAM read/write synchronization (Cha et al., 30 May 2026).

The integration is bidirectional. The software layer actively maps and reshapes input to maximize PIM hardware parallelism, while every PIM request generated by the kernel is scheduled through the hardware model under real DRAM timing constraints. Inter-layer communication, including switching between SB and MB modes and fence synchronization, is captured cycle-by-cycle (Cha et al., 30 May 2026). This makes the simulator a co-simulation environment in which software policy and hardware timing are inseparable.

3. Mapping, tiling, and cycle-accurate methodology

The simulation flow begins with workload mapping. Application-level matrices are tiled into PIM Tiles while respecting hardware constraints such as PIM register file sizes and bank boundaries (Cha et al., 30 May 2026). For an original $H \times W$ matrix divided into tiles of $T_h \times T_w$, the paper gives the tile count as

$$\text{Number of tiles} = \left\lceil \frac{H}{T_h} \right\rceil \times \left\lceil \frac{W}{T_w} \right\rceil$$

(Cha et al., 30 May 2026)

Address mapping then applies a 2D interleaving policy intended to maximize both bank parallelism and row-buffer hits. Vertical mapping distributes tiles across Channel, Rank, Bank Group, and Bank for parallelism, whereas horizontal mapping places adjacent tiles within the same bank for row locality (Cha et al., 30 May 2026). The paper also states that reshape optimization is applied for smaller matrices to maximize block utilization by distributing data along both the row axis $H$ and the column axis $W$ (Cha et al., 30 May 2026).

Dynamic mode switching is part of the methodology rather than an external control assumption. The kernel triggers hardware transitions between SB and MB modes, invokes PIM instructions, and handles tile-level fence synchronization to ensure correct memory ordering when required. Every DRAM transaction, PIM operation, command, and fence is simulated at cycle granularity while observing true ordering and latency (Cha et al., 30 May 2026).

This methodology places equal emphasis on locality and parallelism. Vertical mapping targets concurrency across banks and channels; horizontal mapping targets row locality; reshape optimization targets hardware occupancy when matrix dimensions would otherwise leave PIM blocks idle. A plausible implication is that LP5X-PIM Sim is designed not merely to count cycles for a fixed mapping, but to expose how mapping policy changes effective utilization under realistic LPDDR5X timing.

4. Fidelity, timing compliance, and relation to other simulators

LP5X-PIM Sim is built on DRAMSim3 and Ramulator, both described as widely used DRAM simulators, but refines them with Samsung’s proprietary PIM hardware specifications so that accuracy extends to all control, data, and timing paths relevant to LPDDR5X-PIM functionality (Cha et al., 30 May 2026). The simulator enforces JEDEC LPDDR5X timing, including examples such as $tRAS$, $tRC$, and $tCCD$, together with proprietary PIM operation timelines at each simulation cycle (Cha et al., 30 May 2026).

The paper further states that behavioral aspects including PIM block utilization, memory-controller scheduling, bus/DRAM command ordering, and register-level data movement are validated against actual hardware configurations and expected performance (Cha et al., 30 May 2026). It also models bus-, controller-, and scheduler-level overheads such as memory fences and mode-transition latency based on empirical measurements from mobile SoCs (Cha et al., 30 May 2026). In this sense, “high fidelity” denotes alignment to actual hardware behavior at both the DRAM protocol layer and the software-visible control layer.

Within the broader PIM-simulation landscape, several adjacent efforts illuminate the distinctiveness of LP5X-PIM Sim. uPIMulator is an open-source, execution-driven performance simulator for UPMEM’s commercial general-purpose PIM system that compiles source codes into machine-level instructions consumed by a cycle-level performance simulator (Hyun et al., 2023). PIM-AI introduced a hardware LLM simulator tailored for PyTorch models and directly modeled LPDDR5/LPDDR5X PIM using a 0.95 pJ/bit energy parameter and platform-level hardware profiles (Ortega et al., 2024). IANUS employed a cycle-accurate, in-house simulator validated to commercial NPU and AiM hardware, but its detailed implementations and experiments centered on GDDR6-based AiM rather than LP5X or LPDDR5X (Seo et al., 2024). Against that background, LP5X-PIM Sim is distinguished by full alignment with proprietary LPDDR5X-PIM hardware specifications and by a PIM-specific software kernel for true HW/SW co-simulation (Cha et al., 30 May 2026).

5. Evaluated workload class and reported results

The reported evaluation focuses on General Matrix-Vector Multiplication, identified as a primary kernel for DNNs, across tile sizes, integer and floating-point datatypes, and various matrix shapes (Cha et al., 30 May 2026). The simulator measures idle PIM blocks, DRAM bank-level parallelism, and the effect of software-level tiling and reshaping. It also includes memory-fence latency, given as 150 ns and described as empirically derived, in order to account for real-world bus/controller reordering effects (Cha et al., 30 May 2026).

For large matrices of size $4096 \times 4096$, the paper reports that PIM delivers up to 6.2$\times$ acceleration over non-PIM, sequential DRAM access, for optimal tiling and hardware utilization, across both integer and floating-point data types. It also reports slightly lower 5.7–5.8$T_h \times T_w$0 speedup for smaller tiles due to increased write-to-register overhead (Cha et al., 30 May 2026).

When a 150 ns memory fence is enforced, robust speedup over 5.0$T_h \times T_w$1 is maintained, but heavily tiled workloads such as W4A16 see a drop to 4.1$T_h \times T_w$2 because fence frequency increases. The paper explicitly notes that large matrices can amortize fence overhead (Cha et al., 30 May 2026). This makes synchronization overhead a measured component of performance, not an omitted system artifact.

For smaller matrices with $T_h \times T_w$3, naive row-based tiling leaves many PIM blocks idle; the paper reports that column-wise reshape enables up to an additional 1.65$T_h \times T_w$4 performance gain (Cha et al., 30 May 2026). Optimized 2D mapping is said to ensure that all banks and PIM blocks are active, thereby maximizing intra-PIM parallelism (Cha et al., 30 May 2026). These results place software-controlled reshape and address mapping alongside hardware timing fidelity as coequal determinants of realized performance.

6. Limitations, deferred disclosures, and research implications

The paper explicitly limits what is disclosed. Precise specifics of the internal LPDDR5X-PIM architecture and circuit-level microarchitecture are not fully disclosed, and further technical details regarding the specific architecture and circuit design are deferred to future publications (Cha et al., 30 May 2026). Similarly, although energy efficiency is named as a target of system evaluation, detailed circuit-level power modeling is not yet incorporated (Cha et al., 30 May 2026).

The workload scope is also narrow in the reported experiments. While the simulator infrastructure is described as supporting broader kernels, the evaluation is limited to GEMV and tiling (Cha et al., 30 May 2026). This restriction is significant because contemporary LPDDR5/LPDDR5X PIM research spans a wider design space. LP-Spec presents a hybrid LPDDR5 performance-enhanced PIM architecture for speculative inference with a near-data memory controller, draft token pruning, and dynamic workload scheduling (He et al., 10 Aug 2025). CD-PIM proposes an LPDDR5-based PIM architecture with a high-bandwidth compute-efficient mode, a low-batch interleaving mode, and a compute-efficient CU for low-batch LLM acceleration on edge devices (Lin et al., 18 Jan 2026). These surrounding works indicate that future simulator extensions may need to cover GEMM-dominated and mixed-workload execution paths in addition to GEMV; this suggests a likely direction rather than a capability already demonstrated by LP5X-PIM Sim.

A common misconception in discussions of simulator fidelity is to equate fidelity with complete architectural disclosure. LP5X-PIM Sim instead demonstrates a more bounded form of fidelity: strict JEDEC LPDDR5X timing compliance, proprietary operation timing, realistic controller and fence behavior, and software-visible control sequencing are modeled in detail, even though detailed architecture and circuit models are reserved for later disclosure (Cha et al., 30 May 2026). For research use, that means the simulator is best understood as a high-fidelity execution and scheduling model of commercial LPDDR5X-PIM behavior, not as a full public microarchitectural specification.