Choosing a Quantum Control System: What Actually Drives the Qubits

Introduction

In July 2025, Keysight shipped a rack of electronics to the AIST G-QuAT center in Tsukuba, Japan. It was, at the time, the largest commercial quantum control system ever delivered, specified to drive more than 1,000 superconducting qubits. The quantum processor it serves gets the headlines. The rack of electronics does not. Yet without that rack, the processor is what one of my colleagues likes to call an extraordinarily expensive refrigerator.

Every article in this series so far has dealt with hardware you can see and weigh. The cryostat is three-quarters of a metric ton of metal. The QPU is a chip you can hold. The wiring is a tangible bundle of coax or flex. The control system is the layer that turns all of that cold, inert hardware into something that computes. It generates the pulses that manipulate qubits, captures the faint signals that reveal their states, and closes the feedback loop fast enough to keep up with the qubits’ merciless clock.

For a procurement decision-maker, the control system is the component most likely to be underestimated and the one most likely to slip a schedule. The QPU vendor quotes a delivery date and usually hits it. The cryostat vendor quotes a lead time and usually hits it. The control electronics depend on a global FPGA supply chain that does not care about your quantum computer, and that single fact reshapes the procurement calendar more than any other line item in the build. This article covers what a control system does, which vendors sell one, how the choice changes across the five modalities, and the decisions a buyer has to get right.

What a control system has to do

Strip away the vendor language and a control system performs three functions: it generates signals, it acquires signals, and it processes them in real time. Each one is harder than it sounds.

Signal generation means producing the analog waveforms that physically drive a quantum operation. For a superconducting transmon, a single-qubit gate is a microwave pulse at 4 to 8 GHz, shaped to roughly 20 nanoseconds, with amplitude and phase calibrated to the specific qubit. The pulse shape is not cosmetic. A sloppy envelope drives unwanted transitions and leaks population into states the algorithm never intended to touch. A pulse that lands a nanosecond early corrupts the gate. Multiply that across hundreds of qubits, each with its own calibrated parameters, each drifting as the system ages between calibrations, and the generation problem becomes an exercise in disciplined bookkeeping at nanosecond resolution.

Signal acquisition is the reverse path. Reading a superconducting qubit means probing a coupled resonator and discriminating its state from a reflected microwave signal so weak it has to pass through a chain of near-quantum-limited amplifiers before the control electronics can digitize it. The electronics apply weighted integration, decide between zero and one, and do it within microseconds. Readout fidelity sets a hard ceiling on everything above it. If the control system cannot reliably tell zero from one, no amount of error correction higher in the stack recovers the information.

Real-time processing is the function that has moved from useful to mandatory. Mid-circuit measurement and quantum error correction both require the system to measure a qubit, interpret the result, and act on it before the qubit decoheres. For superconducting qubits with coherence times in the low hundreds of microseconds, that feedback loop has to close in single-digit microseconds. General-purpose CPUs cannot guarantee latency that tight. This is why every serious control platform is built on FPGAs, and increasingly on custom silicon: deterministic timing is the whole game.

These three functions are straightforward to describe and fiendishly hard to execute at scale. A five-qubit system needs five drive channels, five readout channels, and a handful of flux lines, all running from one control chassis. The engineering is manageable. A 100-qubit system needs hundreds of precisely synchronized channels spread across multiple chassis, and the integration problems multiply in ways that are not linear. Crosstalk between adjacent channels can drive parasitic transitions on unintended qubits. Reference clock distribution across racks introduces phase drift that compounds across a circuit. Ground loops between the control electronics and the cryostat inject low-frequency noise that erodes T1. The IQM team at LRZ documented 250 days of operational telemetry in arXiv:2509.12949, and a substantial fraction of their integration effort was debugging exactly these kinds of control-system-to-cryostat interface problems: impedance mismatches found during VNA sweeps after cooldown, unexpected resonances in cable runs, and the iterative cycle of characterize-adjust-re-cool that consumes weeks when it goes wrong. None of these problems are fundamental physics. All of them are the reason a multi-vendor quantum computer needs someone who commands the interface engineering between the control rack and the fridge.

Where the control system ends and the OS begins

One distinction is worth drawing clearly before going further, because the industry routinely blurs it and the blur causes muddled procurement thinking.

A control system operates at the physical layer. It deals in volts, gigahertz, and nanoseconds. Its job is to faithfully execute the lowest-level instructions that move a qubit. A quantum operating system operates at the system-software layer. It deals in resource allocation, job scheduling, compilation, and hardware abstraction. The control system is closer to a network interface card; the OS is closer to the network operating system that decides what traffic goes where. Both are essential. They are not the same procurement, the same vendor, or the same engineering discipline, and the next article in this series treats the OS and orchestration layer on its own terms.

