⚡ electrical engineering

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

Dieses Paper präsentiert eine native Verilog-RTL-Implementierung eines hochperformanten FP64-Quantenzustandsvektor-Simulators auf einem HBM-bestückten FPGA, der durch die Übersetzung eines validierten HLS-Kernels in handgeschriebene Logik mit spezialisierten Gate-Engines und einer optimierten HBM-Speicherarchitektur eine perfekte Fidelität für bis zu 15 Qubits erreicht, während es gleichzeitig einen spezifischen Verifizierungsfehler für 16 oder mehr Qubits dokumentiert.

Ursprüngliche Autoren: Nasir Ali Nasir Ali

Veröffentlicht 2026-07-02✓ Author reviewed ⓘ

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Nasir Ali Nasir Ali

Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, ein magisches, paralleles Universum zu simulieren, in dem eine einzelne Münze gleichzeitig Kopf und Zahl sein kann. In der Welt des Quantencomputings ist diese „Münze“ ein Qubit. Um ein System mit vielen dieser Münzen auf einem herkömmlichen Computer zu simulieren, müssen Sie jede mögliche Kombination von Kopf und Zahl gleichzeitig im Blick behalten.

Dieses Paper beschreibt eine eigens entwickelte Maschine, die genau das tut, aber mit einem Clou: Anstatt einen Standard-Computerchip zu verwenden, hat der Autor ein spezialisiertes „Gehirn“ auf einem FPGA (einem Chip, den man wie ein digitales Lego-Set umprogrammieren kann) gebaut, das mit einem superschnellen, hochkapazitiven Speichersystem namens HBM bestückt ist.

Hier ist eine Aufschlüsselung der Geschichte des Papers, unter Verwendung einfacher Analogien:

1. Das Problem: Der „Bibliotheks“-Engpass

Die Simulation von Quantencomputern ist wie der Versuch, jedes Buch in einer Bibliothek zu lesen, die sich jedes Mal verdoppelt, wenn man ein neues Regal hinzufügt.

Die Mathematik: Wenn man 29 Qubits hat, muss man 536 Millionen komplexe Zahlen speichern. Das sind Unmengen an Daten.
Der Engpass: Die meisten Computer sind schnell in der Mathematik, aber langsam beim Abrufen von Daten aus dem Speicher. Es ist wie ein genialer Koch (der Prozessor), der eine Mahlzeit in einer Sekunde zubereiten kann, aber die Speisekammer (der Speicher) so weit entfernt ist, dass er 99 % seiner Zeit damit verbringt, hin und her zu laufen, um Zutaten zu holen.
Das Limit: Aus diesem Grund stoßen die meisten Simulatoren bei etwa 29 Qubits an eine Wand. Ihnen geht schlichtweg der Platz oder die Zeit aus.

2. Die Lösung: Ein maßgeschneiderter „Super-Bibliothekar“

Der Autor, Nasir Ali, hat eine maßgeschneiderte Engine namens qsim auf einem Xilinx Alveo U55C Chip gebaut. Dieser Chip ist besonders, weil er über HBM2 (High-Bandwidth Memory) verfügt.

Die Analogie: Stellen Sie sich eine Bibliothek vor, in der die Bücher nicht in einem Keller auf Regalen liegen, sondern in 8 verschiedenen Räumen direkt neben dem Koch angeordnet sind. Der Koch hat 8 Assistenten (Datenpfade), die in der Lage sind, gleichzeitig aus allen 8 Räumen Bücher zu holen.
Die Geschwindigkeit: Dieses Setup ermöglicht es der Maschine, Daten mit etwa 460 GB/s zu bewegen. Das ist so, als würde man das gesamte Internet in wenigen Sekunden herunterladen, nur um den Prozessor zu füttern.

3. Wie es funktioniert: Die drei spezialisierten Arbeiter

Die Maschine versucht nicht, alles mit einem einzigen riesigen Gehirn zu erledigen. Stattdessen nutzt sie drei spezialisierte Arbeiter (Engines), die verschiedene Arten von Quanten-„Zügen“ (Gates) handhaben:

Der Mathe-Arbeiter (Single-Qubit Engine): Wenn ein Zug komplexe Mathematik erfordert (wie das Drehen einer Münze), nutzt dieser Arbeiter einen hochgradig optimierten Rechner, der 7 Schritte benötigt, um eine Berechnung abzuschließen. Er ist schnell und präzise.
Der Swap-Arbeiter (CNOT Engine): Einige Züge erfordern lediglich das Vertauschen zweier Münzen. Dieser Arbeiter macht keine Mathematik; er tauscht einfach die Datenpakete aus. Es ist, als würde ein Bibliothekar zwei Bücher im Regal austauschen, ohne sie zu lesen.
Der Flip-Arbeiter (CZ Engine): Einige Züge ändern nur das „Vorzeichen“ einer Zahl (verwandeln ein Plus in ein Minus). Dieser Arbeiter betätigt lediglich einen einzelnen Schalter an den Daten. Er ist der schnellste aller Arbeiter.

