PaperlayerView exact revision on arXiv

Source-linked AI summary

OpenQASM 3: A broader and deeper quantum assembly language

Andrew W. Cross, Ali Javadi-Abhari, Thomas Alexander, Niel de Beaudrap, Lev S. Bishop, Steven Heidel, Colm A. Ryan, Prasahnt Sivarajah, John Smolin, Jay M. Gambetta, Blake R. Johnson

arXiv:2104.14722v2quant-ph

TL;DR

OpenQASM 2 could describe quantum computation in the circuit model, but broader circuits with tightly coupled real-time quantum-classical interactions required additional language support. OpenQASM 3 addresses this gap with classical control flow, external functions, timing, pulse control, gate modifiers, and multi-level representations for circuit development and physical implementation.

  • Problem

    OpenQASM 2 primarily described quantum circuits as qubits and gates, while extended circuits require concurrent real-time classical computation interacting with quantum operations.

  • Method

    OpenQASM 3 extends the language with real-time classical control flow, external classical functions, timing, pulse control, gate modifiers, and representations spanning abstraction levels.

  • Results

    OpenQASM 3 expands the scope of describable circuits to include classical-quantum interactions and physical implementations from high-level gate modifiers to low-level microcoded gates.

  • Takeaways & Limitations

    The language supports circuit development and optimization alongside control-sequence implementation for calibration, characterization, and error mitigation.

  • Takeaways & Limitations

    Compatibility with OpenQASM 2 was prioritized only insofar as practical, with necessary breaking changes in uncommon cases and a global-phase change without observable consequence for OpenQASM 2 circuits.

Abstract

from arXiv · show

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.

1 Introduction

OpenQASM 3 broadens quantum assembly beyond standalone qubit gates by targeting interactive circuits with tightly coupled real-time classical computation. It also serves users across circuit-development, compilation, and hardware-control workflows.

  • Motivation: OpenQASM 3 describes extended quantum circuits combining ordered quantum operations with concurrent real-time classical computation and bidirectional data flow.Classical computation can depend on measurement results, while quantum operations can use or be conditioned on classical data.
  • Motivation: Interactive quantum programs involve real-time computations constrained by qubit coherence times and near-time computations with less stringent timing.Real-time processing supports feedback, feedforward, and error correction but may face limited memory or reduced clock speeds.
  • Design focus: OpenQASM 3 focuses on the real-time domain because near-time computation is already adequately supported by existing programming tools and frameworks.The real-time domain must be tightly coupled to gate and measurement execution on qubits.
  • Execution model: The language uses a dataflow model in which instructions may execute independently when their input data becomes available.Concurrency and parallelism are presented as essential for quantum-control hardware and quantum error correction.
  • Language role: OpenQASM 3 is positioned between higher-level quantum software and lower-level analog control instructions rather than as a general-purpose or directly hardware-consumed language.It can be hand-written, generated by scripts, or targeted by higher-level tools before further compilation.
  • Design goals: Its feature choices address hand-written circuit design, compiler optimization, experimental timing and pulse modification, and hardware-engineering needs.The manuscript explains these motivations rather than serving as the formal language specification.

2 Design philosophy and execution model

