Design-Time Conformance Checking for Pulse-Level Quantum Control

AI summary

Overview

• Research area: Quantum computing — specifically pulse-level quantum control, compiler/toolchain verification, and device capability description for superconducting qubit control stacks.
• Technical level: Advanced. The paper assumes familiarity with pulse-level programming (waveforms, envelopes, sequencers, digital synthesizers), compiler testing, and the QICK and Qblox control stacks.
• Scope (one sentence): The paper presents qconform, an offline, deterministic, exact-arithmetic checker that decides whether a pulse-level control program is realizable on a specific device using a versioned capability descriptor whose every constraint cites the toolchain observation that established it, and evaluates it by differential testing against the QICK and Qblox toolchains.

What This Paper Is About

Pulse-level quantum control programs are written against device limits that are not part of the programming interface: minimum pulse lengths, timing grids, frequency bands, amplitude resolution, and finite envelope memory appear only in vendor documentation, source code, or as failures at compile time or board load. Worse, a toolchain may accept a program and silently alter it — shortening a pulse, folding a frequency onto a Nyquist image, rounding a readout length — so the experiment runs and produces data that does not correspond to the program that was written.

The paper treats device limits as a contract: a versioned, machine-readable capability descriptor in which every constraint cites the survey observation that established it. A checker then decides each program against that descriptor before the program runs, reporting not only a verdict but also the rules it applied and a coverage manifest naming what it did not check.

Key Contributions

1. A capability descriptor format with citation-backed constraints. Every constraint in a descriptor carries an evidence list pointing into a survey catalog, and a gate script refuses any descriptor whose evidence does not resolve. Descriptors are pinned to a firmware configuration and a library version, because the survey showed that accept/reject behavior is a function of that pair.
2. A dependency-free checker in C99. qconform is 4488 lines of C99 with no dependencies; it reads a descriptor and a program as JSON, emits a JSON report, and uses exact rational arithmetic throughout — no floating point — with four exit codes (pass, fail, pass with repairs, tool error) and a coverage manifest that classifies all 26 coverage classes.
3. A differential evaluation against two vendor toolchains. The checker was tested against QICK and Qblox on four configurations (three QICK boards, one Qblox cluster), over 1263 program runs of 969 distinct programs — 665 on QICK and 304 on Qblox — with zero unsound passes.
4. A defects-and-fixes record. The evaluation plus a fault-injection study found ten defects in the checker and its descriptors (seven QICK, three Qblox), 18 in the harness (15 QICK, three Qblox), and five evidence defects, all fixed, along with a build-time tripwire requiring the checker to read every descriptor field the parser fills.

Main Findings