4. Die „Neun-Türen-Regel“ (Eine kritische Entdeckung)

Einer der interessantesten Teile des Papers ist eine Lektion, die auf die harte Tour gelernt wurde.

Der Fehler: Der Autor versuchte zuerst, das System mit 16 Türen (Speicherports) zu der Bibliothek zu entwerfen, in der Annahme, dass mehr Türen den Zugriff beschleunigen würden.
Der Absturz: Die interne Verdrahtung des Chips konnte 16 Türen, die gleichzeitig offen sind, nicht bewältigen. Es war, als versuche man, 16 Lieferwagen in einen Parkplatz zu quetschen, der für 8 ausgelegt ist; sie stießen zusammen, und das Design scheiterte.
Die Lösung: Der Autor reduzierte das Design auf 9 Türen (8 für Daten, 1 für Instruktionen). Dies passte perfekt. Das Paper betont, dass dies nicht nur ein kleiner „Feinschliff“ ist, sondern eine harte Regel. Wenn man versucht, mehr Türen hinzuzufügen, kann der physische Chip die Drähte schlichtweg nicht korrekt routen.

5. Die Ergebnisse: Erfolg und ein Glitch

Der Autor testete diese Maschine, indem er einen „GHZ-Zustand“ (ein spezifisches Quantenmuster) mit zunehmender Anzahl an Qubits simulierte.

Der Erfolg: Für Systeme mit 1 bis 15 Qubits arbeitete die Maschine perfekt. Sie lieferte die korrekten Ergebnisse mit 100 % Genauigkeit. Die Zeit, die für die Simulation benötigt wurde, wuchs vorhersehbar (etwa 2,16-mal langsamer für jedes zusätzliche Qubit), was der Mathematik entspricht.
Der Glitch: Als der Autor versuchte, 16 oder mehr Qubits zu simulieren, lieferte die Maschine falsche Antworten.
- Die Ursache: Es stellte sich heraus, dass bei einem zu großen System zwei „Swap-Arbeiter“ versuchten, zur exakt gleichen Zeit in denselben Speicherraum zu schreiben. Sie standen sich gegenseitig im Weg, und ein Schreibvorgang ging verloren.
- Die Lösung: Der Autor fand die exakte Codezeile, die den Verkehrsstau verursachte, und fügte eine einfache „Warte“-Instruktion hinzu, damit sie sich abwechseln. Diese Lösung ist dokumentiert, aber das Paper merkt an, dass der abschließende Hardware-Test noch nicht durchgeführt wurde, um zu bestätigen, ob die Korrektur in der realen Welt funktioniert.

6. Die Verbindung zur realen Welt

Die Maschine ist kein isoliertes Spielzeug; sie verbindet sich mit Qiskit, einem populären Software-Tool, das von Quantenforschern verwendet wird.

Die Brücke: Der Autor baute einen „Übersetzer“, der den Standard-Quantencode, den Menschen schreiben, nimmt, ihn in die 19 spezifischen Züge zerlegt, die die Maschine versteht, und ihn an den Chip sendet.
Das Versprechen: Wenn Sie dieses Werkzeug verwenden, wird es nicht stillschweigend auf einen langsamen Computer zurückgreifen, falls der Chip versagt; es wird Ihnen sofort mitteilen, wenn etwas nicht stimmt.

Zusammenfassung

Dieses Paper präsentiert einen hochgeschwindigkeits-basierten, maßgeschneiderten Quanten-Simulator, der einen spezialisierten Chip mit massiver Speicherbandbreite nutzt, um Quantenschaltkreise mit extremer Präzision zu simulieren.

Was es erreichte: Es simulierte erfolgreich bis zu 15 Qubits mit perfekter Genauigkeit und bewies, dass ein spezifisches „9-Türen“-Speicherdesign notwendig ist, um den Chip funktionsfähig zu machen.
Was es fand: Es stieß bei 16 Qubits aufgrund eines Verkehrsstaus im Speichersystem an eine Grenze, identifizierte die genaue Ursache und schlug eine Lösung vor.
Das Fazit: Es ist ein Proof-of-Concept, der zeigt, wie die sorgfältige Gestaltung der „Rohre“ (des Speicherzugriffs) eines Chips die Simulation von Quantenphysik extrem beschleunigen kann, sofern man die physikalischen Grenzen der Verdrahtung des Chips respektiert.