OpenQASM 3 is designed around broader circuit expressivity, real-time execution, and multiple abstraction levels while preserving practical continuity with OpenQASM 2. Its execution flow lowers logical circuit intent toward physical, scheduled QPU code.

  • Design philosophy: OpenQASM 3 adds arbitrary classical control flow, gate modifiers, timing, and microcoded pulse implementations to expand practical circuit expressivity.These features support circuits beyond simple qubits and gates, including nondeterministic protocols and measurement-based operations.
  • Execution model: The language focuses on real-time quantum–classical interaction while leaving less time-sensitive classical application work to general programming frameworks.The stated boundary excludes turning OpenQASM into a general-purpose classical programming language.
  • Physical control: Timing and pulse-level features support calibration, characterization, error mitigation, dynamical decoupling, and studies of decoherence and crosstalk.Pulse-level calibration of gates can be fully described in OpenQASM 3.
  • Intermediate representation: OpenQASM 3 acts as a multi-level IR, representing logical gates and real-time classical computation before lowering to physically timed, continuous signals.Its semantics allow optimization and rewriting at different abstraction levels, including preserving controlled gates or powered gates before decomposition.
  • Continuity: OpenQASM 3 minimizes incompatibilities with OpenQASM 2 because the earlier language remains a de facto standard and software projects depend on it.The authors explicitly prioritize practical adoption while acknowledging that compatibility is not valued above all other design concerns.
  • Execution model: The execution flow emits logical or physical OpenQASM circuits plus external real-time functions, which are compiled and passed to a target code generator for QPU binaries.The logical representation captures circuit intent; the physical representation maps and schedules operations on specific qubits.
  • Execution model: The execution model assumes a global QPU controller that centralizes control-flow decisions and can execute external computations emitted by the quantum program.Some QPUs may additionally use local controllers for concurrent independent code segments.

3 Comparison to OpenQASM 2

OpenQASM 3 preserves much of OpenQASM 2’s structure while extending storage, control flow, gate description, lower-level operation semantics, and explicit I/O. These changes retain familiar constructs but broaden what circuits can express.

  • Syntax and storage: OpenQASM 3 retains OpenQASM 2-style headers, includes, top-level instruction streams, and legacy register syntax while introducing preferred primitive storage declarations.Qubits and bits can be declared as qubit[5] q and bit[2] c, while qreg and creg remain supported in the described syntax.
  • Syntax and storage: OpenQASM 3 introduces additional classical storage types and relaxes identifier rules, including support for capitals, underscores, and ranges of Unicode characters.The reserved identifier π denotes the same constant as pi.
  • Basic operations: OpenQASM 3 keeps U(a,b,c) support but makes CX definable from more primitive commands using the ctrl @ gate modifier rather than treating CX as a basic keyword.A standard-library definition is provided, and gate modifiers supply the relevant control semantics.
  • Gate declarations: OpenQASM 3 preserves user-defined unitary gate declarations while allowing more versatile unitary descriptions and separate subroutine mechanisms.Gate definitions remain restricted to unitary operations.
  • Iteration: Operations can be implicitly repeated across whole registers by omitting one or more indices from their qubit arguments.The omitted indices determine repetition across the corresponding register positions.
  • Control flow: OpenQASM 3 generalizes OpenQASM 2’s single-gate if statements to more general if syntax and other forms of control flow.The earlier bit-register comparison behavior remains supported.
  • Lower-level operations: OpenQASM 3 replaces the practical role of opaque declarations by providing lower-level operation definitions, while compilers simply ignore opaque declarations.Opaque declarations were used for physically implementable gates not readily expressed as unitary gates.
  • Input and output: OpenQASM 3 adds explicit input and output declarations, while circuits without them default to producing all stored classical variables as outputs.This extends the output model beyond classical registers alone.

4 Concepts of the language: the logical level

At the logical level, OpenQASM 3 represents quantum computations as a multi-level intermediate representation that can later be lowered to more physical descriptions.

  • Logical level: OpenQASM 3’s logical level expresses quantum circuits using abstract, discrete-time gates together with real-time classical computations.The language also includes a more fine-grained physical level for lower-level circuit descriptions.

4.1 Continuous gates and hierarchical library

OpenQASM 3 uses parameterized continuous gates and hierarchical composition to describe quantum operations compactly while leaving target-specific implementation to users or compilers.

  • Continuous gates: Parameterized unitary gates use built-in single-qubit gates and gate modifiers to construct controlled versions and a universal continuous gate set.The gate set supports universal computation but is not an enforced compilation target.
  • Hierarchical library: Hierarchical gate definitions enable code reuse and can represent many practically relevant gates more compactly than full n×n matrices.Many gates have polynomial-size one- and two-qubit circuit representations, although general n-qubit gates may require exponentially many gates.
  • Continuous gates: The U gate represents any element of U(2) up to a global phase, with useful Euler-angle and {H, P} decompositions.The Hadamard gate is given by U(π/2, 0, π).
  • Hierarchical library: A gate declaration associates a named gate with a unitary transformation without requiring that the target machine implement it through the declaration’s specific instruction sequence.Implementation is left to the user or compiler based on the target’s supported instructions.
  • Standard library: OpenQASM 3 retains CX for backwards compatibility, but controlled gates can instead be expressed using the control modifier rather than a language keyword.CX remains in the standard gate library, while it is no longer a keyword of the language.
  • Standard library: The standard library defines common gates, including Pauli, Clifford, rotation, controlled, swap, and compatibility gates.These gates are provided in the stdgates.inc library and can be used by circuits that include it.

