Unlocking Real-Time Speed for the Quantum Ecosystem with PennyLane, Backline, and AMD

Sep 10, 2026

Today quantum is never purely quantum. Large-scale systems built for quantum computing, sensing, and networking rely heavily on robust classical processing, from processing of applications to low-level hardware control. Not only that, but tight communication and feedback between quantum processors and classical accelerators are essential to identify and correct errors — a process known as quantum error correction (QEC) — before fragile physical information degrades.

As a result, moving from quantum R&D to production execution remains one of the biggest challenges in the quantum industry at-large. Fault-tolerant quantum systems need to scale while preserving the high-fidelity states of their atomic components, and achieving this demands highly performant classical accelerators and infrastructure engineered for strict microsecond latency. In addition, this must be seamlessly orchestrated with support of cutting-edge quantum algorithms and applications.

PennyLane, an open-source quantum software platform by Xanadu — a leading photonic quantum computing company — enables the design, compilation, and realization of meaningful quantum algorithms alongside the realities of quantum hardware. In a previous blog post, we explored how you can fast-track quantum simulation with Xanadu’s PennyLane on AMD GPUs, as well as how Xanadu and PennyLane are driving development of practical quantum algorithms with industry partners alongside AMD hardware. Today, we’ll introduce Backline, an open platform for compilation and low-latency execution co-designed by Xanadu and AMD that dynamically connects quantum workloads to the right classical engine.

Below, we will outline how you can use Backline to deploy meaningful algorithms in PennyLane to quantum and classical hardware — including AMD adaptive SOCs and FPGAs, RDMA NICs, AMD Instinct™ GPUs, and AMD Ryzen™ Threadripper™ Processor & EPYC™ Server CPUs — with near real-time performance. We’ll also explore the underlying tech stack, understand how Backline and AMD hardware is helping to accelerate Xanadu’s quantum hardware roadmap, and showcase benchmarks to demonstrate the low-latency performance.

The heterogeneous quantum ecosystem

A production-grade quantum system requires an array of different classical components:

CPUs for orchestration and high-level control logic.
GPUs for parallel data crunching and complex decoding.
FPGAs and ASICs for fixed, ultra-low latency hardware control directly next to the quantum processing unit (QPU).

Quantum systems come in many forms, utilizing different physical systems — for example superconducting materials, neutral atoms, trapped ions, and photons — each with drastically different clock rates. Xanadu’s own photonic hardware represents one of the industry's most extreme timing constraints; with an end-to-end real-time feedback loop — from measuring a physical qubit to adjusting the next operation — that have execution budgets on the order of microseconds.

An overview of the different layers in the quantum computing stack, and the various classical hardware and software components that underpin it.

Figure 1: An overview of the different layers in the quantum computing stack, and the various classical hardware and software components that underpin it.

With these extreme timing constraints, the underlying software and classical infrastructure must be capable of orchestrating immediate QEC routines directly on ultra-fast FPGAs, while simultaneously routing more complex, tail-end errors to synchronous classical co-processors (such as CPUs and GPUs). Historically, achieving the sub-microsecond speeds required for quantum hardware meant rewriting application logic into low-level C++ or specialized hardware description languages. Backline changes this paradigm by providing a Python-native "one-stop shop" for co-design across applications, QEC, and hardware.

What is Backline?

Backline is an heterogeneous compilation fabric built natively within the open-source PennyLane platform and its Catalyst compiler. It maps complex quantum control systems and classical hardware components back to a familiar Python interface (where high-level quantum and classical application code is already defined), enabling compilation and deployment to tightly coupled accelerators with low-latency requirements.

Designed to directly solve critical bottlenecks for quantum hardware, Backline is an openly available platform that is accessible and easily translated for cross-modality use. With Backline, anyone can write a QEC encoder or decoder from Python, test it with meaningful quantum algorithms, and immediately deploy it for near-real-time prototyping on actual classical and quantum hardware — while supporting the need to drop through abstractions and write increasingly optimized and low-level code.

Key features include:

Single-digit microsecond latency: With an under 3-microsecond end-to-end latency looping, Backline can effectively support the tight co-processing required for advanced QEC backup decoding by treating CPUs and GPUs as highly responsive, low-latency execution endpoints.
Python-native: With Backline, you can write everything from Python. For example, use Python-based libraries like Triton and Gluon to write highly optimized GPU kernels for quantum coprocessing. You can also choose to connect pre-compiled libraries and functions for use with Backline, alongside high-level quantum application logic — easily jumping through abstraction layers without switching frameworks.
Infrastructure agnostic by design: Different hardware platforms have drastically different requirements for error correction, utilizing classical accelerators from across the ecosystem. Backline leverages the expansive compilation tools of the LLVM ecosystem, and supports CPUs, GPUs, FPGAs, and custom devices from any hardware vendor.
Scale from R&D to production: Backline leverages standard CPUs to deliver sub-3 microsecond latency compute for workloads that do not strictly require heavy parallel GPU processing. This approach directly bypasses global GPU supply constraints and specialized systems that mandate shared CPU/GPU memory, and allows immediate prototyping. As you move towards production, progressively include consumer-grade and enterprise GPUs, FPGAs, and ASICs — all from the same software environment.

Hardware-accelerated QEC with Triton, PennyLane, and Backline

To see Backline in action, let’s consider an end-to-end quantum error correction workflow deployed to a remote FPGA controller. We will define a custom QEC decoder in Python using Triton, target an AMD Instinct™ GPU for co-processing, and let Backline automatically handle the heterogeneous compilation and hardware routing.

First, we’ll create our server configuration, representing our remote servers carrying an AMD GPU, an RDMA-capable NIC, and a AMD Versal™ Premium Series VPK120 board:

		from pathlib import Path
import os

import pennylane as qp

GPU_SERVER = {
    'host':"192.168.3.14",
    'user': USER, # user on the GPU server
    'triple': "x86_64-unknown-linux-gnu",
    'sudo': True,
    'deploy': [Path(os.environ["BACKLINE_BUNDLES"]) / "threadripper-bundle"],
    'executor_bin': "numactl -N 0 -m 0 ./catalyst-executor",
    'env': {"LD_LIBRARY_PATH": "."}
}

FPGA_SERVER = {
    'host': "192.168.3.15",
    'user': "petalinux",  # user on the FPGA server
    'triple': "aarch64-unknown-linux-gnu",
    'sudo': True,
    'deploy': [Path(os.environ["BACKLINE_BUNDLES"]) / "vpk-bundle"],
    'env': {
        "XMM_SQ_TYPE": "PL", "XMM_RQ_TYPE": "PL", "XMM_CQ_TYPE": "PL",
        "XMM_APP_MAX_QP": "4", "XMM_APP_RQ_SGE": "1", "XMM_SQ_DEPTH": "64",
        "XMM_RQ_DEPTH": "128", "HWHS_RTT_WARMUP": "0"
    }
}

Now, we can create the FPGA controller:

		FPGA = qp.Controller(
    name="fpga-controller",
    remote=True,
    executor_options={**SERVER, "port": 8811}
    hardware="fpga",
    init_args={"config": "dev=xib_0;gid=1;sq_mem=bram;data_mem=bram;reply_mem=bram;reply_poll=hw;stride_log2=6"}
)

Before we create our GPU coprocessor, we need to define our QEC decoder coprocessing function. This is the function that will receive quantum measurements (referred to as ‘syndromes’) from the FPGA controller, and process them to determine the corrections that need to be made to the qubits to correct any errors. Here, we use Triton to create a decoder for the Steane code. The Steane code uses just seven qubits to encode a logical (error-corrected) qubit — because this number is so low, we can pre-calculate every solution and store them in a lookup table:

		import triton
import triton.language as tl

# The Steane decoding table: the qubit to flip for each three-bit syndrome, with -1 meaning the
# syndrome was zero and nothing needs correcting.
STEANE_QUBIT_BY_SYNDROME = (-1, 0, 4, 1, 6, 3, 5, 2)

