ZSim: High-Performance x86 Simulator

• ZSim is an event-driven, high-performance microarchitectural simulator for x86/x86-64 systems that supports diverse configurations including detailed DRAM interfacing and ISA prototyping.
• It employs a two-phase, windowed simulation model—combining an immediate-response fixed-latency phase with a cycle-accurate DRAM replay phase—to analyze memory behavior.
• ZSim integrates with external DRAM simulators like Ramulator and DRAMsim3 and is validated using a multi-perspective methodology to ensure realistic application-level performance.

ZSim, typically written zSim in the computer-architecture literature, is an event-driven, high-performance microarchitectural simulator for x86 and a fast and scalable simulator designed for x86-64 multicores. In the works considered here, it serves three main functions: a CPU simulator with a Skylake-like core model for coupling to detailed DRAM backends, a host for the bandwidth–latency–curve–driven Mess memory simulator, and a platform for ISA and microarchitectural prototyping such as IntersectX. A distinct and unrelated usage appears in superconducting-circuit research, where $Z_{\mathrm{sim}}(\omega)$ denotes a simulated multiport impedance function rather than a processor simulator (Esmaili-Dokht et al., 2024, Esmaili-Dokht et al., 18 Apr 2026, Rao et al., 2020, Solgun et al., 2015).

1. Execution model and architectural role

In the memory-simulation literature, ZSim is described as event-based and windowed rather than cycle-accurate. In the configuration studied with external DRAM simulators, it simulates execution in windows of 1000 CPU cycles and uses a two-phase scheme. In Phase 1, the Bound phase, execution proceeds with an immediate-response fixed-latency memory model to generate a trace; in the DAMOV template this fixed latency is 1 CPU cycle. Phase 2 then replays the memory operations against a cycle-accurate DRAM simulator and adjusts timings (Esmaili-Dokht et al., 18 Apr 2026).

This execution model is also what makes ZSim suitable as a host for alternative memory backends. The Mess framework uses ZSim as an event-based (not cycle-accurate) microarchitectural simulator, and its memory model is explicitly designed for such simulators. The integration is performed through ZSim’s standard external memory interface, the same general mechanism used for DRAMsim3 and Ramulator, so the memory-timing backend can be replaced without changing the fundamental character of the CPU simulator (Esmaili-Dokht et al., 2024).

2. Reported configurations and modeled systems

Published work uses ZSim in materially different configurations, ranging from server-style memory studies to ISA-extension research. The reported systems illustrate the breadth of the simulator’s use rather than a single canonical hardware template.

Study	ZSim configuration	Research use
(Esmaili-Dokht et al., 18 Apr 2026)	24 cores @ 2.1 GHz; private 32 KB L1-D, 32 KB L1-I, 1 MB L2; shared 33 MB LLC; 6× DDR4-2666 channels	CPU front-end for Ramulator, Ramulator 2, and DRAMsim3
(Esmaili-Dokht et al., 2024)	ZSim configured to model Skylake; additional DDR5 and HBM2 studies via BW–L curves	Host for the Mess simulator
(Rao et al., 2020)	8 cores; ROB 128; loadQueue 32; 64 KB L1D; 2 MB last-level L2; 3 memory controllers; DDR3-1333-CL10	Modeling the IntersectX ISA and architecture

In the DRAM-interface study, the platform is explicitly organized as ZSim core $\rightarrow$ LLC $\rightarrow$ memory controller abstraction in ZSim $\rightarrow$ interface wrapper $\rightarrow$ DRAM simulator command queues, with a Skylake-like core model and a memory system matching 6× DDR4-2666 channels, 1×32 GB DIMM/channel, 2 ranks/DIMM, 8 devices/rank, 16 banks/device. In the IntersectX work, the same simulator family is instead used to model an out-of-order x86-64 core with ROB, load queue, cache hierarchy, and added accelerator structures such as a Stream Cache and Intersection Unit. This suggests that ZSim is used in practice both as a systems-level CPU front-end for memory studies and as a microarchitectural substrate for custom execution mechanisms (Esmaili-Dokht et al., 18 Apr 2026, Rao et al., 2020, Esmaili-Dokht et al., 2024).

3. CPU–memory interface and co-simulation with DRAM backends