4.2 Gate modifiers

OpenQASM 3 gate modifiers define controlled, inverted, exponentiated, and negatively controlled operations while preserving higher-level gate semantics for compilation and optimization.

  • Modifier mechanism: The ctrl, inv, and pow modifiers construct controlled, inverse, and powered versions of existing unitary gates.Modifiers can improve programming convenience and readability while retaining higher-level semantics for compilation.
  • Control modifier: The ctrl modifier represents a controlled-g gate, although a compilation target may require further decomposition or ancillary qubits.The controlled operation is defined by the block matrix I ⊕ g.
  • Optimization: Equivalent Fredkin definitions can have different numbers of controlled operations, allowing compiler passes to rewrite implementations for efficiency.The two definitions produce the same unitary matrix, while fredkin1 directly involves fewer controlled operations than fredkin2.
  • Control modifier: The negctrl modifier conditions operations on control bits being zero, and ctrl or negctrl can specify multiple compile-time-constant controls.This supports direct expression of reversible Boolean functions.
  • Control modifier: Controlled modifiers can express Boolean control patterns directly, including the Toffoli network used to compute a Boolean function in a target qubit.The example combines negative and positive controls on several input qubits.
  • Powering modifier: The pow modifier uses principal-logarithm matrix powers, but compiling powered gates generally requires circuit synthesis or optimization.Even integer powers may be implemented by repetition, while more efficient compilation remains a synthesis problem.

4.3 Non-unitary operations

OpenQASM 3 retains OpenQASM 2’s two basic non-unitary operations: measurement and reset, with defined effects on classical outcomes and qubit states.

  • Measurement: Measurement projects a qubit in the Z basis, assigns outcome 0 or 1 to a classical bit, and leaves the qubit available for further computation.Measurement also supports qubit arrays and stores each outcome in a corresponding classical variable.
  • Measurement: OpenQASM 3 preserves the OpenQASM 2 syntax measure q -> r for individual qubits or equal-length quantum and classical registers.The compatibility form supports both single qubits and arrays.
  • Reset: Reset returns a qubit to |0⟩ and, ideally, is equivalent to measurement followed by conditional X and discarding the outcome.Reset also operates elementwise on qubit arrays.

4.4 Real-time classical computing

OpenQASM 3 extends real-time classical computation beyond OpenQASM 2’s straight-line circuits by adding data types, arithmetic, bit manipulation, loops, conditionals, and external functions. These features support dynamic circuits whose classical decisions depend on measurements and control subsequent quantum operations.

  • Classical data and instructions: OpenQASM 3 adds classical data types, arithmetic, logical instructions, and control-flow keywords, making classical computations expressible within circuits.The type system includes signed and unsigned integers, floating-point values, booleans, bits, and fixed-width variants.
  • Classical data and instructions: Fixed-point angle values represent phases with configurable bit widths, supporting quantum phase estimation and real-time qubit-frame tracking without floating-point modular arithmetic.The angle[n] representation uses values over a phase range with a fractional binary expansion, while numerical overflow constrains phases to the intended domain.
  • Classical control flow: OpenQASM 2 largely limited circuits to straight-line code, whereas OpenQASM 3 adds while loops, for loops, multi-instruction if bodies, and else blocks.These constructs preserve iterative structure that previously had to be generated through metaprogramming and unrolled into lengthy circuits.
  • Classical control flow: Dynamic classical control enables circuits such as repeat-until-success protocols, where measurements determine which operations execute and when computation terminates.OpenQASM 3 expresses this behavior with while loops involving measurements and classical decisions.
  • External classical functions: OpenQASM 3 introduces extern functions for arbitrary opaque classical computations rather than expanding the language with a larger classical feature set.This keeps embedded classical functionality focused on frequently used operations while connecting circuits to more sophisticated classical computation.

