Systems & Engineering

Xanadu and AMD’s Backline Opens a Third Front in the Quantum Control Stack Race

September 10, 2026 – Xanadu Quantum Technologies (NASDAQ/TSX: XNDU) and AMD released Backline, an open-source platform for low-latency communication between quantum processors and classical computing hardware. The platform is built into Xanadu’s PennyLane software framework and connects quantum processors with CPUs, GPUs, and FPGAs.

Xanadu and AMD reported end-to-end loop times below 3 microseconds on the CPU path. The companies said standard AMD CPUs can serve as low-latency coprocessors without enterprise GPUs. In the published benchmark, an AMD Versal FPGA acted as the controller and an AMD Ryzen Threadripper processor as the coprocessor. The platform is open-source, and the companies describe it as infrastructure-agnostic.

“By integrating Backline into PennyLane, we are providing direct access to the communication layers that the industry needs to move from laboratory R&D to real-world performance,” Christian Weedbrook, founder and CEO of Xanadu, said in the announcement.

Scott Tease, corporate vice president of HPC and Sovereign AI at AMD, said the companies co-designed Backline so that a single Python program could span AMD EPYC and Threadripper CPUs, AMD Instinct GPUs, AMD Versal FPGAs, and AMD Pensando networking. “That gives the whole quantum ecosystem an open path from research to production, on hardware developers can use today,” Tease said.

The platform treats a quantum processor as one node in a heterogeneous high-performance computing environment rather than as a separate system connected through a proprietary control stack. Backline uses RDMA over Converged Ethernet v2 (RoCE v2) with zero-copy data paths to achieve its low-latency transport between the FPGA controller and the classical coprocessor.

Backline is available as an open-source feature suite within PennyLane. The companies published a technical paper (arXiv:2609.09270), a joint whitepaper and the source code.


My Analysis

The Backline paper reports more specific numbers than the press release’s “sub-3 microseconds” headline. Using an AMD VPK120 FPGA board as the controller and RoCE v2 transport, the team measured steady-state round-trip latencies of 2.305 µs median to an AMD Threadripper PRO CPU and 4.5 µs to an AMD Instinct MI210 GPU, across approximately one million rounds per path with a 128-bit payload over a 100 Gbps link. The whitepaper gives the means as 2.312 µs and 4.448 µs, with standard deviations of 21.5 ns and 159 ns. The “sub-3 microseconds” claim applies to the CPU path; the GPU path exceeds it.

These are transport loopback measurements – the time for a small payload to travel from the FPGA to the coprocessor and back – not production QEC decode times. That distinction matters because the comparable published figures from competing platforms are the same class of measurement. NVIDIA’s NVQLink, announced in October 2025, reported a mean round-trip latency of 3.84 microseconds with a standard deviation of 35 nanoseconds over 1,000 samples on 400 Gb/s RoCE hardware. A Chinese research team’s THQLink, published in August 2026, reported 2.944 microseconds average round-trip. Backline’s CPU-path floor of 2.3 µs is below both, on a 100 Gbps link against NVQLink’s 400 Gb/s. Its GPU path, at 4.45 µs mean, is slower than NVQLink’s 3.84 µs. None of the three headline numbers includes a production decoder workload.

The decoder has to finish its work within the microseconds that remain after the data has traveled from the quantum processor to the classical hardware and back.

Why the microsecond budget is so tight

A quantum error correction cycle has three phases. The quantum processor measures stabilizer operators to extract error syndromes. A classical decoder processes those syndromes and identifies which corrections to apply. The corrections are sent back to the quantum controller and executed before the qubits decohere.

Superconducting transmon qubits have typical T1 coherence times in the range of 80 to 200 microseconds. For these qubits, the total budget for measurement, decoding, and correction is roughly 10 microseconds. Of that, the transport latency – moving syndrome data out and correction instructions back – is only one component. The decoder needs time to run, and its computational cost grows with code distance. A distance-3 surface code patch is computationally simple. A patch at distance 17 or 23, which is what practical fault-tolerant computation will require, demands substantially more decoder throughput per QEC round.

A Rigetti-Riverlane team published peer-reviewed results in Nature Communications in June 2026, from an experiment first reported in late 2024, demonstrating real-time, low-latency QEC on a superconducting processor. They used an FPGA-based decoder integrated directly into the control electronics of Rigetti’s Ankaa-2 processor and achieved sub-1-microsecond mean decoding time per round (0.44–0.79 µs depending on rounds), with a total feedback latency of 9.6 microseconds across 9 decoding rounds. The tight per-round decoding was possible because the decoder ran on an FPGA sitting next to the control hardware – no network hop, no general-purpose operating system, no CPU scheduler in the path.