A substantial body of recent work on ZSim concerns its coupling to external DRAM simulators. In that setting, ZSim is integrated with Ramulator, Ramulator 2, and DRAMsim3, with the CPU–memory interface responsible for clock coordination, request transmission and response reception, and a simple model of queues/backpressure and translation from ZSim’s per-core view to channel/rank/bank structure. The corrected implementation is released as https://github.com/bsc-mem/ZSim-mem-Interface, with source trees zsim-bsc, ramulator, ramulator2, and dramsim3 (Esmaili-Dokht et al., 18 Apr 2026).

The principal methodological contribution of this line of work is a three-view methodology for memory performance. Perspective ① is the memory simulator view, consisting of DRAM-internal metrics such as average and maximum DRAM access latency, bandwidth utilization, row-buffer hits and misses, bank conflicts, and command scheduling. Perspective ② is the CPU–memory interface view, collected at the ZSim/DRAM boundary and including request arrival and completion timestamps, interface queue occupancies, effective bandwidth seen by the CPU, and latency including interface artifacts but excluding core-pipeline effects. Perspective ③ is the application view, which measures load-to-use latency, IPC, stall cycles, and runtime. The key result is that these three perspectives can diverge severely when the interface is incorrect.

The initial ZSim+Ramulator+DAMOV integration illustrates that divergence numerically. In the DRAM-simulator view, Ramulator reports unloaded latency $\approx 43$ ns, bandwidth saturating at $\sim 100$–$120$ GB/s, and maximum latency 90–195 ns at saturation. At the interface view, latency starts at 27 ns, below the DRAM simulator’s own 43 ns, and simulated bandwidth exceeds the theoretical maximum by $\sim 40\%$. At the application view, load-to-use latency $\approx 24$ ns persists across the realistic bandwidth range, while real Skylake measurements show 89 ns unloaded and 240–390 ns at saturation. The study attributes this primarily to the CPU–memory interface, specifically a disabled clock-scaling block, incorrect integer-ratio clocking via freqRatio = ceil(cpuFreq/memFreq), and the mismatch between ZSim’s 1-cycle immediate-response first phase and the later cycle-accurate replay (Esmaili-Dokht et al., 18 Apr 2026).

The corrected interface replaces integer-ratio clocking with time-based synchronization in picoseconds. Conceptually, it advances CPU time by $\rightarrow$0, advances DRAM time by $\rightarrow$1, and calls the DRAM simulator’s tick() until DRAM time catches up. The same work also introduces a proportional–integral control style adjustment for the first-phase immediate-response latency: $\rightarrow$2 After correcting clock scaling and reducing the phase-1/phase-2 mismatch, application-view bandwidth saturates at the real hardware peak and latency begins to rise with bandwidth rather than remaining nearly flat (Esmaili-Dokht et al., 18 Apr 2026).

4. Mess and bandwidth–latency–curve simulation

Within the Mess framework, ZSim serves as one of the host CPU simulators for a memory model built around families of bandwidth–latency curves. For each read/write ratio $\rightarrow$3, Mess defines a curve

$\rightarrow$4

where $\rightarrow$5 is sustained bandwidth and $\rightarrow$6 is average load-to-use latency. During execution, ZSim runs with a current latency value for a simulation window of about 1000 memory operations; Mess measures the bandwidth actually generated in that window, updates its internal estimate through a proportional controller,

$\rightarrow$7

and then sets the next window’s latency from the corresponding point on the appropriate BW–L curve. In this organization, ZSim still issues memory operations, but Mess replaces the usual timing backend with a feedback-controlled latency model driven by measured or supplied BW–L data (Esmaili-Dokht et al., 2024).

This design is intentionally technology-agnostic. The released ZSim+Mess support covers DDR4, DDR5, Optane, HBM2, HBM2E, and CXL memory expanders, with each technology distinguished by its own BW–L curves rather than by explicit DRAM protocol timing such as $\rightarrow$8 or $\rightarrow$9. The paper demonstrates ZSim+Mess for DDR4-2666 on an Intel Skylake-like 24-core model, DDR5-4800 with a Graviton3-like configuration, HBM2 with an A64FX-like configuration, and CXL using curves derived from Micron’s SystemC model. It also uses ZSim+Mess for a case study that runs 500 billion instructions on the 24-core Skylake model and samples every 20k instructions to compare CXL-attached memory with remote-socket NUMA emulation (Esmaili-Dokht et al., 2024).