4.5 Input and output parameters

OpenQASM 3 adds input and output parameters so one compiled quantum program can be invoked repeatedly with changing classical values. This separates compilation from near-time parameter updates, which is useful for variational algorithms such as VQE.

  • Parameter modifiers: Input and output modifiers let OpenQASM 3 circuits accept runtime parameters and return selected output variables.Without an output declaration, compatibility behavior returns all declared variables; with declarations, programmers can select outputs explicitly.
  • Parameterized execution: Parameterized circuits allow a single program to represent repeated executions with different values chosen by a near-time classical optimizer.This avoids generating a new sequence of operations for every parameter setting.
  • Compilation model: When input parameters are absent, changing a circuit variable such as θ requires recompilation for each execution.The paper describes compilation as expensive and slow in the VQE execution model.
  • Compilation model: With input parameters, compilation can be moved outside the iteration loop, leaving each iteration to run the compiled program with a new parameter value.The example reduces repeated execution to invoking the compiled binary with θ set at runtime.

5 Concepts of the language: the physical level

OpenQASM 3’s physical level adds timing and pulse-oriented constructs for controlling, scheduling, and constraining quantum operations. These features support experiments, calibration, optimization, and hardware-aware compilation while retaining flexibility across target backends.

  • Timing and optimization: Timing semantics let programs control gate and pulse schedules for decoherence and crosstalk characterization, dynamical decoupling, dynamically corrected gates, and parallelism.
  • Timing and optimization: Delay statements specify relative timing, while duration values represent explicit time intervals measured in seconds with SI prefixes.
  • Boxes and barriers: Boxes scope timed subcircuits: internal optimization remains allowed, but moving operations into or out of the box is forbidden.
  • Boxes and barriers: Barriers impose ordering constraints, whereas delays indicate fully scheduled instructions that subsequent scheduling should not alter.
  • Stretch types: Stretch values express relative timing independent of calibrated gate durations and are resolved by the compiler through multiobjective linear programming.
  • Stretch types: Stretchable delays support gate alignment, including left-justified schedules and weighted placement such as positioning a short gate at one-third of a longer gate.

5.2 Calibrating quantum operations

OpenQASM 3 adds calibration support that connects hardware-agnostic circuit instructions to platform-specific control implementations. Its pluggable grammars support vendor-defined pulse and calibration descriptions while preserving scheduling information.

  • Calibration declarations: OpenQASM 3 introduces defcal declarations for specifying microcoded implementations of gates, measurements, and resets in target-hardware control grammars.Calibration support is optional, and the selected defcalgrammar determines available calibration instructions.
  • Calibration declarations: Defcal definitions target physical qubits and may specialize by qubit and gate parameters, unlike generic gate declarations.This supports hardware-specific control stimuli and native parameter precision.
  • Scheduling constraints: Resolved defcal usages require compile-time computable durations and resource information so scheduling remains deterministic.Calibration implementations must also be independent of invocation time for substitution throughout a circuit.
  • Pluggable intermediate representation: Vendor-extensible calibration grammars provide a standardized lowering pipeline from hardware-agnostic OpenQASM to hardware-aware executable circuits.Vendors define grammars and compiler hooks, ranging from simple mappings to full pulse-programming languages.
  • Pulse-level control: OpenPulse examples use relative timing, barriers, external frames, waveforms, and nested defcal calls to synchronize and implement control sequences.Waveforms may be explicit complex-sample arrays or externally declared templates materialized by the compiler or hardware.

5.3 Solving the stretch problem

