SpinControl: Control Software for Prototyping and Benchmarking of Spin-Qubit Devices and Measurement Protocols

AI summary

Overview

Research area: Quantum computing software engineering — experiment control software for semiconductor spin-qubit systems (quantum physics / control systems).

Technical level: Intermediate. Readers need some familiarity with quantum computing terminology (qubits, gates, circuits, readout, calibration) and basic software architecture concepts (modularity, components, continuous integration), but the paper is descriptive rather than mathematical.

Scope (one sentence): The paper presents the software design and architecture of SpinControl, a Python library for controlling, tuning, calibrating and benchmarking spin-qubit devices and measurement protocols, and compares it feature-by-feature against other control software packages.

What This Paper Is About

Operating a semiconductor spin-qubit system requires tuning, calibrating, benchmarking and running algorithms, and these activities demand very different levels of access: experimentalists need low-level control for prototyping devices and measurement protocols, while algorithm researchers want to submit circuits at a high level. Control software therefore has to be customizable, modular and robust at the same time, and this is hard to achieve as circuits, calibration routines and benchmarking suites grow in complexity. The paper describes how SpinControl is structured to meet those three goals simultaneously, and positions it against existing options such as Boulder Opal, EDGE, qblox-scheduler, LabOne Q, QUA, spinQICK, Juice + Quantify, and the Delft stack of core-tools, pulse-lib and QConstruct.

Key Contributions

1. An architecture explicitly mapped to three design metrics. The authors state that customizability is obtained by separating data from behaviour, modularity and extensibility by splitting functionality into distinct components, and robustness by CI pipelines (unit, integration and system tests, type-checking, linting) plus runtime input validation.

2. A five-package Python structure with layered and modular internals. SpinControl is divided into low-level-software, analysis, lls-experiments, llscfg and utils, and the low-level-software package is in turn split into Instrumentation, Compilation, Execution, Calibration, Cloud connection, Storage/data/GUI, and Orchestration components.

3. Spin-specific functionality integrated into a general control stack. This includes virtual gate matrices (a voltage on a virtual port maps to voltages on multiple real ports), a port-to-channel mapping via PortInstrument, per-qubit implementations for initialization and readout of arbitrary-length linear arrays of spin qubits, MeasurementStrategy subclasses for parity-aligned readout, tomography readout and dynamic thresholding, and a large catalogue of standardized spin experiments in Table II.

4. A node-based experiment and calibration framework plus cloud connectivity. LlsExperiment provides template methods for configuring, measuring, analysing and plotting; the node framework (CalibrationNode, CheckNode, BenchmarkNode, SequenceNode, NodeMaintainer, MaintenanceState, Action, ActionExecutor) supports prenodes and graph-like ordering, and the OnlineManager connects to a local component of the Quantum Inspire cloud platform to receive cQASM algorithms and return multi-qubit bitstring counts and fractions.

5. A feature comparison table against competing packages. Table I compares SpinControl with Boulder Opal, EDGE, qblox-scheduler, LabOne Q, QUA, spinQICK, Juice + Quantify, and core-tools + pulse-lib + QConstruct across instrument control, virtual gate matrices, device gate-channel mapping, pulse compilation, circuit compilation, pre-storage processing, standardized experiments, automated calibration, automated tuning and cloud algorithms.

Main Findings

• Separation of data and behaviour is the mechanism for customizability. The MeasurementManager façade receives input definitions (parameter names, value ranges, pulse or circuit programs), and the MeasurementBuilder turns them into Parameter objects retrieved from the InstrumentManager or constructed to set and get from a pulse program, so a generic Measurement class can execute them.

• The measurement types form an abstraction ladder. CqasmMeasurement forwards to QubitMeasurement, which forwards to CircuitMeasurement, which forwards to PulseMeasurement; all four ultimately execute a pulse program. Scan and AwgScan sit alongside these.

• Compilation is split into pulse level and circuit level. PulseCompiler wraps the open-source pulse-lib package and supports block pulses, ramps, custom pulses and acquisitions, configurable averaging and sample rate, and compensation for charging effects in the DC/RF combining circuit. CircuitCompiler wraps the closed-source QConstruct package and converts circuits into pulse programs, with per-qubit instruction implementations and a settings datastore copied into each experiment for reproducibility.

• Parametrization expands one program into many. A parametrized value (voltage or duration) is converted into a sequence of programs, and if multiple values are parametrized the sequence contains all combinations of values.

• cQASM from Quantum Inspire is supported end-to-end. The cQASM string is converted into a circuit program of QConstruct instructions; SpinControl shares its primitive gate set with Quantum Inspire at configuration time so that incoming cQASM only contains gates the device can execute natively.

• Data handling uses xarray Datasets written to disk during measurement. Datasets are written after each user-settable update interval, enabling live plotting and preventing data loss on abort or crash. Multiple Flow objects (sequences of Processor objects) can be supplied, producing multiple stored Datasets with different processing applied; each Flow has a trigger dimension so processing is not attempted on unfinished data.

• Every implemented instrument driver has a simulator counterpart, used in system tests and documentation notebooks, with several simulation styles (pre-recorded return values, qcodes pyvisa simulation files, or user-set simulated data).

• Calibration and execution are mutually excluded by a state machine. LlsStateMachine has an 'online'/'offline' dimension and a 'calibrating'/'executing'/'locked'/'waiting' dimension; the CalibrationManager ensures no calibration starts during a cloud job and vice versa.

