Python in the front, party in the Backline: compiling quantum workloads across CPUs, GPUs, and FPGAs

AI summary

Overview

Research area: Quantum computing systems software — heterogeneous compilation and low-latency runtime infrastructure for fault-tolerant quantum computing (FTQC), spanning compilers (MLIR/LLVM), quantum programming frameworks (PennyLane/Catalyst), and high-performance networking (RDMA/RoCE).

Technical level: Advanced. The paper assumes familiarity with quantum error correction, compiler intermediate representations, and HPC networking, though the motivation and results are stated concretely enough for a determined non-specialist.

Scope: The paper introduces Backline, a three-layer (Python frontend, MLIR compiler, runtime) framework inside PennyLane and Catalyst that compiles quantum-classical workloads from Python onto mixtures of CPUs, GPUs, and FPGAs, and reports microsecond-scale round-trip latencies measured over RoCE v2 from an AMD VPK120 FPGA board to a CPU and a GPU.

What This Paper Is About

Fault-tolerant quantum computing requires quantum error correction (QEC) loops that feed measurement outcomes back into the device within very tight deadlines — a regime where interpreted Python is far too slow, and where the fast hardware (FPGAs, ASICs) is painful to program. At the same time, the classical infrastructure around a quantum device is increasingly heterogeneous (CPUs, GPUs, FPGAs, remote nodes), and writing code that spans all of it is complex.

The paper's goal is to let a researcher write a quantum-classical workload in ordinary Python, declare which devices participate and how they connect, and have the compiler and runtime lower that program into low-latency execution across local or distributed CPUs, GPUs, and FPGAs — without the researcher touching kernel-bypass networking or FPGA toolchains.

Key Contributions

1. The Backline framework, built into PennyLane and Catalyst, comprising a declarative Python frontend for device placement, a heterogeneous compilation layer via MLIR, and a low-latency runtime layer that handles memory regions, coprocessor bindings, and data movement.

2. Two complementary MLIR dialects: an executor dialect that governs the movement of code (which device a subprogram runs on and how it gets there, implemented with LLVM ORC v2 and an Executor Process Control mechanism) and a transport dialect that governs the movement of data (a connection-oriented request/reply session covering connect, key exchange, channel establishment, message sizing, per-round posting and collection, and teardown).

3. An implicit data-placement abstraction built from Node, Controller, Coprocessor, and Placement objects declared through a single qp.Backline(...) call, with a transport mode switch between "memcpy" (local prototyping on a Linux machine, optionally with a GPU) and "rdma" (one-sided network writes) requiring no program changes beyond the transport name and node locality.

4. A demonstration of microsecond-scale synchronous co-processing from an AMD VPK120 FPGA controller, with a hardware-handshake engine issuing each round, achieving median steady-state round-trip latencies over RoCE v2 of 2.305 µs to an AMD Ryzen Threadripper PRO CPU and 4.5 µs to an AMD Instinct MI210 GPU, across 10⁶−1 rounds per path.

5. A four-tier latency taxonomy for FTQC systems (Tier 1: 1 ns–1 µs real-time control; Tier 2: 1 µs–100 µs synchronous co-processing; Tier 3: 100 µs–1 s co-located runtime; Tier 4: >1 s distributed workload) that separates what a class of classical hardware can deliver from what a given qubit modality actually requires.

Main Findings

• Sub-5-microsecond FPGA-to-accelerator round trips: With an AMD VPK120 FPGA board as controller, median steady-state round-trip latency over RoCE v2 was 2.305 µs to an AMD Ryzen Threadripper PRO CPU and 4.5 µs to an AMD Instinct MI210 GPU, measured across 10⁶−1 rounds per path. The authors describe this as demonstrating microsecond-scale synchronous co-processing.

• Tier 2 is reachable with commodity hardware: The measured latencies sit inside the paper's Tier 2 band (1 µs–100 µs), the regime the authors target because Tier 1 (1 ns–1 µs) is reachable only with bespoke hardware sitting beside the quantum device.

• Tier requirements are set by the qubit modality's QEC cycle rate: The decoder throughput must keep pace with incoming syndrome data or the computation suffers an exponential backlog slowdown. Required timescales span orders of magnitude: photonic and superconducting systems sit around 1 µs, while ion traps and neutral atoms sit closer to 1 ms. For photonic systems, Tier 1 is a hard requirement for decoding.

