Closing the Quantum Feedback Loop, Your Way: Qblox and AMD Open the Quantum Feedback Loop to Any Accelerator
.png)
Fault tolerance has moved the bottleneck. To keep a logical qubit alive, a quantum computer must measure, decode and correct inside the coherence window, round after round. The classical loop around the QPU now sets the pace as much as the qubits do. And that loop is a hybrid computing problem: decoders already exist for FPGAs, CPUs and GPUs, and where the best one will run is still an open question for the field.
AMD and Qblox are connecting quantum control directly to classical accelerators. Measurement data from the Qblox control stack now lands in the memory of AMD Instinct GPUs, AMD EPYC™ CPUs and AMD Versal adaptive SoCs, with no host software in the path. On top of that link sits an open, vendor-neutral runtime: the code that answers a measurement can be written in Python, C or OpenMP, and run on whichever processor suits it best.
This is an engineering result from a joint AMD and Qblox team, built on open interfaces, so that researchers and system builders can choose their accelerator and their programming model instead of inheriting one.
Key takeaways
- A direct path from control to compute. An AMD Alveo™ V80 Compute Accelerator writes measurement data straight into accelerator memory and reads the reply back. The link itself adds about half a microsecond; full link-card to device round trips measured 1.8 to 3.7 µs across five AMD processors.
- Any accelerator on the loop. The same link card image serves GPUs, CPUs and adaptive SoCs unchanged. Decoders returned bit-identical results on all of them.
- Your code, your programming model. The runtime is a library, not a framework. Python, C, OpenMP regions and chains of GPU kernels all serve the loop side by side.
- Open by design. Qblox software is open source down to the Q1ASM instruction level, the instruction set of the Q1 processor; AMD builds on ROCm, LLVM and open interconnect standards.
Speed or freedom is a false choice
There is more than one way to build a fast feedback loop. One is to standardize the whole loop on a single ecosystem: one interface, one accelerator family, one programming framework. That can work well. But it ties your roadmap to someone else’s, and it holds every task to the same spec, from real-time decoding to routine telemetry, whether the task needs it or not.
At Qblox, we connect to the ecosystems our customers choose, single-vendor platforms included. What we believe is that choosing one should never be a requirement.
That is the shift we are building toward. Every task runs on the device that suits it best. Interfaces are open, and components work together across vendors. Nobody yet knows for certain where decoders will run best in the long term. An open architecture lets you follow the answer as the field finds it, instead of waiting for a single roadmap to catch up.
One loop, two boundaries, two companies
The feedback loop crosses two boundaries.
- The first runs inside the control stack, where Qblox Q1 sequence processors share measurement outcomes between control modules over LINQ.
- The second runs between the control stack and the classical compute that decodes errors.
This work closes the second one: syndrome data out to an accelerator, the correction back, fast and predictably.
Qblox and AMD divided the loop along their strengths: control on one side, compute on the other.
AMD supplies everything past the control stack: the AMD Alveo™ V80 card, Versal adaptive SoCs, Instinct GPUs and EPYC™ CPUs, plus the open ROCm software stack. That portfolio lets each part of the loop run where it runs best, from fixed-latency logic to large-scale GPU compute.
Qblox supplies the control stack. The Qblox Cluster is a 19-inch rack of up to 80 control and readout channels, from DC to 18.5 GHz, with up to 120 Q1 sequence processors running the experiment in real time. Two proprietary backplane protocols hold the system together: SYNQ for deterministic synchronization with picosecond-level jitter, and LINQ for low-latency, high-throughput feedback.
Interconnects are a solved problem. Composability wasn't.
Moving data from an FPGA straight into accelerator memory is a proven HPC technique, used for years. That gives quantum computing a proven foundation.
That is where this integration begins. The control system connects over Aurora 64B/66B, a lightweight, lossless serial link, to an AMD Alveo™ V80 card. The card writes each request directly into a queue in the accelerator’s memory over PCIe. The accelerator writes its reply into the card’s memory. No host software touches a frame.
The devices meet at a contract in memory rather than a host software stack: a fixed layout of bytes and rules for when they may be read and written. Anything that follows that contract can join the loop, whether it is a GPU kernel, a CPU thread or a block of programmable logic. Measurement payloads are only a few bytes, they travel together with the “data ready” signal, saving a full round trip on every exchange.
A runtime that goes where your code already runs
Qblox control, AMD compute: the results
The team tested the path end to end, timing every round trip from request to computed reply. Qblox generated real LINQ frames, the same frames that carry measurement data across the Qblox feedback network, and sent them over the link into AMD processors. Each frame carried a function ID in its header, and the CPU or GPU read that ID and ran the matching function rather than simply looping the data back.
- 4.05 µs median round trip to an AMD Instinct MI210 GPU.
- 2.70 µs median round trip to a single AMD EPYC™ CPU core.
- 90% of CPU replies landed within a 0.184 µs window.
- 10,000 out, 10,000 back in every run, with no drops and no stray responses.
Larger frames cost time steadily and predictably. The team swept frame size from 64 to 2,048 bytes in 8-byte steps, 2,000 frames per size, and the median grew by about 1.35 ns per byte. Error-correction syndromes are only a few bytes, so they sit at the fast end of this range; the headroom serves larger payloads such as calibration or telemetry data.
Versatile by design: any accelerator, unchanged
Where a decoder should run is still an open question for the field. Decoders exist for FPGAs, CPUs and GPUs, and the right answer depends on the code, the qubit count and the modality. So the integration does not pick a winner.
Three swap tests show the layers are truly independent:
- Change the link, keep the consumer. The GPU code never knows which physical link delivered a frame. Aurora can be replaced by another serial protocol that delivers whole frames losslessly and in order.
- Change the consumer, keep the producer. Moving the loop from a GPU to a CPU, or to a Versal adaptive SoC, required no change to the card’s logic, image, driver or interface.
- Change the programming model, keep both ends. The same decoder in Python, C or OpenMP gives identical answers.
Small error-correction decoders for the Steane-7 and repetition-3 codes returned logical errors equal to the reference decoder, with bit-identical replies from the GPUs, the CPUs and the V80.
More than error correction
Decoding is the most demanding job on the loop. The same path serves any task where a measurement has to shape what the quantum computer does next:
- Calibration: tracking drift in qubit parameters and updating control pulses while experiments run.
- Adaptive circuits: choosing the next operations based on mid-circuit measurement results.
- Active reset and conditional logic: acting on a qubit’s state within the same run.
- Hybrid algorithms: running classical steps close to the qubits instead of round-tripping through a host.
The further a task is from decoding, the more its code looks like ordinary software, with familiar languages and standard math libraries. That is exactly what the runtime is built to host. In our tests, a numerical function of the kind a calibration step uses ran on an AMD Instinct GPU and matched the host’s results on all 3 million replies.
There is still work ahead. Some ways of plugging code in currently add a few microseconds compared with the fastest path, and we are sharing those numbers openly while the team optimizes them.
What comes next
The current integration connects devices in pairs. The next step is a mesh: several control endpoints, several accelerators and programmable logic in between. In parallel, the joint teams are optimizing the FPGA-to-FPGA serial fabric inside the Qblox stack and exploring a quantum-optimized path for multi-rack systems, so the same direct-to-accelerator model can scale across racks.
Built on open standards
Both companies treat openness as a requirement, not a feature.
AMD builds on the open ROCm software stack and LLVM, is a founding member of the Ultra Ethernet Consortium, and backs UALink as an open scale-up interconnect.
Qblox software is open source from the qblox-instruments driver and Q1ASM up to the Qblox Scheduler, and its control electronics run in multi-vendor systems alongside independently sourced chips, software and cryogenics.
Put the two ends together and the choice belongs to the system builder: adopt the whole stack, part of it, or only the piece you need. Whoever builds a quantum computer should own its architecture.
What this means for you
Running an HPC center or building quantum systems? Write open interfaces into your next procurement. Keep your accelerator strategy. Take the single-supplier dependency out of the most latency-critical part of your machine.
Writing the software? Use the language you already know. Run it on the device that fits. Move it when a better device comes along.
Get involved
System integrators, HPC centers, accelerator vendors and decoder builders: endorse the principles and build with Qblox and AMD.
The integration is available to early-access partners. To run real-time decoding on AMD accelerators with Qblox control contact QuantumComputing@amd.com or sales@qblox.com.
For the full technical detail, including the runtime design and every measurement, read the companion deep dive: Closing the Quantum Feedback Loop with a Composable Runtime.
Frequently asked questions
Why does measurement data bypass the host on its way to the accelerator?
Host software adds unpredictable latency that eats into the qubit coherence window. In the Qblox and AMD integration, the link card writes each request straight into accelerator memory over PCIe, and no host software touches a frame. When the team froze the host process mid-run, the GPU kept answering without a failure.
What is real-time quantum error correction?
Real-time quantum error correction measures qubit states, decodes the error syndromes and feeds the correction back to the control system, all within the qubit coherence window. It needs deterministic, low-latency classical feedback between readout, decoding and control hardware.
What are Qblox LINQ and SYNQ?
LINQ and SYNQ are backplane protocols in the Qblox Cluster. SYNQ synchronizes all channels with picosecond-level jitter. LINQ delivers low-latency, high-throughput feedback with arbitrary control flow, so measurement outcomes can steer control decisions in real time. In the AMD tests, real LINQ frames carried the measurement data to AMD processors.
Why are FPGAs used for quantum control?
FPGAs provide deterministic, nanosecond-scale processing at the interface with quantum hardware. Unlike CPUs or GPUs, they execute control and readout logic with fixed, predictable latency, which is essential for feedback that must complete within a qubit coherence window. In the Qblox and AMD integration, FPGAs sit at both ends of the link: in the Qblox control modules and on the AMD Alveo™ link card.
What is the Qblox Q1 sequence processor?
Q1 is Qblox’s own sequence processor, running on the FPGA in every Qblox control module. It executes Q1ASM programs with deterministic, nanosecond-scale timing, the fixed and predictable latency that feedback within a qubit coherence window requires. A Qblox Cluster runs up to 120 Q1 sequence processors in parallel. In the Qblox and AMD integration, Q1 runs the experiment on the control side, and an AMD Alveo™ V80 card carries the measurement data to AMD compute.
Which qubit platforms does the Qblox control stack support?
The Qblox Cluster operates from DC to 18.5 GHz, covering superconducting qubits, spin qubits and quantum dots, and NV centers from a single vendor-neutral stack.
Which AMD processors work with Qblox control?
AMD Instinct GPUs, AMD EPYC™ CPUs and AMD Versal adaptive SoCs. The same link card image serves all of them without changes. Small decoders for the Steane-7 and repetition-3 codes gave bit-identical replies on each.
How fast is the quantum feedback loop with AMD accelerators?
With a Qblox Cluster on the loop, median round trips were 4.05 µs to an AMD Instinct MI210 GPU and 2.70 µs to a single AMD EPYC™ CPU core. Every run sent 10,000 frames and got 10,000 computed replies back, with no drops.
Which programming languages does the runtime support?
Python, C and OpenMP. The runtime is a library, not a framework, so a function moves between an AMD GPU and CPU by naming another device instead of being rewritten.
How can I get access?
The integration is available to early-access partners. Contact QuantumComputing@amd.com or sales@qblox.com.
