FPGA‑Based Quantum‑Computer Simulator with a Web‑Based Design‑Run‑Analyse Front‑End”
1. Context & Motivation
Quantum‑computing research still suffers from a shortage of accessible hardware. Cloud‑based quantum‑processors are valuable but expensive and have limited queue times, while classical simulators quickly become infeasible as the number of qubits grows.
Field‑Programmable Gate Arrays (FPGAs) sit in a sweet spot: they are deterministic, low‑latency, and highly re‑configurable, allowing a hardware‑accelerated simulation of quantum circuits that can run orders of magnitude faster than a pure CPU implementation for medium‑size systems (≈10–20 qubits).
Several academic projects (e.g., QuTiP‑FPGA, QSim FPGA, FQP – “FPGA Quantum Processor”) already demonstrate that a state‑vector or density‑matrix simulator can be mapped onto an FPGA fabric. What is still missing for a bachelor‑level research project is a complete, user‑friendly workflow that hides the low‑level HDL/driver details behind a modern web interface:
- Design – drag‑and‑drop or text‑based circuit entry (e.g., OpenQASM, Qiskit‑like syntax).
- Deploy – compile the circuit to a bit‑stream or to a run‑time instruction set that the FPGA can execute.
- Run – launch the simulation on the physical board, collect measurement statistics.
- Evaluate – visualise state probabilities, fidelity, execution time, and resource utilisation.
The thesis will implement such a workflow on a provided development board (e.g., Xilinx Alveo U250, Intel Stratix 10, or a cheaper low‑cost board such as the Digilent Arty‑A7 with a modest number of DSP slices). The core contribution is the integration of an existing FPGA‑based quantum simulator with a web‑portal that offers a seamless “program‑cloud‑simulation‑cloud” experience for students and researchers.
2. Research Questions (RQs)
| # | Question |
|---|---|
| RQ1 | Which quantum‑simulation algorithm (state‑vector, tensor‑network, or Clifford‑stabiliser) can be mapped most efficiently onto the chosen FPGA resources while still supporting a useful subset of gates (U3, CX, measurement)? |
| RQ2 | How can the FPGA‑side simulator be parameterised to accept a generic instruction stream generated from arbitrary OpenQASM programs? |
| RQ3 | What architecture (REST API + WebSockets, Dockerised back‑end, etc.) delivers a responsive web interface while keeping the latency overhead below a few milliseconds for control‑plane messages? |
| RQ4 | Does the integrated environment improve usability (time to get results, learning curve) compared with the “bare‑metal” workflow (HDL → synthesis → bitstream → UART console)? |
| RQ5 | What are the scalability limits (max qubits, gate depth) of the FPGA implementation, and how do they compare with a pure‑software simulator on the same host CPU? |
3. Objectives & Scope
- Re‑use / adapt an existing open‑source FPGA quantum simulator (e.g., qsim‑fpga or QIO‑FPGA) to run on the target board.
- Define a compact instruction set (ISA) that can encode arbitrary OpenQASM‑2.0 programs (or a restricted subset) and write a compiler that translates OpenQASM → ISA binary.
- Implement a host‑side daemon (Python/C++) that receives instruction binaries via a local network, programs the FPGA, triggers execution, and streams back measurement results.
- Create a web front‑end (React/Angular + Flask/Django REST) that provides:
- Text editor with syntax highlighting for OpenQASM (or graphical circuit builder).
- “Compile & Deploy” button.
- Real‑time console showing execution progress.
- Post‑run analysis panels (probability histogram, Bloch‑sphere visualisation, fidelity vs. ideal state).
- Evaluate the whole stack on a set of benchmark circuits (Bell state, GHZ, Quantum Fourier Transform, random Clifford circuits) regarding:
- Execution time (FPGA vs. software baseline).
- Memory / LUT / DSP utilisation on the FPGA.
- User‑experience metrics (task‑completion time, SUS questionnaire).
4. Methodology
4.1. Literature & Tool Survey (Weeks 1‑2)
- Study quantum‑simulation algorithms on FPGAs (state‑vector, tensor‑network, stabiliser).
- Review existing open‑source projects (qsim‑fpga, QIO, QuEST‑FPGA).
- Analyse web‑based quantum‑circuit editors (IBM Quantum Composer, Qiskit‑IBM‑Runtime UI) for UI ideas.
4.2. Platform Selection & Setup (Weeks 3‑4)
- Choose the FPGA board (availability, developer tools, resource budget).
- Install toolchains (Vivado/ISE, Quartus, or open‑source tools like Symbiflow).
- Set up a Linux host with Docker for reproducible builds.
4.3. Core Simulator Adaptation (Weeks 5‑9)
| Sub‑task | Activities |
|---|---|
| Algorithm choice | Benchmark state‑vector vs. stabiliser on a small test‑bench to decide which fits the LUT/DSP budget. |
| HDL / HLS implementation | Port the chosen algorithm to the board using VHDL/Verilog or high‑level synthesis (C/C++ → HLS). |
| Instruction decoder | Design a lightweight packet parser that fetches a 32‑bit instruction word (opcode, qubit indices, rotation angles). |
| Memory mapping | Use on‑chip BRAM for the state vector; if needed, add external DDR interface for > 10 qubits. |
| Measurement / output | Convert final amplitudes to probability distribution; pack into a UDP/TCP packet for the host. |
4.4. Compiler & ISA (Weeks 10‑12)
- Parse a subset of OpenQASM (U3, CX, MEASURE).
- Map each gate to one or more ISA instructions (e.g.,
LOAD_QUBIT,ROTATE,CNOT,MEASURE). - Implement in Python (using ply or lark) → binary file.
4.5. Host Daemon & API (Weeks 13‑15)
- Daemon – Python (asyncio) or C++ (Boost::Asio) process that:
- Receives compiled binaries via a REST endpoint.
- Programs the FPGA (via PCIe, JTAG, or Ethernet‑based remote‑programming).
- Triggers execution and streams results back (WebSockets).
- API – Swagger/OpenAPI definition for /compile, /run, /status, /results.
4.6. Web Front‑End (Weeks 16‑19)
- UI framework – React + Material‑UI (or Vue + Vuetify).
- Editor – Monaco editor (used in VS Code) with OpenQASM grammar.
- Visualisations – Plotly/D3 for histograms, Bloch‑sphere widget (three‑js).
- Docker compose – Front‑end, API daemon, and FPGA driver container for easy deployment.
4.7. Benchmarking & Evaluation (Weeks 20‑23)
- Performance – Compare FPGA simulation time vs. Qiskit Aer on the same host for 5‑, 10‑, 12‑qubit circuits.
- Resource utilisation – Extract utilisation reports from Vivado/Quartus (LUT, FF, DSP, BRAM).
- Usability study – Recruit 8‑12 participants (students) to perform two tasks: (a) bare‑metal workflow, (b) web‑UIworkflow. Collect SUS scores and task‑completion times.
4.8. Documentation & Dissemination (Weeks 24‑28)
- Write the thesis manuscript (introduction, background, design, implementation, results, discussion).
- Produce a user guide (README + video demo).
- Publish the full source code (MIT license) on GitHub with Docker images on Docker Hub.
4.9. Finalisation (Weeks 29‑30)
- Proof‑reading, supervisor review, final submission.
5. Deliverables
| ID | Description |
|---|---|
| D1 | Requirement & Architecture Document – detailed functional and non‑functional specs, system block diagram, ISA definition. |
| D2 | FPGA Bitstream – synthesised design (state‑vector or stabiliser simulator) for the chosen board, with synthesis reports. |
| D3 | OpenQASM → ISA Compiler (Python package, CLI). |
| D4 | Host Daemon & REST/WebSocket API (Python or C++). |
| D5 | Web Front‑End (React app) with editor, compile/deploy buttons, result visualisations. |
| D6 | Benchmark Suite & Evaluation Report – tables/plots for performance, resource usage, user‑study results. |
| D7 | Thesis manuscript (≈60 pages, university format). |
| D8 | Public repository (GitHub) containing all source, Dockerfiles, documentation, and a short video walkthrough. |
6. Tools & Technologies
| Layer | Candidates |
|---|---|
| FPGA Development | Xilinx Vivado (or Intel Quartus) – HLS (C/C++) optional; open‑source Symbiflow for portability. |
| HDL | Verilog/SystemVerilog (or VHDL) – minimal custom logic + pre‑existing simulation kernels. |
| Host Daemon | Python 3.11 (asyncio, Flask/FastAPI) or C++ 17 (Boost::Asio). |
| Compiler | Python with lark parser; output binary format (little‑endian 32‑bit). |
| Web Server | FastAPI (auto‑generated OpenAPI), gunicorn/uvicorn. |
| Front‑End | React 18 + Typescript + Material‑UI; Monaco editor for code editing; Plotly.js/D3 for charts; three.js for Bloch‑sphere. |
| Containerisation | Docker + Docker‑Compose (frontend, API, FPGA‑driver container). |
| Benchmarking | Qiskit Aer (Python) as software baseline; perf & vivado reports for hardware metrics. |
| Usability | SUS questionnaire (System Usability Scale), Google Forms for data collection. |
| Version Control | Git (GitHub). |
7. Risk Assessment & Mitigation
| Risk | Potential Impact | Mitigation |
|---|---|---|
| R1 – FPGA resources insufficient for chosen algorithm (e.g., > 12 qubits needed). | Project stalls or requires redesign. | Start with a stabiliser‑only simulator (Clifford) which needs far fewer resources; later optionally extend to full state‑vector for ≤ 10 qubits. |
| R2 – High latency between web UI and FPGA (network bottleneck). | Poor user experience, invalidates RQ4. | Keep control messages lightweight (≤ 1 KB), use WebSockets for streaming results, perform local (same LAN) testing. |
| R3 – Compiler does not support enough gates → limited circuits. | Benchmarks become trivial. | Initially support the universal gate set (U3 + CX) – sufficient for all benchmark circuits. |
| R4 – Security of the web service (remote code execution). | Vulnerable to attacks when the board is on a shared network. | Run the service inside a Docker container with limited privileges; validate all incoming binaries against a whitelist. |
| R5 – Limited time for FPGA synthesis (hours per build). | Delays the iterative development loop. | Use pre‑synthesised bitstreams for most experiments; only re‑synthesise when modifying the core algorithm. |
8. Evaluation Plan
- Performance Metrics
- Latency – from “Run” click to first measurement result (ms).
- Throughput – number of gate operations per second.
- Scalability – max qubits before the design exceeds 90 % LUT/DSP utilisation.
- Resource Utilisation
- Extract LUT, FF, DSP, BRAM percentages from synthesis reports.
- Usability
- Task‑time: average minutes to go from source code to final histogram (both workflows).
- SUS score (0‑100) after participants finish both tasks.
- Qualitative feedback – open‑ended questions on ease of use, learning curve, and desired features.
- Comparative Analysis
- Plot execution‑time vs. qubit count for FPGA vs. Qiskit Aer on the same host.
- Discuss where the FPGA provides speed‑up and where the overhead (compilation, data transfer) dominates.
Statistical analysis (paired t‑test for task‑time, Wilcoxon signed‑rank for SUS) will be performed to answer RQ4.
9. Timeline (30 Weeks)
| Week | Milestone |
|---|---|
| 1‑2 | Literature review, tool & board selection |
| 3‑4 | Platform setup (toolchains, Docker environment) |
| 5‑9 | Core simulator adaptation (HDL/HLS, ISA decoder) |
| 10‑12 | OpenQASM → ISA compiler |
| 13‑15 | Host daemon & REST/WebSocket API |
| 16‑19 | Web front‑end (editor, visualisations) |
| 20‑23 | Benchmark suite, performance & usability evaluation |
| 24‑26 | Writing results, discussion, conclusions |
| 27‑28 | Thesis polishing, supervisor review |
| 29‑30 | Final submission, repository release, demo video |
10. Why This Is a Suitable Bachelor Thesis
- Well‑bounded scope – All components (simulator, compiler, web UI) can be built incrementally; the most complex part (HDL) is limited to a known algorithm.
- Hands‑on experience – The student works with digital hardware design, software engineering, compiler construction, and human‑computer interaction – a valuable interdisciplinary skill set.
- Immediate applicability – Universities with quantum‑computing curricula can adopt the resulting web portal as a teaching tool; industry partners interested in FPGA‑accelerated simulators will have a prototype to evaluate.
- Deliverable‑driven – Concrete artefacts (bitstream, Docker images, source code, evaluation report) are easy to review and grade.
11. Expected Contributions
| Academic | Practical |
|---|---|
| A1 – A systematic mapping from OpenQASM to a minimal FPGA‑compatible ISA. | P1 – A ready‑to‑run web‑portal that allows anyone to upload a quantum circuit and obtain a hardware‑accelerated simulation instantly. |
| A2 – Empirical data on the performance limits of FPGA‑based quantum simulation for the chosen algorithm. | P2 – Open‑source FPGA design (state‑vector or stabiliser) that can be reused or extended by other students. |
| A3 – Usability assessment of a hardware‑accelerated simulation platform vs. a pure‑software workflow. | P3 – Documentation and Docker images enabling reproducible deployment on any compatible FPGA development board. |
| A4 – Recommendations for future integration of higher‑level quantum languages (Qiskit, Cirq) with FPGA back‑ends. | P4 – A small benchmark suite that can be used to compare future FPGA designs or other accelerators (GPU, ASIC). |
Optional Extensions (to raise the work to Master‑level depth)
If the student wishes (or the programme demands) a more research‑oriented contribution, any two of the following can be added:
| Extension | What is added | Why it matters |
|---|---|---|
| A. Advanced Simulation Kernels – implement a tensor‑network or Clifford‑stabiliser engine that can handle > 15 qubits with the same FPGA resources. | Shows that the platform can be generic rather than a fixed‑size state‑vector. | |
| B. Multi‑FPGA / Distributed Execution – split the quantum state across two identical boards and synchronise via PCIe/ Ethernet. | Demonstrates a path to scaling beyond a single device and yields a performance‑modeling contribution. | |
C. Formal Performance & Resource Modelling – derive an analytical model (e.g. latency = a·2ⁿ + b·depth + c) and validate it against synthesis reports. | Provides a predictive tool for future designers and a publishable quantitative study. | |
| D. Security & Sandboxing – design a lightweight verifier that checks user‑programs for illegal memory accesses or resource exhaustion, and measure the overhead. | Essential for a cloud‑service scenario; adds a security‑research dimension. | |
| E. Large‑Scale Usability Study – recruit ≥ 30 participants, compare the web UI with a traditional “bitstream‑UART” workflow, and analyse SUS/NASA‑TLX scores statistically. | Generates statistically significant evidence of human‑centred benefits, suitable for a conference paper. | |
| F. SDK Integration – provide Qiskit and Cirq back‑ends that automatically translate their circuit objects to the FPGA ISA. | Makes the platform immediately useful to the wider quantum‑software ecosystem and increases impact. |
Choosing any of these extensions deepens the investigation, yields new scientific results, and typically results in a master‑level thesis (≈ 100 pages, plus a short conference‑style manuscript).
Bottom line:
The thesis will bridge the gap between low‑level FPGA quantum‑simulation research and a high‑level, user‑friendly development environment, delivering both a technical contribution (hardware‑accelerated simulator with a clean ISA) and a practical tool (web UI) that can be directly used for teaching or early‑stage quantum algorithm prototyping.