• Tail errors motivate auxiliary decoding: An FPGA decoder is expected to correct the majority of events, but a small tail (e.g. beyond the P99.999 percentile) cannot be corrected in time; these are too complex for a fixed decoder design and may benefit from an auxiliary processor running a more sophisticated algorithm in Tier 2. This connects to the paper's earlier framing of iterative decoders such as belief propagation (BP), which are inherently probabilistic and may fail to converge within the operation timescale.

• A concrete prior datapoint for context: In Xanadu's Aurora system, the error-correction decoder was implemented on an FPGA with a latency of 64 ns, and the end-to-end feed-forward latency was slightly below the available 1000 ns budget because of analog, analog-to-digital, and serial communication delays; more optimal hardware choices (zero-latency ADCs, optimized serial transceivers) could bring that additional latency below 100 ns.

• Three interchangeable routes to a coprocessor function: A coprocessor function can be (a) a pre-compiled symbol in a library (e.g. C++, CPU or GPU), (b) a user-supplied Triton kernel compiled ahead-of-time as a GPU kernel, or (c) generated from a CSS code's Tanner graph as a belief-propagation decoder with ordered-statistics post-processing (BP-OSD). The paper's listings reference a Steane decoder and a [[13,1,3]] hypergraph-product code with num_iters=10 and postprocess="osd", targeting platform "hip:gfx90a:64".

• Dynamic decoder dispatch: A coprocessor may register multiple functions selected at run time by a decoder_id field in the payload — for example to apply different decoders to X-type versus Z-type errors. For the self-dual Steane code, one kernel is registered twice.

• Not reported in the supplied content: The paper text provided is truncated partway through the compilation-flow subsection (Section IV-C3), so the full demonstrations of Section V and the applicability discussion of Section VI are not visible. Any throughput, energy, resource-utilization, or comparative-baseline numbers beyond the latencies above are therefore not available here.

Methodology in Plain English

The authors build on their existing open-source stack rather than starting fresh. PennyLane is the Python layer where a user writes a quantum program; Catalyst is the compiler that takes that program and progressively translates it down through MLIR and LLVM into a binary. Backline extends both.

The workflow is:

1. Declare the machine in Python. The user calls qp.Backline(...) with one Controller node (the thing that drives the quantum device and initiates every round — here an FPGA), a list of Coprocessor nodes (helpers that process each message, here a CPU or GPU), and a transport mode. Each node records its hardware type, whether it is remote, how its code is deployed, and, where needed, connectivity details.

2. Let the compiler place the work. That declaration is serialized as an attribute on the generated MLIR module, and every subsequent compiler pass reads the nodes, their targets, and the transport from it. Parts of the program assigned to remote executors are compiled separately for the target architecture and shipped to a catalyst-executor process, where LLVM ORC v2 links and loads them via its Executor Process Control mechanism; external symbols resolve against shared libraries already loaded there. Cross-compilation uses a target sysroot.

3. Generate the low-latency data path. The transport dialect emits a fixed sequence of operations: create a typed session, connect to the peer, exchange memory-region keys, establish the channel, set request/reply sizes, start the session, then per round stage the payload, post it, and collect the reply into a buffer. Non-blocking variants of connect and key exchange (connect_async, exchange_keys_async) completed by await allow bring-up steps to overlap.

4. Run over the network without the CPU in the way. The runtime relies on kernel-bypass and remote direct memory access, using RoCE as the network and transport protocol. Accelerators and RNICs are the only participants in a data exchange, avoiding context switches and unnecessary memory movement between PCIe devices and main memory.

5. Prototype small, deploy big. The same program runs locally with "memcpy" transport — exercising placement, serialization, and the per-round request/reply structure through local memory copies — and then switches to "rdma" for HPC-grade hardware with minimal edits. A lower-level qp.runtime_call escape hatch lets users embed a call to a pre-compiled dynamic library at an exact point in the lowered program, for handshakes or single message transfers.

The measurements use the AMD VPK120 FPGA board as the controller, whose hardware-handshake engine issues each round, with RoCE v2 to a Threadripper PRO CPU and an MI210 GPU.

Why This Matters

Impact on research: The paper argues that a unified end-to-end stack — programming, compilation, orchestration, runtime execution — is essential for hardware-software co-design in FTQC, because it lets teams find bottlenecks, judge application viability, and derive system-level requirements before hardware is finalized. It also makes a deliberate design argument: rather than standardizing a fast-moving field too early and entrenching suboptimal solutions, the authors favor a moving-design specification with "best effort" compatibility, analogous to the LLVM ecosystem's approach across releases. They position vendor-agnostic multi-platform support as a community need, with efforts like NVQLink described as a move in the right direction but limited in target variety.