• Outputs follow the quantify directory convention, organised by year, day and experiment-unique identifier, optionally including the dataset, an instrument-parameter snapshot, a copy of the datastore, the measurement input definition, and analysis/fit values with plots. The datastore is a JSON file backed up on each update.

• The comparison table places SpinControl as the only listed package with all compared features, while noting that the core-tools + pulse-lib + QConstruct stack also offers virtual gate matrices, hardware-agnostic operation, pulse and circuit compilation, and standardized circuits (non-spin-specific).

• No quantitative performance results are reported. The paper contains no qubit counts, fidelities, timing benchmarks, or measured speed-ups; its evidence is architectural description and the qualitative feature matrix of Table I.

Methodology in Plain English

The authors did not run a physics experiment. They designed a software system, documented its structure, and compared it against alternatives.

They started from the observation that two very different user groups must share one control stack: internal maintainers and experimentalists who need low-level instrument access to prototype devices and measurement protocols, and external users who want to send an algorithm to a cloud service and get results back. They responded with three stated design goals — customizability, modularity/extensibility, and robustness — and then assigned a concrete software mechanism to each: pass user-supplied functionality into a generic core (separating data from behaviour), split functionality into loosely coupled, highly cohesive components, and enforce correctness with CI pipelines and runtime input validation.

They then arranged the code as Python packages with an explicit dependency direction, built each component on existing open-source or in-house packages (qcodes for instrument drivers, pulse-lib for pulse compilation, core-tools for virtual gate matrices and GUIs, QConstruct for circuit compilation, xarray for datasets, quantify for the instrument monitor and output directory layout, qt-dataviewer for plotting), and added simulator counterparts for every instrument driver so tests could run without hardware. Finally they tabulated the resulting capabilities against other packages to show where SpinControl is distinctive.

Why This Matters

Impact on research. Spin-qubit experiments involve long chains of tuning, calibration and benchmarking that must be reproducible. SpinControl's contribution is to make those chains first-class software objects: experiments are composed from measurement and analysis building blocks, calibration is expressed as a maintainable node graph that can be re-run periodically and can suppress and log errors so execution continues, and measurement results are stored together with inputs, an instrument snapshot and analyses. Configuration and user scripts sit under version control, which the authors present as one of the two routes to measurement reproducibility.

Real-world applications (as implied by the paper's design):

• Cloud access to semiconductor spin-qubit hardware, via the Quantum Inspire connection that accepts cQASM strings and returns bitstring counts and fractions.
• Laboratory device bring-up and day-to-day maintenance, where automated calibration repairs the system after an out-of-spec calibration and check nodes perform small measurements rather than full calibrations.
• Prototyping new device layouts and new measurement protocols, since device configuration is a plug-in and user-supplied programs, processing flows and measurement strategies are passed into the core.
• Benchmarking qubit quality using the standardized spin experiments listed in Table II, such as AllXY, Rabi variants, T1/T2*/T2Hahn, flipping, tomography variants and randomized benchmarking variants.

Industry relevance. The paper's comparison table shows a fragmented tooling landscape: several vendors' packages are vendor-only or not spin-specific, spinQICK supports only one brand of RFSoC hardware, and the Delft stack is hardware-agnostic but not spin-specific in its circuits. SpinControl's modularity claim is that parts of it can be integrated into other stacks and vice versa, which matters for labs assembling heterogeneous instrument setups from multiple manufacturers and for providers offering spin-qubit cloud access alongside other modalities.

Future Directions

• Add more spin-specific functionality, which the authors name explicitly as maintaining flexibility for shuttling, dispersive gate readout, and automated tuning.
• Increase modularity further, both to make it easier to integrate parts of the library into other control software stacks and to integrate other libraries into SpinControl.
• Expand remote connectivity and instrument support — the paper states plans for additional remote connections and more instruments.
• Implement automated tuning nodes, which the node framework can support but for which no nodes are currently implemented.

Target Audience

Experimentalists and lab software engineers working with semiconductor spin qubits who need low-level instrument control with reproducible calibration and benchmarking; quantum software architects interested in how modularity, customizability and robustness can be traded off in a real control stack; and researchers or cloud-platform operators who want to compare SpinControl's feature set against Boulder Opal, EDGE, qblox-scheduler, LabOne Q, QUA, spinQICK, Juice + Quantify, or the core-tools/pulse-lib/QConstruct stack. Readers looking for quantitative performance data will not find it here, since the paper reports no measured figures.

Authors’ abstract

Quantum computers require software to control the states of the qubits. As the actions on qubits grow in complexity with circuit execution, calibration, and benchmarking, the complexity of the control software grows in tandem. Spin-qubit quantum computers are at a stage where experimentalists need low-level access for tuning and calibration, and quantum algorithm researchers want high-level circuit-level access. In this article, we present the software design of SpinControl. SpinControl integrates three architectural metrics: 1) customizability, to allow prototyping devices and measurement protocols, is achieved by separating data and behaviour; 2) modularity and extensibility are achieved by separating functionalities into different components; and 3) robustness, to reliably execute quantum circuits on many qubits, is achieved by CI pipelines and input validation. SpinControl allows different types of measurements while customizing the instruments used, the pulse or circuit program executed, and the data processing. It allows building standardized experiments from measurement and analysis building blocks and executing these for calibration in a custom and conditional order. SpinControl implements these functionalities alongside robust configuration and data management, a connection to the cloud, and calibration scheduling. Pulse and circuit compilation, virtual gate matrices, as well as spin-qubit-specific GUIs integrated by SpinControl, make heavy use of software packages developed by Delft University of Technology: pulse lib, core-tools (both open source), and QConstruct