OpenQASM 3: A broader and deeper quantum assembly language

TL;DR

OpenQASM 3 broadens quantum assembly language capabilities to integrate real-time classical control with quantum circuits, delivering a multi-level IR that spans logical circuit descriptions to physical pulse implementations. It introduces continuous gate parameterization, gate modifiers, non-unitary operations, and real-time classical computing, all within a framework designed to remain compatible with OpenQASM 2 while enabling richer hardware-aware descriptions. A key contribution is the incorporation of timing, stretchy delays, and box/barrier mechanisms to manage synchronization and optimization in the presence of varying gate durations, alongside an OpenPulse-calibration pathway for hardware-specific pulse control. The work positions OpenQASM 3 as a versatile, governance-driven, ecosystem-friendly language for designing, optimizing, and calibrating quantum circuits across diverse hardware platforms while supporting parameterized and externally computed components for near-time quantum–classical workflows.

Abstract

Quantum assembly languages are machine-independent languages that traditionally describe quantum computation in the circuit model. Open quantum assembly language (OpenQASM 2) was proposed as an imperative programming language for quantum circuits based on earlier QASM dialects. In principle, any quantum computation could be described using OpenQASM 2, but there is a need to describe a broader set of circuits beyond the language of qubits and gates. By examining interactive use cases, we recognize two different timescales of quantum-classical interactions: real-time classical computations that must be performed within the coherence times of the qubits, and near-time computations with less stringent timing. Since the near-time domain is adequately described by existing programming frameworks, we choose in OpenQASM 3 to focus on the real-time domain, which must be more tightly coupled to the execution of quantum operations. We add support for arbitrary control flow as well as calling external classical functions. In addition, we recognize the need to describe circuits at multiple levels of specificity, and therefore we extend the language to include timing, pulse control, and gate modifiers. These new language features create a multi-level intermediate representation for circuit development and optimization, as well as control sequence implementation for calibration, characterization, and error mitigation.

Figures (5)

• Figure 1: The compilation and execution model of a quantum program, and OpenQASM's place in the flow. An application is written in terms of a quantum program. Certain regions of a quantum program are purely classical and can be written in classical programming languages for execution in a near-time context. The quantum program emits payloads for execution on a quantum processor (QPU). This payload consists of extended quantum circuits and external real-time classical functions. OpenQASM is the language to describe the quantum circuits, which includes interface calls to the external classical functions. There may be higher-order aspects of the circuit payload which are optimized before OpenQASM is generated. An OpenQASM compiler can transform and optimize all aspects of the circuits described with the IR, including basis gates used, qubit mapping, timing, pulses, and control flow. The final physical circuit plus extern functions are passed to a target code generator which produces binaries for the QPU.
• Figure 2: Toffoli network to compute a Boolean function $f = \bar{a}_0\bar{a}_1a_2a_3a_4 \oplus \bar{a}_0a_1a_2\bar{a}_3 \oplus \bar{a}_0a_1a_3a_4 \oplus a_0\bar{a}_1a_3a_4 \oplus a_0a_1a_2 \oplus \bar{a}_0\bar{a}_1\bar{a}_2a_3$ in a target qubit. The control pattern may be expressed in OpenQASM via control gate modifiers.
• Figure 3: Fourier sampling circuit with the loop unrolled.
• Figure 4: Arbitrary alignment of gates in time using stretchy delays. a) left-justified alignment intent, and timed instructions after stretches are resolved. b) alignment intent of a short gate at the one-third point of a long gate, and after stretch resolution.
• Figure 5: Dynamically corrected CNOT gate where the spectator has a rotary pulse. The rotary gates are stretchy, and the design intent is to interleave a "winding" and "unwinding" that is equal to the total duration of the CNOT. We do this without knowledge of the CNOT duration, and the compiler resolves them to the correct duration during lowering to the target backend.