• No unsound passes on any configuration. Across testbench (127 programs), qce2025-r26 (681), rb-r27 (127), and qblox-qcm-qrm (328), the unsound count is 0 in every case. The checker accepted no program that a toolchain refuses.
• Silent repairs are the central hazard. On a full-speed QICK generator, a frequency past the digital synthesizer range is accepted and aliased with the register wrapping; a gain past full scale is accepted with the register exceeding what the hardware can represent; an envelope larger than channel memory compiles and fails only at board load. In a muxed generator's tone table, a tone one step below the lower band edge compiles and is folded onto its Nyquist image, about 860 MHz from the request, while the readback reports the requested frequency.
• Qblox has its own silent behaviors. A clock declared with an initial phase compiles but the sequencer starts at phase zero with no warning; an amplitude of exactly full scale is written as 32767 of 32768 because the register cannot hold +1; an amplitude below half a register step rounds to zero and the play instruction disappears from the program.
• The toolchain version pin is part of the soundness claim. On QICK, two releases (one older, one newer than the pin) give identical result rows byte for byte, but the two oldest do not: the oldest refuses the newer processor revision outright, and the next refuses any jump target past address 2047. Against the pinned descriptors, the oldest release gives 90, 2, and 90 unsound passes on the three configurations, and the next gives 2 on each.
• Qblox shows the same version dependence. The pin is the newest release, so all four others are older; the nearest reproduces the catalog and results byte for byte, but the three oldest refuse a wait shorter than 4 ns inside a program that the pin accepts, and two also compile the program at each instruction limit to one instruction over it — giving 10, 10, and 8 unsound passes against the pinned descriptor.
• Cost models hold exactly at the limits. The linear program-memory cost model holds at both QICK memory sizes: the program one element past the limit compiles to 4097 of 4096 words on testbench and 16385 of 16384 words on rb-r27. On Qblox the instruction cost model holds on both budgets: 16386 of 16384 instructions on the drive module and 12290 of 12288 on the readout module.
• Most disagreements are documented leniency, not error. The 91 vendor-lenient QICK rows are behaviors the descriptor documents; in 83 of them (an aliased or folded frequency, or a gain past full scale) only the raw register shows the change because the readback reports the requested value. A frequency just past the band reads back unchanged with a register of 2147483651, which has wrapped past 2^31. No Qblox row is lenient.
• A small conservative set. Eight rows (two QICK, six Qblox) are cases where the checker refuses and the vendor compiles, and every refusal points at a frequency or phase update that no later output uses.
• Corpus seed mattered for one class of defect. A corpus seed derived from a salted string hash meant that of 286 programs, 120 differed between two runs at the same seed — one of the five evidence defects. Over ten seeds the corpus grows to 486, 2564, and 486 distinct programs on the three QICK configurations and to 1024 on Qblox, with no seed producing an unsound pass, missed repair, over-predicted repair, or open row.
• Coverage is declared, not implied. Of the 26 rule classes, 23 are exercised. Two of the other three are unreachable by construction and one reports unchecked by definition; on Qblox the envelope sample grid is one sample on every channel, so that class can never reject and is reported as vacuous.
• Recurrent defect pattern: parsed but never enforced. Three times, a descriptor field was accepted by the checker and never enforced — notably the post_mixer flag, where the parser read the flag and the checker never consulted it, so it compared the requested frequency against an unshifted band and accepted four programs the toolchain refuses. The fix was a format change requiring a program to declare its channel's mixer. The Qblox instruction cost model similarly cited rows showing two instructions per output while the descriptor charged one, and passed a program over the instruction limit.

Methodology in Plain English

The author first surveyed each toolchain by black-box probing, with no hardware present. For QICK, the asm_v2 toolchain was driven from captured board configurations over 605 probes across three configurations, written as 45 catalog files; each probe varied one parameter around a limit the configuration implies and recorded whether the toolchain accepted unchanged, accepted and changed a value, refused with a typed error, or failed without naming a cause. The Qblox survey was done analogously: qblox-scheduler compiles a schedule to Q1ASM for a dummy cluster that qblox-instruments runs with no hardware, giving 193 probes over one configuration in 11 catalog files.

Those observations become the evidence entries of the capability descriptor. The descriptor names a device, lists channels, gives each channel a time base as an exact rational (chosen so both the channel clock cycle and the processor timing tick are whole multiples — on the QICK board studied, a 599.04 MHz fabric clock against a 430.08 MHz timing clock), and states constraints whose values are exact rationals in SI units.

The evaluation is differential testing: the vendor toolchain itself is the oracle. A harness lowers each generated program into a vendor program, compiles it with no hardware, and records the checker's verdict and the vendor outcome together, one row per program. The corpus is built from boundary ladders (far below, just below, exactly at, just above, far above each limit), budget ladders, spacing ladders, resolution and grid rungs including an odd multiple of the step, and randomized programs that compose several elements with values near the limits, probing one representative per channel class. Because both vendor interfaces take times and frequencies as doubles while the checker is exact, every conversion records the request, the value passed, and whether both fall in the same grid cell; rows where they do not are attributed to the harness and excluded from the soundness count. Triage then classifies every row into one of nine dispositions (agree, unsound, missed repair, over-predicted, vendor lenient, conservative, unobserved, harness, open), comparing repairs one quantity at a time. A separate fault-injection study planted 742 single-change defects in the descriptors and checker to see which survived the corpus.