Technische Zusammenfassung: Ein nativer RTL-Quantenzustandsvektor-Simulator in FP64 auf einer HBM-fähigen FPGA

Problemstellung
Die Simulation von Quantenschaltkreisen mit vollem Zustandsvektor erfordert die Speicherung und Aktualisierung von $2^n$ komplexen Amplituden. Bei doppelter Genauigkeit (FP64, 16 Bytes pro Amplitude) ergibt sich daraus eine harte Speicherobergrenze von etwa 29 Qubits auf einem einzelnen Gerät mit 8 GB Speicher. Während die Speicherkapazität die obere Grenze definiert, wird die Leistung solcher Simulatoren oft durch die Speicherbandbreite und nicht durch den Arithmetik-Durchsatz begrenzt. Ein-Qubit-Gatter erfordern das Berühren jeder Amplitude genau einmal, während Zwei-Qubit-Gatter alle Amplituden scannen müssen, um aktive Paare zu identifizieren. Bestehende FPGA-Simulatoren waren historisch entweder auf On-Chip-BRAM beschränkt (ca. 5–16 Qubits) oder auf Off-Chip-DDR4, und die meisten operieren in Single- oder Mixed-Precision. Zudem mangelt es High-Level-Synthesis-Tools (HLS) oft an der erforderlichen granularen Kontrolle zur Optimierung von Speicherinterleaving und AXI-Master-Anzahlen, was zu Routing-Fehlern auf komplexen HBM-Fabrics führt.

Methodik
Das Paper präsentiert qsim, eine native Verilog-RTL-Implementierung eines Double-Precision-Zustandsvektor-Simulators, der auf die Xilinx Alveo U55C FPGA abzielt. Das Design ist eine strukturelle Übersetzung eines validierten HLS-Kernels (v06) in handgeschriebenes RTL, um eine explizite Kontrolle über die Pipeline-Struktur, die Speichergeometrie und das Timing zu gewinnen.

Architektur und Speicher-Topologie: Das System nutzt das 16 GB HBM2-Subsystem der U55C. Eine kritische architektonische Invariante ist die neun-AXI-Master-Beschränkung: Das Design verwendet acht unabhängige AXI4-Master-Ports für Amplitude-Banks und einen gemeinsamen Port für Gate-Instruktionen. Diese Topologie wurde aus einem Routing-Fehler beim vorangegangenen HLS-Versuch abgeleitet (der versuchte, 17 Master zu verwenden), bei dem der Vivado-Router das 16-Bank-Design aufgrund von Kongestionsproblemen in der HBM-Switch-Region ablehnte. Die Acht-Bank-Topologie nutzt ein Modulo-Acht-Interleaving-Schema (bank(k) = k mod 8), um Amplitude-Indizes über die Banks zu verteilen, was parallele AXI4-Transaktionen ermöglicht.
Gate-Engines: Der Kernel implementiert 19 Gate-Opcodes über drei spezialisierte Engines:
1. SG Engine (Single-Qubit): Führt beliebige $2 \times 2$ unitäre Matrizen aus. Sie verwendet einen pipelinierten FP64-Komplex-Multiplizierer (cmul_fp64) mit einer Latenz von 7 Zyklen, der aus Xilinx Floating-Point Operator IPs aufgebaut ist.
2. CNOT Engine: Führt bedingte Amplitude-Swaps ohne Fließkomma-Arithmetik durch. Sie enthält einen Serialisierungspfad für „Same-Bank“-Swaps (wenn Control- und Target-Qubit auf dieselbe HBM-Bank abgebildet werden), um Schreibkollisionen zu verhindern.
3. CZ Engine: Invertiert Amplituden durch Umkehrung des IEEE 754 Vorzeichen-Bits, was keine Arithmetikeinheiten erfordert.
Parametrische Gatter: Matrizen für parametrische Gatter (RX, RY, RZ, P, U2, U3) werden auf dem Chip mittels einer 24-Zyklus-CORDIC-Pipeline zusammengesetzt, um $\cos(\theta)$ - und $\sin(\theta)$ -Werte zu generieren. Feste Matrizen sind in einem kombinatorischen BRAM-freien ROM gespeichert.
Host-Integration: Das System wird über ein Qiskit 1.0.2 BackendV2 exponiert. Die Python-Host-Schicht transpilierte Schaltkreise in die native 17-Gate-Basis, kodiert Gatter in 256-Bit-Pakete und verwaltet DMA-Transfers über die Xilinx Runtime (XRT). Das Backend wirft explizit Fehler, falls die Hardware-Ausführung fehlschlägt, um ein stilles Fallback auf Software zu vermeiden.