The reported accuracy is unusually strong for a non-cycle-accurate memory backend. On Skylake DDR4, ZSim+Mess achieves unloaded latency error < 1%, max latency error $\rightarrow$0, and a 2% difference in saturated bandwidth range relative to real hardware. Across STREAM, LMbench, and Google multichase, the average error is 1.3%. In simulation cost, ZSim+Mess incurs +26% time relative to ZSim’s fixed-latency model, but is 2% faster than ZSim’s M/D/1 model, 15% faster than the internal DDR model, 13× faster than ZSim+Ramulator, and 15× faster than ZSim+DRAMsim3 (Esmaili-Dokht et al., 2024).

5. ISA extension and accelerator prototyping

ZSim is also used as a platform for full ISA and microarchitectural experimentation. The IntersectX work implements a custom stream ISA and associated accelerator structures entirely on zSim, stating that all proposed architectural components, including Stream Cache and Intersection Unit, are integrated into the simulator. The ISA includes S_READ, S_VREAD, S_FREE, S_FETCH, S_SUB, S_SUB.C, S_INTER, S_INTER.C, S_VINTER, S_CSR, and S_NESTINTER (Rao et al., 2020).

The added microarchitecture is substantial. IntersectX introduces a Stream Mapping Table (SMT) that maps stream IDs to internal stream registers, a read-only Stream Cache (S-Cache), explicit stream-dependence tracking via pred0 and pred1, an Intersection Unit (IU), a Stream Value Processing Unit (SVPU), and a nested intersection translator. The baseline configuration on zSim uses 8 cores, ROB size 128, loadQueue size 32, 64 KB L1D, 2 MB L2 as last-level cache, 3 memory controllers, memory controller latency 40 cycles, and DDR3-1333-CL10. The Stream Cache has 1-cycle latency, 16 B/cycle bandwidth, and 256 B slot size; with 16 stream registers, this yields an S-Cache of 4 KB. All stream instructions except S_NESTINTER occupy one ROB entry, while S_NESTINTER is translated into a variable-length sequence of micro-ops with checkpointing to preserve precise exceptions (Rao et al., 2020).

The same study uses ZSim to model not only the added execution structures but also their interaction with the conventional hierarchy. S-Cache is placed on top of L2 together with L1, while values for (key,value) streams still travel through the normal load queue and cache hierarchy. The S-Cache does not participate in the coherence protocol, an approximation justified in the paper by the read-only nature of the graph keys. Sensitivity studies then vary the number of IUs and S-Cache bandwidth inside the simulator. On this basis, IntersectX is reported to outperform the paper’s CPU baseline implementation by 10.7 times on average and up to 83.9 times, and to outperform GRAMER by 40.1 times on average and up to 181.8 times (Rao et al., 2020).

6. Validation practice, scope, and terminology

The most consistent warning across the ZSim literature is methodological rather than purely architectural: internal simulator plausibility is not sufficient validation. The DRAM-interface study shows that ZSim can produce reasonable-looking DRAM statistics while still yielding application-visible memory behavior that is qualitatively wrong. Its recommendation is to validate at all three levels—memory simulator, interface, and application—and to use application-visible metrics such as load-to-use latency, IPC, and runtime, not just DRAM timing or JEDEC compliance. Even after the published interface corrections, realistic address mapping, NoC refinement, and prefetchers, the remaining gap to hardware can still be large; under saturation, simulated latency remains below measured latency by up to 214 ns (Esmaili-Dokht et al., 18 Apr 2026).

The scope of ZSim in these studies is also specific. In the Mess framework, ZSim is the x86-only front-end, whereas ARM, Power, RISC-V, and PTX coverage is supplied by other simulators or by the benchmark itself. Mess-based integration does not expose internal DRAM state such as row-policy or refresh timing in the way that cycle-accurate DRAM engines do; instead, such effects are captured only indirectly through the supplied BW–L curves. This makes ZSim+Mess well suited to studies driven by end-to-end bandwidth–latency behavior, but not to research requiring explicit DRAM microarchitectural state (Esmaili-Dokht et al., 2024).

A final source of confusion is terminological. In superconducting-circuit quantization, $\rightarrow$1 is the simulated multiport impedance function obtained from full-wave EM simulations of the linear, passive part of a device, and the corresponding paper uses this object as the starting point for vector fitting, positive-real synthesis, Hamiltonian construction, and $\rightarrow$2 calculation. That notation is unrelated to the architectural simulator zSim/ZSim discussed above, despite the visual similarity of the names (Solgun et al., 2015).