Why This Matters

The paper moves a class of quantum-control bugs from "discovered when the data looks wrong" to "rejected before the program runs." Silent repairs are especially damaging because the resulting data is plausible — nothing in it says the pulse was shortened or the frequency folded — so experiments can be interpreted against a program that was never executed. Making device limits versioned, evidence-backed, and mechanically checkable also gives a concrete answer to the reproducibility problem that arises when a descriptor is pinned to one toolchain release and the lab upgrades.

Real-world applications:

• Pre-flight validation of pulse experiments on superconducting qubit control stacks, catching aliased frequencies, over-scale gains, and over-budget envelopes before board load.
• CI for quantum control code, since the checker is offline, deterministic, dependency-free C99 and needs only a C compiler and a POSIX shell, and neither differential harness needs hardware.
• Vendor toolchain regression testing and release notes, since the version-pin study shows exactly which behaviors change between releases on both QICK and Qblox.
• Device capability description for hardware-agnostic compilation, where a portable pulse representation must still be checked against the device it is lowered to.

Industry relevance: labs and vendors building or consuming pulse-level control stacks can adopt the descriptor format and result rows as an acceptance test. The paper is framed as a response to a measured gap — a rubric for control-plane openness has been applied to thirteen vendor stacks — and the artifact is released under Apache-2.0 so any implementation of the specification can be run against the corpus.

Future Directions

• Extending to other vendors and other input languages. The paper notes that QubiC and Qibolab are other open control stacks a descriptor could target, and that programs currently arrive in the qconform JSON format with only one exporter, from compiled QICK programs. A vendor whose compiler runs only against a live instrument cannot be tested this way.
• Testing the untested Qblox grid rules and static QICK readouts. The channel unit is one nanosecond and both grids are one unit, so only a program stated in half a unit can miss either grid — and a half-nanosecond value does not survive the vendor interface's double conversion exactly, so neither rule is tested against the toolchain. The harness also does not lower a capture on a static QICK readout, affecting one row of 681.
• Tightening the muxed-generator time rule and handling run-time behavior. The rule bounds a single pulse rather than accumulated program time, so it is exact for a pulse that starts the program and loose for one that starts later. Data-dependent control flow is out of scope because the program format has no branches or loops.
• Resolving the open unenforced fields. The build-time tripwire's first run found three more descriptor fields read by the parser but not by the checker, recorded as open, and the paper notes that a clean corpus does not prove no unsound program exists.

Target Audience

Quantum control engineers, compiler and tooling developers for quantum stacks, and experimentalists writing pulse-level programs on QICK, Qblox, or comparable hardware. It is also relevant to researchers working on device capability description and hardware-agnostic pulse representations, and to anyone doing differential or metamorphic testing of quantum software stacks — though readers without background in pulse-level control and compiler testing will find the middle sections demanding.

Authors’ abstract

A pulse-level quantum control program is written against a device whose limits are recorded, if at all, in vendor documentation and source code. A program that exceeds them can be refused at compile time. It can also be accepted and silently altered, or compile and then fail at the board. In the last two cases the experiment runs, and the data does not correspond to the program that was written. We present qconform, a checker that decides whether a pulse program is realizable on a device, given a versioned capability descriptor for that device. Every constraint in a descriptor cites the toolchain observation that established it. The checker is design-time, offline, and deterministic, and it uses no floating point. It reports a verdict, the rules it applied, and a coverage manifest that names what it did not check. We evaluate qconform by differential testing against the QICK and Qblox toolchains, on three QICK board configurations and one Qblox cluster. Over 1263 program runs of 969 distinct programs, the checker accepted no program that a toolchain refuses. On both vendors, a descriptor pinned to one toolchain release accepts programs that older releases refuse. The evaluation also found ten defects in the checker and its descriptors, all fixed.