But what is a Quantum Control System?

In my job at Zurich Instruments, I’m busy most days building software for a quantum control system (QCS). And even though that’s something very tangible for me, it’s often difficult to explain to folks outside of the field, and sometimes I struggle to describe precisely to other physicists what a QCS is or does.

So first, for a working definition we use internally: A QCS is a system used in building quantum computers, specifically concerned with controlling the individual qubits. Each qubit is a discrete physical system typically exhibiting two energy states, and by coupling them to each other, quantum computations can be executed on the quantum computer. How specifically that works is beyond this discussion (and also beyond me, if I’m honest). Oftentimes, the chip (if it is a chip) containing qubits is called the QPU, or Quantum Processing Unit, in analogy to the CPU or GPU. But as I will describe further down, this term is not quite clear and can be used in a different way. Also note that despite having an education in physics, I’m working on the QCS software – I have many extremely competent colleagues with PhDs in quantum computing who are much better able to explain the finer aspects of quantum computing.

Qubits

There are many different types of qubit, as there are many ways of realizing the basic two-level system in physics. Today, the most prominent ones being researched are superconducting, ion-trap, electron spin, and neutral atom qubits. Zurich Instruments is specialized in superconducting qubits, as these different technologies have differing requirements in terms of how you control the individual qubits. One way of imagining the qubits, especially if you already have some background knowledge in physics, is as artificial atoms: just like atoms, qubits have these discrete energy states, but especially for qubits, we only care about two of them - often the lowest too, base state and first excited state.

Superconducting qubits, a very promising technology and a specialty of Zurich Instruments, are realized as discrete macro-scale electric circuits containing a superconducting path interrupted by a Josephson junction. The details are extremely complex – many PhDs have been done and are still being completed on the specifics – but at a high level you can imagine it as an LC-circuit (like from high school physics) with a certain non-linearity. The circuit becomes a quantum system when operating in one of its discrete energy states; this happens when it is excited into such states by applying microwave pulses to it, just like exciting an atom’s electron by interaction with a photon. The quantum nature is apparent once the qubit is not set up in either ground or excited states, but in a superposition between the two states. The Josephson junction in a superconducting qubit provides a non-linearity, meaning that (unlike in an harmonic oscillator), energy levels have different transition energies. This is crucial to be able to control the qubit just in the first two states, the “computational states”, and not enter any higher states.

After setting an initial quantum states, computations are executed by further playing certain pulses on the control and “flux” lines of the qubits. Qubits can be made to interact with each other, for example, through tunable couplers. Couplers and qubits can be “detuned”, i.e. have their basic resonance frequencies changed, by subjecting them to a magnetic field generated by a flux line.

On the other hand, after (or between) executing computations on the qubits, the qubit states must be read out occasionally, measuring their state. This is necessary both for determining a computation’s outcome, as well as doing advanced schemes like Quantum Error Correction (QEC), in which there is a complex protocol reading and setting qubit states to prevent loss of quantum information from the qubit system. Some qubit types like trapped ions use different technologies, like optical readout; but some shared principles exist.

Functionality

This leads to the main challenge and basic function of a QCS: play and measure

1. high-quality microwave pulses
2. with extremely accurate timing
3. on a large number of channels (100 - 10000, depending on the desired scale),
4. with real-time feedback between channels.

For superconducting qubits, the microwave frequency is typically in a range from 0 - 12 GHz, and in Zurich Instruments' QCS implementations, there are typically two channel types: low-frequency flux-type channels with a bandwidth of up to ~1 GHz for playing unmodulated pulses; and signal generator-type channels for generating modulated microwave pulses up to 12 GHz. The pulses typically have a duration of a few nanoseconds, and need to be phase-coherent with the qubit. The generated signals also must be very pure, as unwanted frequencies can excite the qubits into non-computational states.