Separately, THQLink demonstrated real-time surface-code decoding on CPUs up to distance 19 using a parallel-window matching strategy, at roughly 1 µs per round. That result establishes prior art for CPU-based QEC decoding at a code distance that starts to approach practical relevance.

Backline’s claim that standard AMD server CPUs can handle QEC-related workloads needs to be read against what the companies’ own whitepaper says about where CPUs fit. The whitepaper places ASICs and FPGAs in a hard real-time tier (1 ns–1 µs) that runs the primary QEC decoder and measurement feedforward. It assigns CPUs and GPUs, along with FPGAs, to a 1–100 µs “synchronous co-processing” tier, where they run a backup decoder for the complex or correlated “tail-end” errors the primary decoder cannot resolve quickly. That is a more conservative positioning than the press release’s headline suggests.

Three architectures, three bets

The quantum control stack now has three competing architectural approaches for the classical side of the QEC feedback loop, each making a different bet about where decoding compute should run.

NVIDIA NVQLink routes syndrome data over RDMA-capable Ethernet to GPU-based decoders running on Grace Hopper or GB200 hardware. The approach has the broadest vendor backing in the industry: 17 QPU builders, five control electronics providers, and nine U.S. national laboratories signed on at launch. Quantinuum demonstrated a 67-microsecond median qLDPC decoder latency (BP+OSD on Bring’s code) on its Helios trapped-ion system over NVQLink – approximately 32 times faster than Helios’s 2-millisecond decoder-reaction requirement. The GPU approach trades hardware cost and power consumption for raw compute throughput, which should scale well as decoder algorithms grow more complex at higher code distances.

Riverlane’s QECi takes the opposite path: a purpose-built open-source specification for the control-to-decoder interface, designed to run on FPGAs integrated directly into the control electronics. Riverlane argues that a QEC-specific interface will scale past the point where general-purpose RDMA-based links begin to saturate, which the company places beyond roughly 300 physical qubits. Qblox has demonstrated Deltaflow 2 integration over QECi, closing a full real-time QEC loop at 6.886 µs for Surface-17 and 11.886 µs for Surface-161 with emulated measurement data. Quantum Machines has demonstrated Deltaflow 2 integration with its OPX1000. The FPGA approach optimizes for deterministic, bounded latency at the expense of decoder flexibility – changing the decoding algorithm means resynthesizing the FPGA design.

Backline now offers a third option: run parts of the feedback loop on commodity server CPUs, accessed through PennyLane’s Python interface, compiled down to low-level execution via the Catalyst compiler and MLIR. The same Python program can also target GPUs and FPGAs, and in the whitepaper’s own QEC model the primary decoder executes on an FPGA or ASIC and the backup decoder on the CPU. The cost advantage is real. An AMD Threadripper PRO server is dramatically cheaper than a DGX Quantum node, and every data center already has the procurement channels, power infrastructure, and operational expertise to deploy and maintain x86 servers. If general-purpose CPUs can sustain that backup-decoding workload at scale, the classical infrastructure cost of building a fault-tolerant quantum computer drops substantially.

The word “if” carries the entire weight of that sentence.

What Backline has not yet demonstrated

The eWeek analysis of the announcement identified the right gap: all performance claims to date come from Xanadu and AMD. No independent team has tested Backline under production QEC conditions.

Several specific questions remain open.

First, decoder load. The sub-3-microsecond benchmark ran no decoder; it echoed a 128-bit payload. The whitepaper’s worked examples run two small decoders: a Steane lookup table and BP+OSD on a 13-qubit qLDPC code. The one timing it prints with a decoder attached comes from the FPGA-to-GPU path running Catalyst’s precompiled Steane decoder: a median round trip of 4.86 µs over 16,000 rounds, against 4.5 µs for the bare GPU echo.

The whitepaper reports no decoder timing on the CPU path. A distance-3 Steane code is a different computational problem from a Union-Find or neural-network decoder at distance 15, and no timing at that scale is published.

Second, jitter under load. Operating system scheduling, cache misses, interrupt handling, and memory allocation all produce latency jitter on a CPU. For QEC, jitter can be worse than high average latency – a single late correction in a sequence of 10,000 QEC rounds can propagate a logical error. The Rigetti-Riverlane FPGA decoder had low, bounded latency with a known worst case.

