⚡ electrical engineering

A Native RTL Quantum Statevector Simulator in FP64 on an HBM-Equipped FPGA

This paper presents a native Verilog RTL implementation of a high-performance FP64 quantum statevector simulator on an HBM-equipped FPGA that achieves perfect fidelity for up to 15 qubits by translating a validated HLS kernel into hand-written logic with specialized gate engines and an optimized HBM memory architecture, while also documenting a specific verification failure for 16 or more qubits.

Original authors: Nasir Ali Nasir Ali

Published 2026-07-02✓ Author reviewed ⓘ

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Nasir Ali Nasir Ali

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to simulate a magical, parallel universe where a single coin can be both heads and tails at the same time. In the world of quantum computing, this "coin" is a qubit. To simulate a system with many of these coins on a regular computer, you need to keep track of every possible combination of heads and tails simultaneously.

This paper describes a custom-built machine designed to do exactly that, but with a twist: instead of using a standard computer chip, the author built a specialized "brain" on a FPGA (a chip you can reprogram like a digital Lego set) that is packed with a super-fast, high-capacity memory system called HBM.

Here is a breakdown of the paper's story, using simple analogies:

1. The Problem: The "Library" Bottleneck

Simulating quantum computers is like trying to read every book in a library that doubles in size every time you add one new shelf.

The Math: If you have 29 qubits, you need to store 536 million complex numbers. That's a lot of data.
The Bottleneck: Most computers are fast at math but slow at fetching data from memory. It's like having a genius chef (the processor) who can cook a meal in a second, but the pantry (memory) is so far away that they spend 99% of their time walking back and forth to get ingredients.
The Limit: Because of this, most simulators hit a wall at around 29 qubits. They simply run out of space or time.

2. The Solution: A Custom "Super-Librarian"

The author, Nasir Ali, built a custom engine called qsim on a Xilinx Alveo U55C chip. This chip is special because it has HBM2 (High-Bandwidth Memory).

The Analogy: Imagine a library where the books aren't on shelves in a basement, but are arranged in 8 different rooms right next to the chef. The chef has 8 assistants (data paths) who can grab books from all 8 rooms at the exact same time.
The Speed: This setup allows the machine to move data at roughly 460 GB/s. That's like downloading the entire internet in a few seconds, just to feed the processor.

3. How It Works: The Three Specialized Workers

The machine doesn't try to do everything with one giant brain. Instead, it uses three specialized workers (engines) that handle different types of quantum "moves" (gates):

The Math Worker (Single-Qubit Engine): When a move requires complex math (like spinning a coin), this worker uses a highly tuned calculator that takes 7 steps to finish a calculation. It's fast and precise.
The Swap Worker (CNOT Engine): Some moves just require swapping two coins. This worker doesn't do any math; it just physically swaps the data packets. It's like a librarian swapping two books on a shelf without reading them.
The Flip Worker (CZ Engine): Some moves just flip the "sign" of a number (turning a positive into a negative). This worker just flips a single switch on the data. It's the fastest worker of all.

4. The "Nine-Door" Rule (A Critical Discovery)

One of the most interesting parts of the paper is a lesson learned the hard way.

The Mistake: The author first tried to design the system with 16 doors (memory ports) to the library, thinking more doors would mean faster access.
The Crash: The chip's internal wiring couldn't handle 16 doors opening at once. It was like trying to fit 16 delivery trucks into a parking lot designed for 8; they crashed into each other, and the design failed.
The Fix: The author reduced the design to 9 doors (8 for data, 1 for instructions). This fit perfectly. The paper emphasizes that this isn't just a "tweak"; it's a hard rule. If you try to add more doors, the physical chip simply cannot route the wires correctly.

5. The Results: Success and a Glitch

The author tested this machine by simulating a "GHZ state" (a specific quantum pattern) with increasing numbers of qubits.

The Success: For systems with 1 to 15 qubits, the machine worked perfectly. It produced the correct results with 100% accuracy. The time it took to run the simulation grew predictably (about 2.16 times slower for every extra qubit added), which matches the math.
The Glitch: When the author tried to simulate 16 or more qubits, the machine started giving wrong answers.
- The Cause: It turned out that when the system got too big, two "Swap Workers" tried to write to the same memory room at the exact same time. They got in each other's way, and one of the writes was lost.
- The Fix: The author found the exact line of code causing the traffic jam and added a simple "wait" instruction to make them take turns. This fix is documented, but the paper notes that the final hardware test hasn't been run yet to confirm the fix works in the real world.

6. The Connection to the Real World

The machine isn't just a standalone toy; it connects to Qiskit, a popular software tool used by quantum researchers.

The Bridge: The author built a "translator" that takes standard quantum code written by humans, breaks it down into the 19 specific moves the machine understands, and sends it to the chip.
The Promise: If you use this tool, it won't silently fall back to a slow computer if the chip fails; it will tell you immediately if something is wrong.

Summary

This paper presents a high-speed, custom-built quantum simulator that uses a specialized chip with massive memory bandwidth to simulate quantum circuits with extreme precision.

What it achieved: It successfully simulated up to 15 qubits with perfect accuracy and proved that a specific "9-door" memory design is necessary to make the chip work.
What it found: It hit a wall at 16 qubits due to a traffic jam in the memory system, identified the exact cause, and proposed a fix.
The Bottom Line: It's a proof-of-concept that shows how carefully designing the "plumbing" (memory access) of a chip can make it much faster at simulating quantum physics, provided you respect the physical limits of the chip's wiring.

Technical Summary: A Native RTL Quantum Statevector Simulator in FP64 on an HBM-Equipped FPGA