The boundary is real even though some products straddle it. Quantum Machines’ platform pairs control hardware with the QUA language, which carries scheduling and real-time decision logic that has an operating-system flavor. Zurich Instruments’ LabOne Q sits a programming abstraction above the hardware. That overlap is a commercial design choice, not evidence that the layers are interchangeable. For a buyer, the practical point is this: choosing a control system and assembling an orchestration stack are two separate decisions, and a vendor that does one well has not necessarily solved the other.

The superconducting control market: four vendors, four philosophies

For superconducting qubits, the commercial control market has consolidated around four companies. They are genuine alternatives, not interchangeable boxes, and the differences matter for a build.

Qblox, based in Delft, is the control vendor in the Q-PAC reference deployment and a co-creator of the Quantum Utility Block reference architecture alongside QuantWare and Q-CTRL. Its Cluster platform is a modular 19-inch rack system with swappable QCM, QRM, and QTM modules that cover drive, readout, and timing functions. The architecture uses a deterministic SYNQ synchronization bus across modules and a Q1ASM sequence processor on each module’s FPGA. Qblox adopted NVIDIA’s cudaq-realtime API in March 2026, making the Cluster NVQLink-native, and the same month demonstrated real-time QEC integration with Riverlane’s Deltaflow decoder. The DOE’s Fermilab selected Qblox as the manufacture-and-distribute platform for the QICK open-control ecosystem, which gives the hardware a foothold in the U.S. national laboratory network. For a buyer building on the QUB blueprint, Qblox is the pre-validated choice; for a buyer outside the QUB combination, it competes on modularity, the Riverlane QEC path, and a growing North American support presence.

Quantum Machines, based in Tel Aviv, is the most widely deployed. Its OPX line is built around a Pulse Processing Unit, an FPGA architecture that synthesizes pulses in real time from parametric descriptions rather than replaying stored waveforms from memory. The practical consequence is adaptive, feedback-driven sequences without a round trip to a host computer, which is exactly what error correction protocols need. The QUA programming language gives pulse-level control without requiring the user to be an FPGA engineer. The playbook lists conditional-feedback latency at 224 nanoseconds, and the OPX1000 platform is built to scale past 1,000 qubits using mixed low-frequency and microwave front-end modules. Quantum Machines also acquired the Danish cryogenic-electronics firm QDevil, which adds ultra-low-noise DACs and cryogenic filters to its catalog. More than 200 deployments, including a pre-integrated QPU-plus-control package with QuantWare, make it the default choice for a large share of new builds.

Zurich Instruments, now part of the Rohde & Schwarz group, takes a test-and-measurement approach. Its Quantum Computing Control System is a family of purpose-built instruments: the SHFQC+ qubit controller, the SHFQA analyzer, the HDAWG flux generator, and the PQSC synchronizer that ties multiple units into a star network. The design priority is analog signal quality. A double-superheterodyne frequency-conversion scheme sidesteps the IQ-mixer calibration headaches that complicate competing systems, and the signal-to-noise figures are among the best on the market. That advantage compounds as qubit coherence times improve and the control electronics, rather than the qubit, become the limiting factor in gate fidelity. The SHFQC+ handles 6 qubits per box with 350-nanosecond feedback and scales to 108 qubits through the PQSC. IQM’s Constellation systems default to Zurich Instruments, and the new ZQCS variant adds explicit support for long-lived logical qubits.

Keysight entered later and moved fast, drawing on decades of RF test-and-measurement heritage. Its PXI-based Quantum Control System drives the Fujitsu-RIKEN 256-qubit machine, and the July 2025 AIST delivery was the first commercial control system specified beyond 1,000 superconducting qubits. Keysight’s distinguishing feature is the surrounding engineering ecosystem: chip-design EDA tools, electromagnetic simulation, and system-level analysis software. For an organization building a quantum computer from the chip up rather than buying a QPU off a catalog, that design-to-control continuity has real value.

Below these four sit other options worth knowing. Keysight aside, the playbook flags Tabor Electronics as a cost-competitive AWG source, SDT in Korea as an emerging player that showed a 20-qubit control system with NVQLink integration at GTC 2026, and LBNL’s QubiC as an open-source RFSoC platform. IBM and Google build their own control electronics and do not sell them. None of that changes the basic procurement reality: for a Western superconducting build sourcing components on the open market, the realistic shortlist is Qblox, Quantum Machines, Zurich Instruments, and Keysight.