Wesentliche Beiträge

Native RTL-Implementierung: Ein vollständiger, synthetisierbarer Verilog-RTL-Kernel für die Alveo U55C, der 19 Gate-Opcodes in FP64-Präzision implementiert und ein vorangegangenes HLS-Design ersetzt, um die Routing-Machbarkeit und Pipeline-Kontrolle zu gewährleisten.
Routing-validierte Architektur: Die Etablierung der neun-AXI-Master-Topologie (8 Banks + 1 Gate) als nicht verhandelbare architektonische Invariante, dokumentiert durch die Analyse eines vorangegangenen Routing-Fehlers.
Spezialisierte Hardware-Engines:
- Ein 7-Zyklen-pipelinerter FP64-Komplex-Multiplizierer.
- Eine CNOT-Engine mit expliziter Logik zur Serialisierung von Same-Bank-Schreibvorgängen.
- Eine CZ-Engine, die die Vorzeichen-Bit-Invertierung nutzt.
Qiskit-Backend: Ein vollständiges BackendV2-Integration, das Transpilierung, Paketkodierung und Zustandsvektor-Abruf handhabt und sicherstellt, dass die Hardware der einzige Ausführungspfad ist.
Verifizierung und Charakterisierung: Funktionale Verifizierung durch acht Korrektheitstests (einschließlich Bell- und GHZ-Zustände) und ein Qubit-Sweep-Experiment (n=1 bis n=20), welches die Skalierung der Ausführungszeit quantifiziert.

Ergebnisse

Funktionale Korrektheit: Die RTL-Simulation mittels Vivado xsim bestätigte alle acht Funktionstests mit Amplitude-Fehlern unter $10^{-9}$ .
GHZ-Sweep (n=1 bis 15): Der Simulator erreichte eine perfekte Fidelität ( $F=1.0$ ) für GHZ-Schaltkreise von 1 bis 15 Qubits. Die Ausführungszeit skalierte mit etwa 2,16× pro Qubit, was leicht über dem theoretischen Minimum von $2\times$ liegt, bedingt durch den Overhead der CNOT-Engine beim Scannen aller $2^n$ Indizes (einschließlich inaktiver) sowie durch feste FSM-Transitionskosten.
Fehler bei n ≥ 16: Für $n \ge 16$ schlug die Simulation fehl (Fidelität sank auf 0,5). Das Paper identifiziert die Ursache als einen Same-Bank-Write-Serialisierungsdefekt in der CNOT-Engine. Wenn der Target-Qubit-Index 15 überschreitet, bilden alle aktiven Swap-Paare dieselbe HBM-Bank. Eine Race Condition in der Write-FSM führte dazu, dass der zweite Schreibvorgang eines Paares verworfen wurde, falls der Arbiter zu schnell in den Idle-Zustand zurückkehrte. Das Paper dokumentiert eine minimale Ein-Zeilen-Korrektur (Hinzufügen eines Wait-States für das Ready-Signal des Arbiters), um dies zu lösen.
Projizierte Performance: Bei der Ziel-Taktfrequenz von 258,5 MHz wird ein 15-Qubit-GHZ-Schaltkreis in ca. 9,19 ms ausgeführt, während ein 20-Qubit-Schaltkreis etwa 390 ms benötigen würde (exklusive des Defekts).

Bedeutung
Das Paper positioniert qsim als den ersten Double-Precision-Zustandsvektor-FPGA-Simulator, der um HBM2 aufgebaut und über ein modernes, transpiler-aware Qiskit-Backend exponiert wird. Seine Bedeutung liegt nicht darin, die exponentielle Speicherbegrenzung der Zustandsvektor-Simulation zu umgehen, sondern eine verifizierte, hardwaregetreue Implementierung dieser Methode auf einer hochbandbreitigen Plattform bereitzustellen. Durch den Wechsel von HLS zu nativem RTL demonstrieren die Autoren, dass die explizite Kontrolle über Speicherinterleaving und AXI-Master-Anzahlen essenziell ist, um Timing-Closure auf HBM-fähigen FPGAs zu erreichen. Die Arbeit bietet eine ehrliche Charakterisierung der Skalierungsgrenzen und spezifischer Hardware-Fehlermodi (wie den Same-Bank-Write-Defekt) und liefert damit eine transparente Baseline für zukünftige hardwarebeschleunigte Quantensimulationsbemühungen.