For the transport alone, the Backline whitepaper publishes more of the tail than NVIDIA did for NVQLink, which gave a 35 ns standard deviation and a 3.96 µs maximum. The Backline CPU echo held a 21.5 ns standard deviation and a 99.999th percentile of 2.475 µs, tighter than the GPU echo’s 159 ns and 5.26 µs. Both paths still recorded worst cases near twice their medians: 4.64 µs on the CPU and 9.27 µs on the GPU. Xanadu and AMD measured those figures on an echo with no decoder running and have not published the same distribution under sustained decoding load.

Third, modality. Xanadu builds photonic quantum computers. Its whitepaper places light-based hardware at the fast end of the clock-rate range, with superconducting systems on microsecond cycles and trapped ions on millisecond cycles. Xanadu’s own Aurora system used an FPGA decoder at 64 nanoseconds latency within a feed-forward budget of roughly 1,000 nanoseconds – an order of magnitude tighter than the 10 µs superconducting budget.

Backline’s 2.3 µs CPU round trip is more than twice that photonic budget, which fits the whitepaper’s design of keeping the primary decoder on the FPGA and sending only tail-end errors to a CPU or GPU. Neither the benchmark nor the worked examples put a quantum processor of any modality in the loop; the quantum side ran on simulators. The companies’ claim that the platform works across qubit modalities will need validation on real hardware.

Fourth, scaling. Quantum Machines documented that real-time QEC with lattice surgery and qLDPC codes requires distributed, cross-dependent parallel decoding – multiple decoders exchanging data in real time during a single QEC round. One CPU handling one decoder for a small code patch is a solved problem. Hundreds of decoders coordinating across a multi-thousand-qubit system while maintaining microsecond-scale total latency is not. Xanadu and AMD have not yet shown whether a CPU-based approach can scale to that regime, or whether the inherent parallelism of GPUs or the deterministic timing of FPGAs becomes necessary.

The competition is the contribution

Teams specifying the classical side of the QEC loop now have a third architecture to weigh against NVQLink and QECi.

Eleven months ago, NVIDIA’s NVQLink looked like a strong candidate for a de facto standard in the quantum-classical interface layer. Seventeen QPU builders and five control electronics providers had signed on, and the hardware was shipping. NVIDIA had also published a standard deviation and a worst case for NVQLink’s latency. Riverlane’s QECi offered a credible alternative for teams building around FPGA-based control electronics, but the ecosystem was narrower.

Backline introduces a third architectural path – CPU-first, open-source, integrated into one of the most widely used quantum software frameworks – and in doing so turns the classical control stack from a two-horse race into an open market. That is consistent with the Quantum Open Architecture trajectory I have been tracking: the quantum computing supply chain is disaggregating into independently sourceable layers, and the control-to-decoder interface is one of the layers where the specification war is now actively underway.

For teams building or procuring quantum systems today, the practical implication is that the control-to-decoder interface is itself a specification decision, and deferring it carries increasing risk. Choosing NVQLink locks you into the NVIDIA GPU ecosystem for decoder compute. Choosing QECi locks you into FPGA-based decoding with Riverlane’s interface specification. Choosing Backline locks you into PennyLane as the orchestration layer. Each lock-in has a different cost profile, scaling trajectory, and vendor dependency.

None of the three has demonstrated real-time QEC decoding on a fault-tolerant-scale system. All three are building toward a future that remains years away. The right response for a builder is not to pick a winner today but to ensure that the control electronics and network architecture being specified now can support at least two of the three interface options – because retrofitting a low-latency decoder link into a system not designed for it is prohibitively expensive, and the winner of this particular race is not yet clear.

Marin Ivezic

I am the Founder of Applied Quantum (AppliedQuantum.com), a research-driven consulting firm empowering organizations to seize quantum opportunities and proactively defend against quantum threats. A former quantum entrepreneur, I’ve previously served as a Fortune Global 500 CISO, CTO, Big 4 partner, and leader at Accenture and IBM. Throughout my career, I’ve specialized in managing emerging tech risks, building and leading innovation labs focused on quantum security, AI security, and cyber-kinetic risks for global corporations, governments, and defense agencies. I regularly share insights on quantum technologies and emerging-tech cybersecurity at PostQuantum.com.