The first two items on the list are solved by high-end electronics built by my supremely competent coworkers – this involves building custom PCBs incorporating cutting-edge chips based on a custom system architecture. Software is barely involved here, as the determinism and latency requirements are not achievable using custom software. Timing between pulses must be consistent over time down to hundreds of femtoseconds(!): this means that even slight temperature changes affecting the RF cabling will result in phase coherence being disturbed.

The third item must be solved both at the hardware and software level. Software is mostly used in the control plane here, doing asynchronous tasks down to a latency of milliseconds that prepare the electronics to execute experiments at its own speed. The last item is only partially solved by any QCS implementation today: it is required to, for example, measure a qubit state on one (ADC) channel, and deliver the result of the read-out measurement to a signal-generator (DAC) channel that may be located in a different part of the system, but def

Programming an Experiment

Typically, a quantum computing experiment is defined in one of many available domain-specific languages (DSL). Zurich Instrument’s is called LabOne Q and is based on Python, but others exist, including translation layers between them. The DSL is used to define the precise sequence of pulses across many channels, and translated into a more low-level description of the quantum experiment. This is typically a list of channel definitions, each channel coming with some waveform buffers, and programs in different representations. The programs are interesting as they define the experiment logic; advanced QCS have different kinds of processors in the FPGAs, CPUs, GPUs, etc. that are part of the system and define how experiments are played and measurements acquired. Within each such experiment, timing is typically deterministic or at least equipped with real-time bounds; the time scale is based on samples and measured in nanoseconds. These different “compute resources” will be important a bit further down.

As a scalable QCS is usually a distributed system by itself, software is used to distribute experiment definitions to the different channels. In the simplest case, this works over normal TCP/IP connections, as latency is not crucial; the software only needs to be able to reach high enough throughput to keep channels fed with experiments. However, individual experiments may also run for an extended period of time, further reducing even the throughput requirements put on the system software. This is helpful in further scaling the system, as each individual channel can be implemented with fewer resources.

Control Plane

With all its custom components, a QCS is a complex system made up of many hardware components connected by a more or less high-performance network that need to be assembled into a coherent system. This means there are many more conventional tasks that also need to play well with the final user experience, and many of them are quite similar to building a conventional cluster of commodity machines:

1. Recognizing and reporting available hardware modules, and changes to the hardware configuration
2. Building a centrally-controlled network with all the usual services: DHCP, DNS, NTP, boot images, etc.
3. Configuration, including notifying components of updates
4. Monitoring components both for errors and performance, as well as collecting logs
5. Internal and external communication and their associated APIs

We chose only a few off-the-shelf components and built many parts ourselves, mostly in C++, but with some key components in Rust. These ensure that you can just press one power button, and a heterogeneous system will be assembled every time it boots. Tight integration between different components ensures that - for example - a newly installed hardware module will automatically become part of the internal fabric and boot the correct firmware, and is immediately discovered by the monitoring infrastructure which will start collecting logs and metrics from it.

Definition

After all the talk about individual functionality of a QCS, I want to present our working definition of a QCS:

A QCS is a system made up of various compute resources (CPU, GPU, FPGA, ASIC, TPU) which are able to communicate with each other (with low or deterministic latencies) and on which real-time compute workloads can be scheduled; and which are connected to a quantum computing experiment through ADCs on the one side (converting analog RF inputs into digital samples) and DACs on the other (converting digital samples into analog RF signals).

We can also reconsider what “QPU” means in this case: For example, we might extend the definition to encompass both the qubit chip(s) as well as the control electronics. Now you can consider the “Logical QPU” consisting of error-corrected qubits and control electronics, exposing a useful interface to the outside world - analogous to a GPU, which consists of chips controlled by drivers and a whole toolchain. In a Logical QPU, GPUs might be used to implement part of the quantum computing algorithm, for example by running efficient signal processing algorithms.

This line of thought becomes even more interesting when considering integration of high-performance computing (HPC) infrastructure, for example to accelerate specific subproblems of a larger workload using quantum computing resources. This is a field of active investigation, though, so I won’t be able to discuss much more about it for now =)