def pack_lookup_table(values, no_error=0xF):
    """Pack the lookup table into one integer, four bits per entry."""
    word = 0
    for i, value in enumerate(values):
        word |= (no_error if value < 0 else value) << (4 * i)
    return word

# A compile-time constant, so the lookup below becomes a shift and a mask with no memory access.
STEANE_LUT = tl.constexpr(pack_lookup_table(STEANE_QUBIT_BY_SYNDROME))

def steane_lookup(syndrome):
    """Return the qubit to correct for one syndrome, or -1 if there is nothing to do."""
    idx = tl.cast(0, tl.uint32)
    for i in tl.static_range(3):
        idx |= tl.cast((syndrome >> (8 * i)) & 1, tl.uint32) << i
    qubit = (tl.cast(STEANE_LUT, tl.uint32) >> (idx * 4)) & 0xF

    # All ones is -1 read as unsigned, which is how the controller recognises "no correction".
    no_error = tl.cast(0xFFFFFFFFFFFFFFFF, tl.uint64)
    return tl.where(qubit == 0xF, no_error, tl.cast(qubit, tl.uint64))

We can use the provided qp.backline.triton_decoder to compile this for our target system, and then it is simply a matter of providing steane_triton_decoder as our coprocessing function when defining the GPU coprocessor.

		steane_triton_decoder = qp.backline.triton_decoder((steane_lookup, steane_lookup), platform="hip:gfx90a:64")

GPU = qp.Coprocessor(
    name="gpu-coproc",
    coprocessor_fn=steane_triton_decoder,
    remote=True,
    endpoint=qp.Endpoint("192.168.1.2", 7760),
    executor_options={**GPU_SERVER, "port": 8813},
    hardware="gpu",
    init_args={"config": "dev=mlx5_1;gid=3;cpu_pin=4;rt=1;gpu=0"}
)

Defining the backline object, we provide our FPGA as the controller, and the GPU as the coprocessor (which will be running our steane_triton_decoder). We will also specify qec_code=”steane”, which will result in Catalyst automatically applying error encoding using the Steane code as it lowers and compiles the program through LLVM and MLIR. Then, we simply pass the backline object to our fault-tolerant quantum program, to use as the execution backend.

		dev = qp.Backline(controller=FPGA, coprocessors=[GPU], transport="rdma", qec_code="steane")

@qp.qjit(capture=True)
@qp.set_shots(1000)
@qp.qnode(dev, mcm_method="one-shot")
def ghz():
    # a simple quantum program that produces a GHZ state
    qp.Hadamard(0)
    qp.CNOT([0, 1])
    qp.CNOT([1, 2])
    return qp.sample([qp.measure(0), qp.measure(1), qp.measure(2)])

We can now execute the fault-tolerant quantum program to see the results:

		>>> sample(ghz())