One integration reality is worth being direct about. Buying a control system from one vendor and a QPU from another is the QOA premise, and it works, but it is not plug-and-play. There is no universal protocol between a control chassis and a QPU sample holder. Cable runs, trigger timing, reference clock distribution, and synchronization semantics all have to be negotiated at the project level. The Q-PAC deployment used QuantWare QPUs with Qblox control electronics, and while the five-month timeline proves the integration is bounded, it required engineers who understood both sides of the interface. The Quantum Utility Block reference architecture, the QuantWare-Q-CTRL-Qblox joint design, exists precisely to pre-validate these interfaces so a buyer does not have to rediscover them from scratch. For any combination outside the QUB blueprint, budget integration engineering time explicitly.

Latency and scaling figures are from Applied Quantum’s Systems Integration Playbook v3.0 and vendor disclosures as of May 2026. They describe different things measured in different ways and should be confirmed against current vendor specifications at procurement time, not treated as a direct head-to-head ranking. The table covers control-system hardware; the firmware-level pulse-optimization layer (Q-CTRL Boulder Opal, QuantrolOx) is a separate procurement, discussed below.

The constraint that reshapes the schedule: FPGA allocation

Here is the single most important procurement fact in this article. Every major control platform, and every real-time decoder that works alongside it, depends on AMD/Xilinx or Intel/Altera RFSoC FPGAs. Those same chips are in demand from defense, telecom, and AI hardware builders, and the quantum industry is a small customer competing against very large ones.

The result is that control-electronics lead time is frequently set by FPGA allocation, not by the control vendor’s own production capacity. The playbook is blunt about the consequence: pre-qualify the FPGA SKU allocation with your control vendor before you place the order, get the delivery timeline in writing, and if allocation stretches past 16 weeks, hedge with a second vendor rather than letting the whole build wait.

This inverts the intuition most buyers bring from classical IT procurement, where the compute is the fast part and the facility is the slow part. In a quantum build, the cryostat lead time is long but predictable. The control electronics can be the genuine wildcard. A program manager who treats the control system as a late-stage, low-risk purchase is the program manager who discovers in month four that first qubit signal has slipped to month nine. Order the control electronics early, in parallel with the cryostat and the QPU, and confirm the FPGA position in writing before treating the date as real.

Control by modality: the same job, different physics

A control system built for superconducting qubits does not transfer to trapped ions or neutral atoms. The three core functions stay the same; the physics underneath them changes completely, and so does the vendor picture.

Trapped-ion control has a different culture from the superconducting world. Where superconducting labs standardized on commercial systems, the ion community built its own, and the de facto standard is open source. ARTIQ, developed by M-Labs with NIST’s ion-storage group, is a Python-based environment that compiles experiment code onto FPGA hardware with nanosecond timing resolution. It pairs with the Sinara open-hardware ecosystem, more than 50 modular boards under the CERN Open Hardware License. The combination runs dozens of ion labs worldwide. The reason ARTIQ dominates is not just cultural preference. Trapped-ion control sequences involve complex conditional logic that generic AWG-based systems do not handle natively: which ion to shuttle to which gate zone, which measurement outcome determines the next laser pulse, how to interleave cooling and gate operations across a QCCD architecture with eight parallel zones. ARTIQ was designed from the ground up for exactly this feedback-intensive workflow. Commercial ion companies such as Quantinuum and IonQ build proprietary control stacks, but ARTIQ remains the community’s center of gravity and a common choice for early hardware bring-up. For a buyer, the trapped-ion build shifts the control question from “which of four vendors” to “commercial stack or ARTIQ-derived,” a materially different decision with different staffing implications: ARTIQ gives you flexibility and community support but requires in-house FPGA and Python expertise to maintain, while a commercial stack trades that flexibility for vendor-managed support.

Neutral-atom control is optical rather than electronic. The qubits are atoms held in optical tweezers, and the control system manages lasers: spatial light modulators and acousto-optic deflectors that arrange atoms into arrays, tuned lasers that drive transitions including the Rydberg states behind two-qubit gates, and cameras that read atomic states by fluorescence. Pasqal’s Pulser, open source under Apache 2.0, is the leading framework, designed at the pulse level because neutral-atom systems run in both digital and analog modes. The timing tolerances are looser than for superconducting qubits, since atomic coherence can exceed a second, but the spatial bookkeeping is harder: the system tracks the positions and states of hundreds of individual atoms at once.

Photonic control is different again. There are no qubit-driving microwave pulses to shape. The control system manages photon generation, routing through programmable interferometers, interferometric phase stabilization, and the classical feed-forward logic that measurement-based architectures require. It is optical systems engineering more than RF engineering, which is one reason photonic companies build their control infrastructure in-house rather than buying it.