Real-world applications:

• Auxiliary QEC decoding for tail errors: offloading rare, hard-to-converge events (beyond P99.999) to a CPU or GPU decoder in Tier 2 so the real-time FPGA decoder is never stalled and the decoding backlog cannot build to unresolvable amounts.
• Backup and secondary decoding: a second decoder path that tolerates some execution-time variation, plus the switching infrastructure such decoders require.
• Disaggregated quantum-classical pipelines: assigning dedicated devices to dedicated functions (pre-processing, post-processing, numerical assistance) in the style of disaggregated ML inference environments.
• Rapid QEC protocol prototyping: expressing inner/outer decoder pairings and adaptive control logic in Python, then compiling them for FPGA, CPU, or GPU execution to iterate on protocol design.

Industry relevance: The work is entirely vendor-agnostic at the frontend while targeting real commercial hardware — AMD FPGAs, CPUs, and GPUs — and integrates with the RDMA/RoCE infrastructure already deployed across HPC systems and large-scale machine learning. For quantum platform builders, it offers a path where algorithm researchers, control-system developers, and HPC performance engineers each work at an appropriate abstraction layer without needing each other's expertise.

Future Directions

• Scaling beyond the demonstrated codes: the paper notes that the Aurora example relied on a small-scale code, and that increasing QEC schema complexity will extend decoder execution times, potentially exceeding latency budgets for real-time correction. Whether Tier 2 auxiliary decoding absorbs that growth is an open question.

• Scheduling and resource allocation for auxiliary decoders: the authors observe that using these networks for auxiliary decoding in large-scale quantum systems requires advanced scheduling policies to allocate decoder resources efficiently, while noting that a tightly connected device mesh suffices for most R&D applications.

• Bridging into Tier 1: the framework currently targets Tier 2 programmability, with Tier 1 explicitly reachable only through bespoke hardware beside the quantum device. Tighter coupling between the compiled Backline runtime and hard real-time control hardware is a natural next step.

• Breadth of supported runtime devices and transports: the modular split (frontend / compiler / runtime with a unified C ABI) is presented as making new runtime devices easy to add, so expansion to further target architectures and transport protocols is implied but not yet demonstrated in the visible text.

Target Audience

Quantum computing systems researchers and engineers building FTQC control stacks; compiler engineers working on MLIR/LLVM-based quantum toolchains; HPC performance engineers integrating accelerators and RDMA fabrics with quantum hardware; QEC researchers who need to prototype real-time decoder architectures; and PennyLane/Catalyst users who want to understand how far Python-expressed workloads can be pushed toward microsecond-scale execution. Readers focused on algorithmic quantum advantage or NISQ-era experiments are not the intended audience.

Authors’ abstract

Moving from quantum research and development to production-grade, fault-tolerant quantum workload execution remains one of the most significant challenges facing quantum platform builders. While Python frameworks have enabled an easy entry point for quantum algorithm design, the low-latency requirements for real-time quantum error correction (QEC) demand performance that traditional interpreted environments cannot provide. FPGAs and ASICs play a central role at these layers, but their specialized programming models make development rigid and time-consuming. CPUs, GPUs, and other accelerators introduce a different challenge: as infrastructure becomes increasingly heterogeneous, programming across different devices and their associated abstractions becomes more complex. Allowing researchers to write workloads in high-level languages that map to low-latency execution across diverse distributed target platforms will enable the development of key infrastructure for utility-scale quantum systems. For this, we introduce $\textit{Backline}$, a heterogeneous compilation and runtime framework built within PennyLane and Catalyst. Backline allows us to design and build quantum-classical workloads for high-performance and low-latency devices, with compilation directly from a Python interface through MLIR. We demonstrate the compilation and execution of several quantum workloads with low-latency data movement across a mix of CPUs, GPUs, and FPGAs, for both local and distributed remote hardware targets, all from a vendor-agnostic Python frontend. With an AMD VPK120 FPGA board as the controller, issuing each round from its hardware-handshake engine, we measured median steady-state round-trip latencies over RoCE v2 of $2.305~μ$s to an AMD Ryzen Threadripper PRO CPU and $4.5~μ$s to an AMD Instinct MI210 GPU across $10^6-1$ rounds per path, demonstrating microsecond-scale synchronous co-processing.