[fpga-controller] catalyst-executor: loaded /home/petalinux/catalyst-exec/librt_transport.so
[fpga-controller] catalyst-executor: loaded /home/petalinux/catalyst-exec/librt_capi.so
[fpga-controller] catalyst-executor: loaded /home/petalinux/catalyst-exec/librtd_null_qubit.so
[fpga-controller] Listening on 127.0.0.1:7811
[fpga-controller] [127.0.0.1:7811] executor ready, waiting for connections
scp: Connection closed
[gpu-coproc] catalyst-executor: loaded /home/mehrdad.malek/catalyst-exec/librt_transport.so
[gpu-coproc] catalyst-executor: loaded /home/catalyst-exec/librt_capi.so
[gpu-coproc] Listening on 127.0.0.1:7813
[gpu-coproc] [127.0.0.1:7813#3133915] Accepted connection
[fpga-controller] [127.0.0.1:7811] accepted connection from 127.0.0.1:39924 on pid 1209, waiting for next connection
[fpga-controller]
[fpga-controller] === engine RTT (n=16000, 0 warmup dropped, hardware handshake) ===
[fpga-controller]   min          4595 ns
[fpga-controller]   p50          4750 ns
[fpga-controller]   p95          5050 ns
[fpga-controller]   p99          5350 ns
[fpga-controller]   p99.9        5530 ns
[fpga-controller]   max      96567640 ns
[fpga-controller]   mean        10843 ns
samples: [[0 0 0]
 [0 0 0]
 [0 0 0]
 ...
 [0 0 0]
 [0 0 0]
 [0 0 0]]
JIT session error: FD-transport disconnected
JIT session error: disconnecting
JIT session error: FD-transport disconnected
JIT session error: disconnecting

Note that the max number is particularly large for the very first round, which pays for the connection initialization. By setting HWHS_RTT_WARMUP=1 in the board's environment, we can examine the steady state latency values.

In addition to the above example, Backline also supports a myriad of different configurations; from local CPU-CPU interactions using Python-defined kernels, to remote FPGA-GPU interactions using pre-compiled and highly-optimized GPU kernels. Further, Backline supports the ability to prototype the error encoding directly in Python, alongside MLIR-based error encoding passes. For more details, see our Backline demos and tutorials.

Benchmarking the latency floor

To validate the architecture, we ran internal benchmarks to determine the latency floor using an AMD Threadripper™ Pro workstation orchestrated alongside an AMD (Xilinx) VPK120 FPGA (using the ERNIC™ IP block), an RDMA NIC, and an AMD Instinct™ MI210 GPU. The results demonstrate a mean value of 2.3 μs end-to-end latency for the CPU path, and 4.4 μs end-to-end latency for the GPU path — well within the latency requirements for quantum systems.

Figure 2: Caption?

Inside Backline

Backline operates as a dynamic heterogeneous compiler and runtime environment explicitly engineered to sit natively within PennyLane and its Catalyst compiler. At its core, the architecture orchestrates complex quantum-classical workflows through a unified MLIR-based (Multi-Level Intermediate Representation) pipeline to target diverse hardware backends. This architecture enables the progressive lowering of programs — translating high-level Python semantics into hardware-specific dialects down to device-native operations.

Figure 3: Caption?

To meet the real-time needs of quantum hardware systems, data placement and mobility must be built-in across all abstraction layers. Backline utilizes the libibverbs user-space library as the interface to the Linux RDMA (Remote Direct Memory Access) subsystem. By leveraging RoCE V2 (RDMA over Converged Ethernet), the system enables ultra-low-latency data transmission directly between devices, effectively bypassing costly CPU context switches and main memory bottlenecks

Figure 4: Overview of how quantum and classical workflows flow through the Catalyst compiler and the low-latency runtime of Backline, which is handling all heterogenous compilation and orchestration.

Overview of how quantum and classical workflows flow through the Catalyst compiler and the low-latency runtime of Backline, which is handling all heterogenous compilation and orchestration.

Conclusion

Whether the goal is engineering fault-tolerant quantum computers, establishing unhackable secure networks, or developing ultra-precise diagnostic sensors, a singular reality remains today: quantum is never purely quantum. Success across the entire ecosystem depends on high-speed classical infrastructure operating in lockstep behind the scenes.

By transforming complex hardware orchestration into a streamlined, Python-first workflow, Backline ensures that every innovator — from quantum research labs to enterprise engineering teams like those at Xanadu — can design, test, and deploy production-grade quantum technologies alongside classical infrastructure. Going forward, development on Backline will focus on supporting Xanadu’s photonic hardware, and expanding the open platform's reach across the industry — from including a NumPy-like API for co-processors, to explicit memory management via AMD’s open-source space-rt runtime (a spatial runtime for modern accelerators).

Other resources

Backline is available today to help you build and deploy to both quantum and classical hardware.

Documentation — Install Backline, and get started with the qp.Backline functionality in PennyLane today.
Tutorial — Explore our tutorial demonstrating single-digit microsecond latency execution across heterogeneous hardware.
AMD Developer Cloud — Start projects with PennyLane on AMD Instinct™ GPUs
Read the whitepaper — Understand in more detail the challenges we face in building production-scale quantum systems, and how Backline solves these problems.
Learn more in our technical paper — Delve into the technical details behind Backline, including the experimental setups and benchmarks discussed in this blog post.