Silicon-spin control overlaps most with superconducting: a mix of microwave pulses for spin manipulation and low-frequency voltages for tuning the quantum dots, all at millikelvin temperatures. Silicon-spin groups have adopted commercial systems from both Quantum Machines and Zurich Instruments. Diraq has specifically credited the OPX platform’s real-time capability for enabling its adaptive tuning work. For a silicon-spin build, the control choice looks much like the superconducting one, with the added consideration of cryogenic co-integration discussed below.

The firmware layer: making pulses error-resistant

One layer sits between the control hardware and the circuit: firmware-level pulse optimization. The control system generates a pulse, but the question of what pulse shape best resists the noise environment of a specific cryostat, on a specific chip, at a specific calibration point is its own discipline. The default pulse shapes shipped with control hardware are generic Gaussian or DRAG envelopes designed to work adequately across a wide range of systems. A pulse optimized for the actual noise profile of a specific QPU can cut error rates substantially, and the improvement is not theoretical.

Q-CTRL’s Boulder Opal is the most visible commercial product here. It designs control pulses that are inherently resistant to amplitude fluctuations and other noise, and the gains are measurable rather than theoretical. In a published application note, Boulder Opal pulses deployed on QuEra’s Aquila neutral-atom hardware via Amazon Braket improved the preparation fidelity of a Z2 antiferromagnetic state by a factor of three over a standard benchmark pulse, clearing 70 percent probability on the target bitstring. The point for a buyer is that the control system and the pulse-optimization layer are separable choices. The hardware vendor sells the rack; the firmware optimization can come from a specialist. A build that specifies one should consciously decide about the other rather than assuming the hardware vendor’s default pulses are the best the hardware can do.

The horizon: control electronics move into the cold

Every control architecture described so far places the electronics at room temperature, connected to the qubits through a long, lossy, heat-leaking chain of cables. That chain is the wiring wall this series has discussed in the cryogenics and superconducting articles, and it is the reason a 1,000-qubit superconducting system needs thousands of individual cryogenic connections. The problem is not just physical space. Every signal crosses a temperature gradient from 300 K to 10 mK. Every cable segment, every attenuator, every connector in that chain is a potential source of impedance mismatch, thermal noise, and signal degradation. The superconducting article’s drive-line table shows 62 dB of staged attenuation across five temperature stages. That is the cost of keeping room-temperature electronics away from millikelvin qubits, and it is why eliminating the distance between controller and qubit is not a convenience but an architectural necessity at scale.

Cryo-CMOS is the engineering answer, and it is moving from research toward product. The idea is to place control electronics inside the cryostat, close to the qubits, eliminating most of the room-temperature-to-millikelvin cabling. Intel’s Horse Ridge II is a 22-nanometer cryogenic controller operating at 3 K, demonstrated driving up to 128 qubits through 4 RF channels using frequency-division multiplexing. Intel’s Pando Tree program targets the millikelvin stage directly. SEEQC is building single-flux-quantum digital control at 4 K and reported gate fidelities above 99.9% in December 2025. A QuTech group demonstrated co-integrated CMOS control for diamond NV centers in February 2026 with no observable fidelity loss.

None of this displaces the room-temperature rack before roughly 2028. But the direction is clear, and it is the strongest reason a buyer planning past 1,000 qubits should treat today’s control architecture as a stage rather than a destination. Silicon spin has a structural advantage in this race, since its qubits already tolerate operating temperatures near 1 K, where cryo-CMOS is far easier to integrate than at the 10 to 20 millikelvin a transmon demands.

What a buyer should take away

The control system deserves more procurement attention than it usually gets, and the reasoning is concrete rather than abstract.

For a superconducting build, the realistic shortlist is four vendors. Quantum Machines if real-time feedback and the widest deployment base are the priorities. Zurich Instruments if analog signal purity matters most, or if the QPU is from IQM. Keysight if the organization is building from the chip up and values the surrounding design ecosystem. All three support NVQLink, which the HPC integration article covers as the GPU-coupling path; specify that compatibility in the purchase regardless of which vendor wins.

For any other modality, the question changes shape. Trapped-ion builds choose between a commercial stack and the open-source ARTIQ ecosystem. Neutral-atom and photonic builds will largely take the control infrastructure their QPU vendor provides, since those systems are not yet assembled from independently sourced control components.

Whatever the modality, place the control-electronics order early and confirm the FPGA allocation in writing. The control system is not the component that makes the headline qubit count. It is the component that decides whether the headline qubit count ever computes anything, and on current supply-chain conditions it is the line item most likely to move your first-qubit-signal date. Treat it accordingly.

For the deeper engineering picture, including signal-chain specifications, calibration parameter detail, and the vendor-by-vendor technical comparison, my full deep dive on quantum control systems goes well past what a build guide needs to cover.