Problem Statement
Full-statevector quantum circuit simulation requires storing and updating $2^n$ complex amplitudes. At double precision (FP64, 16 bytes per amplitude), this imposes a hard memory ceiling of approximately 29 qubits on a single device with 8 GB of memory. While memory capacity defines the upper bound, the performance of such simulators is often constrained by memory bandwidth rather than arithmetic throughput. Single-qubit gates require touching every amplitude exactly once, and two-qubit gates require scanning all amplitudes to identify active pairs. Existing FPGA simulators have historically been limited to on-chip BRAM (capping at ~5–16 qubits) or off-chip DDR4, and most operate in single or mixed precision. Furthermore, High-Level Synthesis (HLS) tools often lack the granular control required to optimize memory interleaving and AXI master counts, leading to routing failures on complex HBM fabrics.

Methodology
The paper presents qsim, a native Verilog RTL implementation of a double-precision statevector simulator targeting the Xilinx Alveo U55C FPGA. The design is a structural translation of a validated HLS kernel (v06) into hand-written RTL to gain explicit control over pipeline structure, memory geometry, and timing.

Architecture and Memory Topology: The system utilizes the U55C's 16 GB HBM2 subsystem. A critical architectural invariant is the nine-AXI-master constraint: the design uses eight independent AXI4 master ports for amplitude banks and one shared port for gate instructions. This topology was derived from a routing failure in the prior HLS attempt (which tried to use 17 masters), where the Vivado router rejected the 16-bank design due to congestion in the HBM switch region. The eight-bank topology uses a modulo-eight interleaving scheme (bank(k) = k mod 8) to distribute amplitude indices across banks, enabling parallel AXI4 transactions.
Gate Engines: The kernel implements 19 gate opcodes via three specialized engines:
1. SG Engine (Single-Qubit): Executes arbitrary $2 \times 2$ unitary matrices. It employs a pipelined FP64 complex multiplier (cmul_fp64) with a 7-cycle latency, built from Xilinx Floating-Point Operator IPs.
2. CNOT Engine: Performs conditional amplitude swaps without floating-point arithmetic. It includes a serialisation path for "same-bank" swaps (where control and target qubits map to the same HBM bank) to prevent write collisions.
3. CZ Engine: Negates amplitudes by inverting the IEEE 754 sign bit, requiring no arithmetic units.
Parametric Gates: Matrices for parametric gates (RX, RY, RZ, P, U2, U3) are assembled on-chip using a 24-cycle CORDIC pipeline to generate $\cos(\theta)$ and $\sin(\theta)$ values. Fixed matrices are stored in a combinational BRAM-free ROM.
Host Integration: The system is exposed via a Qiskit 1.0.2 BackendV2. The Python host layer transpiles circuits to the native 17-gate basis, encodes gates into 256-bit packets, and manages DMA transfers via the Xilinx Runtime (XRT). The backend explicitly raises errors if hardware execution fails, avoiding silent fallback to software.

Key Contributions

Native RTL Implementation: A complete, synthesizable Verilog RTL kernel for the Alveo U55C, implementing 19 gate opcodes at FP64 precision, replacing a prior HLS design to ensure routing feasibility and pipeline control.
Routing-Validated Architecture: The establishment of the nine-AXI-master (8 banks + 1 gate) topology as a non-negotiable architectural invariant, documented through the analysis of a prior routing failure.
Specialized Hardware Engines:
- A 7-cycle pipelined FP64 complex multiplier.
- A CNOT engine with explicit same-bank write serialisation logic.
- A CZ engine utilizing sign-bit inversion.
Qiskit Backend: A full BackendV2 integration that handles transpilation, packet encoding, and statevector retrieval, ensuring the hardware is the sole execution path.
Verification and Characterization: Functional verification of eight correctness tests (including Bell and GHZ states) and a qubit-sweep experiment (n=1 to n=20) quantifying execution scaling.

Results

Functional Correctness: RTL simulation using Vivado xsim confirmed all eight functional tests with amplitude errors below $10^{-9}$ .
GHZ Sweep (n=1 to 15): The simulator achieved perfect fidelity ( $F=1.0$ ) for GHZ circuits from 1 to 15 qubits. The execution time scaled at approximately 2.16× per qubit, slightly above the theoretical $2\times$ minimum due to the CNOT engine's overhead of scanning all $2^n$ indices (including inactive ones) and fixed FSM transition costs.
n ≥ 16 Failure: For $n \ge 16$ , the simulation failed (fidelity dropped to 0.5). The paper identifies the root cause as a same-bank write serialisation defect in the CNOT engine. When the target qubit index exceeds 15, all active swap pairs map to the same HBM bank. A race condition in the write FSM allowed the second write of a pair to be dropped if the arbiter returned to an idle state too quickly. The paper documents a minimal one-line fix (adding a wait state for the arbiter's ready signal) to resolve this.
Projected Performance: At the target clock of 258.5 MHz, a 15-qubit GHZ circuit is projected to execute in ~9.19 ms, while a 20-qubit circuit would take ~390 ms (excluding the defect).

Significance
The paper positions qsim as the first double-precision statevector FPGA simulator built around HBM2 and exposed through a modern, transpiler-aware Qiskit backend. Its significance lies not in escaping the exponential memory ceiling of statevector simulation, but in providing a verified, hardware-faithful implementation of the method on a high-bandwidth platform. By moving from HLS to native RTL, the authors demonstrate that explicit control over memory interleaving and AXI master counts is essential for achieving timing closure on HBM-equipped FPGAs. The work offers an honest characterization of scaling limits and specific hardware failure modes (such as the same-bank write defect), providing a transparent baseline for future hardware-accelerated quantum simulation efforts.