OpenQASM 3 resolves symbolic stretch values into explicit delays through a constrained optimization problem. The approach supports scheduling, alignment, and preserved design intent across abstraction levels.

  • Problem formulation: The stretch problem treats duration values as variables in a linear system of inequalities that must be solved before execution.The solver computes explicit durations for all delays.
  • Resolution and representation: A feasible stretch solution provides explicit timing for operations, while an infeasible or unbounded problem produces a compiler error or cannot determine a schedule.Stretches are resolved in a late-stage pass after circuit constraints and relevant durations are available.
  • Optimization: The formulation is a lexicographic multi-objective linear program that can be solved in polynomial time and efficiently in practice.Objectives are optimized sequentially while preserving the costs achieved by earlier objectives.
  • Problem formulation: Stretch problems are solved independently for basic blocks or boxes, with constraints from instruction ordering, durations, qubit resources, and target-platform minima.The block duration is represented by a variable that is minimized subject to nonnegative duration constraints.
  • Optimization: The declaration order of stretch variables determines their minimization order and can produce different schedules, including left- or right-aligned layouts.Minimizing a, b, c, d yields a left-aligned schedule, while reversing the order yields a right-aligned schedule.
  • Resolution and representation: Stretch instructions preserve high-level scheduling intent through compilation and can align operations even when gates are decomposed differently.Explicit delays constrain commutation, while stretchy delays can be carried with circuit constructs and inserted into gate definitions.

6 Compilation phases by example

An iterative phase-estimation example demonstrates OpenQASM 3 as an intermediate representation across compilation stages. The example progresses from target-independent transformations to hardware mapping, scheduling, calibration linking, and pulse-level execution.

  • Example and scope: The example uses iterative phase estimation to showcase classical control flow, gate modifiers, virtual and physical qubits, timing, stretches, and pulse-defined calibrations.The algorithm requires real-time feedforward because each measurement influences the next iteration during the qubits’ coherence interval.
  • Target-independent transformations: Target-independent compilation propagates constants, simplifies gates, evaluates modifiers, and may unroll statically known loops.These transformations expose optimization opportunities such as removing zero-angle rotations and redundant resets.
  • Target-dependent transformations: Target-dependent compilation maps virtual qubits to physical connectivity and translates operations into a target-specific basis.The example assumes physical qubits 0 and 1 support CNOT in either direction, so routing is unnecessary.
  • Timing and calibration: Scheduling uses stretchy delays to encode an as-late-as-possible policy before concrete gate durations are known.Later calibration linking supplies durations and resolves stretches into concrete delays.
  • Timing and calibration: Calibration linking associates pulse sequences with gates, resets, and measurements, then rounds angles to defcal precision and resolves final timing.The example includes waveform templates, physical-qubit defcals, two-qubit pulse sequences, and measurement capture.

7 Related Work and Future Extensions

OpenQASM 3 builds on prior quantum languages while emphasizing portable real-time classical control, gate modifiers, and timing or pulse-level circuit descriptions. The language remains deliberately lower-level, with additional features considered for future revisions.

  • OpenQASM 3 introduces new types such as angle and permits purely classical extern functions for real-time computation.
  • Gate modifiers decouple gate semantics from implementation and, with U and gphase, generate the standard gate library.
  • OpenQASM 3 extends prior timing and pulse-control approaches by expressing timing constraints decoupled from actual pulse implementations.
  • OpenQASM intentionally remains lower-level and focused on executable circuits rather than resource management or compiling classical code into reversible circuits.
  • The language uses structured for and while loops while preserving backwards compatibility with OpenQASM 2's global-scope execution model.
  • Unitary circuit families, generic subroutines, classical arrays, and fixed-point real numbers remain under consideration or reserved for future development.

8 Conclusion

OpenQASM 3 broadens quantum-circuit descriptions toward physical implementation and quantum–classical interaction while maintaining a consistent language across abstraction levels. The authors expect continued evolution driven by practical use and hardware development.

  • OpenQASM 3 expands quantum-circuit scope toward physical implementation and interactions between classical and quantum computing.
  • The language aims to preserve a consistent look and feel across different abstraction levels.
  • Future revisions are expected to address awkward constructions, missing features, and incomplete specifications discovered through real-world usage and hardware development.
Loading 2104.14722v2…