OpenQASM 3: A Broader and Deeper Quantum Assembly Language

2.1 Versatility in Describing Logical Circuits

One key motivation for the new language features is the ability to describe new kinds of circuits and experiments. For example, repeat-until-success algorithms [65] or magic state distillation protocols [20] have non-deterministic components that can be programmed using the new classical control flow instructions. There are other examples, which show benefits to circuit width or depth from incorporating classical operations. For instance, with measurement and feedforward any Clifford operation can be executed in constant depth [44]. The same is true of the quantum Fourier transform [79]. This extension also allows description of teleportation and feedforward in the measurement model [44, 67]. This collection of examples suggests the potential of the extended quantum circuit family to reduce the requirements needed to achieve quantum advantage in the near term.

It is not our intent; however, to transform OpenQASM into a general-purpose programming language suitable for classical programming. A general quantum application includes classical computations that need to interact with quantum hardware. For instance, some applications require pre-processing of problem data, such as choosing a co-prime in Shor’s algorithm [71], post-processing to compute expectation values of Pauli operators, or further generation of circuits like in the outer loop of many variational algorithms [66]. However, these classical computations do not have tight deadlines requiring execution within the coherence time of the quantum hardware. Consequently, we think of their execution in a near-time context, which is more conveniently expressed in existing classical programming frameworks. Our classical computation extensions in OpenQASM 3 instead focus on the real-time domain, which must be tightly coupled to quantum hardware. Even in the real-time context, we enable re-use of existing tooling by allowing references to externally specified real-time functions defined outside of OpenQASM itself.

2.2 Versatility in the Level of Description for Circuits

We wish to use the same tools for circuit development and for lower-level control sequences needed for calibration, characterization, and error mitigation. Hence, we need the ability to control timing and to connect quantum instructions with their pulse-level implementations for various qubit modalities. For instance, dynamical decoupling [78] or characterizations of decoherence and crosstalk [39] are all sensitive to timing, and can be programmed using the new timing features. Pulse-level calibration of gates can be fully described in OpenQASM 3.

Another design goal for the language is to create a suitable intermediate representation (IR) for quantum circuit compilation. Recognizing that quantum circuits have multiple levels of specificity from higher-level theoretical computation to lower-level physical implementation, we envision OpenQASM as a multi-level IR where different levels of abstraction can be used to describe a circuit. We can speak broadly of two levels of abstraction: logical and physical levels. A logical-level circuit (see Section 4) is described by abstract, discrete-time gates, and real-time classical computations. This is lowered by a compiler to a physical-level circuit (see Section 5) where quantum operations are implemented by continuous, time-varying signals with specific timing constraints. We introduce semantics that allow the compiler to optimize and re-write the circuit at different levels. For example, the compiler can reason directly on the level of controlled gates or gates raised to some power without decomposing these operations, which may obscure some opportunities for optimization. Furthermore, the new semantics allow capturing intent in a portable manner without tying it to a particular implementation. For example, the timing semantics in OpenQASM are designed to allow higher level descriptions of timing constraints without being specific about individual gate durations.

2.3 Continuity with OpenQASM 2

In the design of interfaces for quantum computing, particularly at the early stage that we are currently in, backwards compatibility is not to be prized above all else. However, in recognition of the current importance of the preceding version of OpenQASM as a de facto standard, we made design choices to introduce as few incompatibilities between OpenQASM 2 and OpenQASM 3 as practically possible.

Our intent is that an OpenQASM 2 circuit can be interpreted as an OpenQASM 3 circuit with no change in meaning. In doing so, we hope to introduce as little disruption to software projects, which rely on OpenQASM, and to make OpenQASM 3 easier to adopt for those software developers who are already familiar with OpenQASM 2. We describe the supported features of OpenQASM 2 in more detail in Section 3.

2.4 Execution Model

We illustrate a potential application compilation and execution flow for quantum programs in Figure 1. An application might be composed of several quantum programs including near-time calculations and quantum circuits. The quantum program interacts with quantum hardware by emitting OpenQASM3 circuits and external real-time functions. Initial generation of these circuits and extern functions require a deep compilation stack to transform the circuits and extern into a form that is executable on the QPU. We represent these multiple stages by logical OpenQASM and physical OpenQASM. The logical OpenQASM represents the intent of the extended quantum circuit, whereas the physical OpenQASM is the lowest level where the circuit is mapped and scheduled on specific qubits. A quantum program might work with even higher level circuit representations than those expressible with OpenQASM 3, but in this flow, manipulations of these higher order objects would be contained within the quantum program. A quantum program is not constrained to produce only logical OpenQASM. Sometimes it might emit physical OpenQASM, or later stages of a program might take advantage of lower-cost ways to produce binaries executable by the QPU. For instance, a program describing the optimization loop of a variational algorithm might directly manipulate a data section in the binaries to describe circuits with updated circuit parameters [46]. We generically expect quantum programs to be able to enter the compilation toolchain at varying levels of abstraction as appropriate for different phases of program execution.

Fig. 1.

View Figure

Our language model further assumes that the QPU has a global controller that orchestrates execution of the circuit. This global controller centralizes control flow decisions and has the ability to execute extern computations emitted by the quantum program. Some QPUs may also have a collection of local controllers that interact with a subset of qubits. Such segmentation of the QPU could enable concurrent execution of independent code segments.

4.1 Continuous Gates and Hierarchical Library

We define a mechanism for parameterizing unitary matrices to define quantum gates. The parameterization uses a set of built-in single-qubit gates and a gate modifier to construct a controlled version to generate a universal gate set [16]. Early QASM languages assumed a discrete set of quantum gates, but OpenQASM is flexible enough to describe universal computation with a continuous gate set. This gate set was chosen for the convenience of defining new quantum gates and is not an enforced compilation target. Instead of allowing the user to write a unitary as an \( n \times n \) matrix, we make gate definitions through hierarchical composition allowing for code reuse to define more complex operations [35, 42]. For many gates of practical interest, there is a circuit representation with a polynomial number of one- and two-qubit gates, giving a more compact representation than requiring the programmer to express the full \( n \times n \) matrix. In the worst case, a general \( n \)-qubit gate can be defined using an exponential number of these gates.

We now describe this built-in gate set. Single-qubit unitary gates are parameterized as (1) \( \begin{equation} U(\theta ,\phi ,\lambda) := \left(\begin{array}{cc} \cos (\theta /2) & -e^{i\lambda }\sin (\theta /2) \\ e^{i\phi }\sin (\theta /2) & e^{i(\phi +\lambda)}\cos (\theta /2) \end{array}\right). \end{equation} \) This expression specifies any element of \( U(2) \) up to a global phase. The global phase is here chosen so that the upper left matrix element is real. For example, U(π/2, 0, π) q[0]; applies the Hadamard gate \( H = \frac{1}{\sqrt {2}} \begin{array}{cc} 1 & \phantom{-}1 \\ 1 & -1\end{array} \) to qubit q[0]. For the convenience of the reader, we note two important decompositions of \( U \), through an Euler angle decomposition using rotations \( R_z(\alpha) = \exp (-i\alpha Z/2) \) and \( R_y(\beta) = \exp (-i\beta Y/2) \), and a \( \lbrace H, P\rbrace \) basis representation where \( P(\alpha) = \begin{array}{cc} 1 \,&\, 0 \\ 0 \,&\, e^{i\alpha \!}\end{array} \): (2) \( \begin{equation} U(\theta ,\phi ,\lambda) \;=\; e^{i(\phi +\lambda)/2}\, R_z(\phi)R_y(\theta)R_z(\lambda) \;=\; e^{i\theta /2} \, P(\phi \!+\!\pi /2) H P(\theta) H P(\lambda \!-\!\pi /2). \end{equation} \) Note. Users should be aware that the definition in Equation (1) is scaled by a factor of \( e^{i(\phi +\lambda)/2} \) when compared to the original definition in OpenQASM 2 [27]. This implies that the transformation described by U(a,b,c) has determinant \( e^{i(\texttt {a}+\texttt {c})} \), and is not in general an element of \( SU(2) \). This change in global phase has no observable consequence for OpenQASM 2 circuits. We also note that U is the only uppercase keyword in OpenQASM 3.

New gates are associated with a unitary transformation by defining them using a sequence of built-in or previously defined gates and gate modifiers. For example, the gate declaration

View Figure

defines a new gate called “h” and associates it to the unitary matrix of the Hadamard gate. Once, we have defined “h”, we can use it in later gate blocks. The definition does not necessarily imply that h is implemented by an instruction U(π/2, 0, π) on the quantum computer. The implementation is left to the user and/or compiler (see Section 5.2), given information about the instructions supported by a particular target.

Controlled gates can be constructed by attaching a control modifier to an existing gate. For example, the NOT gate (i.e., the Pauli \( X \) operator) is given by U(π, 0, π) and the block

View Figure

defines the gate (3) \( \begin{equation} \texttt {CX} := I\oplus \texttt {x} = \left(\begin{array}{cccc} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 0 & 1 \\ 0 & 0 & 1 & 0 \end{array}\right), \end{equation} \) and applies it to q[1] and q[0]. This gate applies a bit-flip to q[0] if q[1] is one, leaves q[1] unchanged if q[0] is 0, and acts coherently over superpositions. The control modifier is described in more detail in Section 4.2.

Remark. Throughout the document, we use a tensor order with higher index qubits on the left. This ordering labels states in a way that is consistent with how numbers are usually written with the most significant digit on the left. In this tensor order, CX q[0], q[1]; is represented by the matrix (4) \( \begin{equation} \left(\begin{array}{cccc} 1 & 0 & 0 & 0 \\ 0 & 0 & 0 & 1 \\ 0 & 0 & 1 & 0 \\ 0 & 1 & 0 & 0 \end{array}\right). \end{equation} \)

From a physical perspective, any unitary \( U \) is indistinguishable from another unitary \( \mathrm{e}^{i\gamma } U \), which only differs by a global phase. When we attach a control to these gates, however, the global phase becomes a relative phase that is applied when the control qubit is one. To capture the programmer’s intent, a built-in global phase gate allows the inclusion of arbitrary global phases on circuits. The instruction gphase(γ) adds a global phase of \( \mathrm{e}^{i\gamma } \) to the scope containing the instruction. For example,

View Figure

constructs the gate (5) \( \begin{equation} R_z(\tau) = \exp (-i\tau Z/2) = \begin{pmatrix} \mathrm{e}^{-i\tau /2} & 0 \\ 0 & \mathrm{e}^{i\tau /2} \end{pmatrix} = \mathrm{e}^{-i\tau /2} \begin{pmatrix} 1 & 0 \\ 0 & \mathrm{e}^{i\tau } \end{pmatrix}, \end{equation} \) and applies the controlled form of that phase rotation gate (6) \( \begin{equation} I\oplus R_z(\pi /2) = \begin{pmatrix} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & \!\mathrm{e}^{-i\pi /4}\! & 0 \\ 0 & 0 & 0 & \!\mathrm{e}^{i\pi /4}\! \end{pmatrix}. \end{equation} \)

In OpenQASM 2, gate subroutines are defined in terms of built-in gates U and CX. In OpenQASM 3, we can define controlled gates using the control modifier, so it is no longer necessary to include a built-in CX gate. For backwards compatibility, we include the gate CX in the standard gate library (described below), but it is no longer a keyword of the language.

4.1.1 Standard Gate Library.

We define a standard library of OpenQASM 3 gates in a file, we call stdgates.inc. Any OpenQASM 3 circuit that includes the standard library can make use of these gates.

View Figure

4.2 Gate Modifiers

We introduce a mechanism for modifying existing unitary gates g to define new ones. A modifier defines a new unitary gate from g, acting on a space of equal or greater dimension, that can be applied as an instruction. We add modifiers for inverting, exponentiating, and controlling gates. This can be useful for programming convenience and readability, but more importantly it allows the language to capture gate semantics at a higher level which aids in compilation. For example, optimization opportunities that exist by analysing controlled unitaries may be exceedingly hard to discover once the controls are decomposed.

The Control Modifier.

The modifier ctrl@ g represents a controlled-g gate with one control qubit. This gate is defined on the tensor product of the control space and target space by the matrix I ⊕ g , where \( I \) has the same dimensions as g. (We regard ctrl@gphase(a) as a special case, which is defined to be the gate U(0,0,a).) A compilation target may or may not be able to execute the controlled gate without further compilation. The user or compiler may rewrite the controlled gate to use additional ancillary qubits to reduce the size and depth of the resulting circuit.

For example, we can define the Fredkin (or controlled-swap) gate in two different ways:

View Figure

The definitions are equivalent because they result in the same unitary matrix for both Fredkin gates. If we directly apply the definitions, fredkin1 involves fewer controlled operations than fredkin2. A compiler pass may infer this fact or even rewrite fredkin2 into fredkin1. Note that although the toffoli gate is well defined here, the compiler or user needs to do further work to synthesize it in terms of more primitive operations, such as 1- and 2-qubit gates, or pulses (see Section 5.2).

For a second example, if we go one step further, we can define a controlled Fredkin gate. If we use the \( ABA^\dagger \) pattern in the definition of the fredkin1 gate, we require only one controlled toffoli gate after we remove unneeded controls from the CX gates. Although the controlled toffoli gate is defined on four qubits, it may be beneficial for a compiler or user to synthesize the gate using extra qubits as scratch space to reduce the total gate count or circuit depth, as in the following example:

View Figure

We further provide the negctrl modifier to control operations with negative polarity, i.e., conditioned on the control bit being 0 rather than 1. Both ctrl and negctrl optionally accept an argument \( n \), which specifies the number of controls of the appropriate type, which are added to the front of the list of arguments (omission means \( n=1 \)). In each case, \( n \) must be a positive integer expression which is a “compile-time constant”. ⁴ For example, this can be useful in writing classical Boolean functions [69], as demonstrated by the following example (illustrated in Figure 2).

Fig. 2.

View Figure

View Figure

The Inversion Modifier.

The modifier inv@ g represents the inverse g\( ^\dagger \) of the gate g. This can be easily computed from the definition of the gate g as follows:

–	The inverse of any unitary operation \( U=U_mU_{m-1}\dots U_1 \) can be defined recursively by reversing the order of the gates in its definition and replacing each of those with their inverse \( U^\dagger =U_1^\dagger U_2^\dagger \dots U_m^\dagger \).
–	The inverse of a controlled operation \( I\oplus U \) can be defined by reversing the operation, which is controlled, as \( (I\oplus U)^\dagger =I\oplus U^\dagger \) for any unitary \( U \). That is, inv@ctrl@ g is defined to have the same meaning as ctrl@inv@ g (commuting the “inv @” modifier past the “ctrl @” modifier).
–	The base case is given by replacing inv@U(a, b, c) by U(-a, -c, -b), and replacing inv @ gphase(a) by gphase(-a).

For example,

View Figure

applies the gate inv@ rz(π/2), which is defined by { gphase(π/4); U(0,-π/2,0); . For an additional example: The gate inv@ctrl@ rz(π/2) q[1], q[0] would be rewritten as ctrl@inv@ rz(π/2) q[1], q[0] , which is the same as ctrl@rz(-π/2) q[1], q[0] .

The Powering Modifier.

The modifier pow(r) @ g represents the \( r \)th power g\( ^r \) of the gate g, where \( r \) is an integer or floating point number. Every unitary matrix \( U \) has a unique principal logarithm \( \log U = iH \), where \( H \) has only real eigenvalues \( E, \) which satisfy \( -\pi \lt E \le \pi \). For any real \( r \), we define the \( r \)th power as \( U^r = \exp (i r H) \).

For example, consider the Pauli \( Z \) operator \( \mathsf{z} = \begin{array}{cc} 1 & 0 \\ 0 & -1\end{array} \). The principal logarithm is \( \log {\mathsf {z}} =\begin{array}{cc} 0 & 0 \\ 0 & i\pi \end{array} \), from which it follows that \( \mathsf{Z}^{1/2} = \exp (\tfrac{1}{2} \log \mathsf{z}) = \begin{array}{cc} 1 & 0 \\ 0 & i \end{array} \). In this way, the definitions

View Figure

allow us to define the gate \( \texttt {s} \) as the square root of \( \texttt {z} \). (A compiler pass is responsible for resolving \( S \) into gates.) For another example, the principal logarithm of the Pauli \( X \) operator \( {\texttt {x}} = \begin{array}{cc} 0 & 1 \\ 1 & 0\end{array} \) is \( \log \texttt {{x}}=\tfrac{i\pi }{2}\begin{array}{cc} +1 \,&\, -1 \\ -1 \,&\, +1\end{array} \). One can confirm that this operator has eigenvalues 0 and \( i\pi \), and \( \texttt {{x}}^{1/2} := \exp (\tfrac{1}{2}\log \texttt {{x}}) = \tfrac{1}{2}\begin{array}{cc} 1{+}i \,&\, 1{-}i \\ 1{-}i \,&\, 1{+}i \end{array} \). Therefore, the definitions of the \( \sqrt {X} \) gate

View Figure

are equivalent.

In the case where \( r \) is an integer, the \( r \)th power pow(r) @ g can be implemented simply (albeit less efficiently) as \( r \) repetitions of g when \( r\gt 0 \), or \( r \) repetitions of inv@ u when \( r\lt 0 \). Continuing our previous example,

View Figure

defines and applies \( \texttt {s} \)\( ^{-2} \). This can be compiled to

View Figure

and further simplified into

View Figure

without solving the problem of synthesizing \( \texttt {s} \). In general, however, compiling pow(r) @ g involves solving a circuit synthesis or optimization problem, even in the integral case.

4.3 Non-unitary Operations

OpenQASM 3 includes two basic non-unitary operations, which are the same as those found in OpenQASM 2.

The statement bit = measure q measures a qubit \( \texttt {q} \) in the \( Z \)-basis, and assigns the measurement outcome, “0” or “1”, to the target bit variable (see the subsection on classical types in Section 4.4). Measurement is “non-destructive”, in that it corresponds to a projection onto one of the eigenstates of \( Z \); the qubit remains available afterwards for further quantum computation. The \( \texttt {measure} \) statement also works with an array of qubits, performing a measurement on each of them and storing the outcomes into an array of bits of the same length. For example, the example below initializes, flips, and measures a register of 10 qubits.

View Figure

For compatibility with OpenQASM 2, we also support the syntax measure q -> r for a qubit \( \texttt {q} \) (or quantum register of some length \( n \)), and a bit variable \( \texttt {r} \) (or a classical bit register of the same length).

The statement reset q resets a qubit \( \texttt {q} \) to the state \( |0\rangle \). With idealised quantum hardware, this is equivalent to measuring \( \texttt {q} \) in the standard basis, performing a Pauli \( X \) operation on the qubit if the outcome is “1”, and then discarding the measurement outcome. Mathematically, it corresponds to a partial trace over \( \texttt {q} \) (i.e., discarding it) before replacing it with a new qubit in the state \( |0\rangle \). The \( \texttt {reset} \) statement also works with an array of qubits, resetting them to the state \( |0\rangle \otimes \cdots \otimes |0\rangle \).

4.4 Real-time Classical Computing

OpenQASM 2 primarily described static circuits in which the only mechanism for control flow were \( \texttt {if} \) statements that controlled execution of a single gate. This constraint was largely imposed by corresponding limitations in control hardware. Dynamic circuits—with classical control flow and concurrent classical computation—represent a richer model of computation, which includes features that are necessary for eventual fault-tolerant quantum computers that must interact with real-time decoding logic. In the near term, these circuits also allow for experimentation with qubit re-use, teleportation, and iterative algorithms.

Dynamic circuits have motivated significant advances in control hardware capable of moving and acting upon real-time values [22, 38, 68]. To take advantage of these advances in control, we extend OpenQASM with classical data types, arithmetic and logical instructions to manipulate the data, and control flow keywords. While our approach to selecting classical instructions was conservative, these extensions make OpenQASM Turing-complete for classical computations in principle, augmenting the prior capability to describe static circuits composed of unitary gates and measurement.

Classical Types:.

In considering what classical instructions to add, we felt it important to be able to describe arithmetic associated with looping constructs and the bit manipulations necessary to shuttle data back and forth between qubit measurements and other classical registers. As a result, simple classical computations can be directly embedded within an OpenQASM 3 circuit. To support these, we introduce classical data types like signed/unsigned integers and floating point values, to provide well-defined semantics for arithmetic operations.

The OpenQASM type system was designed with two distinct requirements in mind. When used within high-level logical OpenQASM circuits the type system must capture the programmer’s intent. It must also remain portable to different kinds of quantum computer controllers. When used within low-level physical OpenQASM circuits the type system must reflect the realities of particular controller, such as limited memory and well-defined register lengths. OpenQASM takes inspiration from type systems within classical programming languages but adds some unique features for dynamic quantum circuits.

For logical-level OpenQASM circuits, we introduce some common types, which will be familiar to most programmers: int for signed integers, uint for unsigned integers, float for floating point numbers, bool for boolean true or false values, and bit for individual bits. The precision of the integer and floating-point types is not specified within the OpenQASM language itself: rather the precision is presumed to be a feature of a particular controller. Simple mathematical operations are available on these types, for example:

View Figure

More complex classical operations are delegated to extern functions, as we describe below.

For low-level platform-specific OpenQASM circuits, we introduce syntax for defining arbitrary bit widths of classical types. In addition to the hardware-agnostic int type, OpenQASM 3 also allows programmers to specify an integer with exact precision int[n] for any positive integer n. For example,

View Figure

shows direct access to the underlying bits in classical values. This kind of flexibility is common in hardware description languages like VHDL and Verilog where manipulations of individual bits within registers are common. We expect similar kinds of manipulations to be common in OpenQASM 3, and so we allow for direct access to bit-level updates within classical values. In practice, we expect target platforms for OpenQASM 3 to only support particular bit widths of each classical type: e.g., some target hardware might only allow for uint[8] and uint[16], while other targets might only offer uint[20]. This is intended to allow OpenQASM 3 to describe platform-specific code, which is tailored to the registers and other resources of controllers of a quantum circuit unit. If the programmer does not require a particular bit width, they may leave the bit-width unspecified: Bit-level operations on the variable would no longer be permitted, but an appropriate choice of bit-width would then be deferred to a platform-specific compiler.

OpenQASM 3 also introduces a fixed-point angle type to represent angles or phases. These may also be defined to have a specific bit-width through the types angle[n]. Values stored in variables of the type angle[n] may be interpreted as representing values in the range \( [0, 2\pi) \),⁵ with a fractional binary expansion of the form \( 2\pi \times 0.c_{n-1}c_{n-2} \cdots c_{0} \) . (For example, with an angle[4], the binary representation of \( \pi \) would be \( c_3 c_2 c_1 c_0 = \texttt {1000} \), using a big-endian representation; the representation of \( \pi /2 \) would be 0100; and so forth.) This representation of phases is common to both quantum phase estimation [51] as well as numerically-controlled oscillators. The latter case is particularly relevant to real-time control systems that need to track qubit frames at run-time, where they can take advantage of numerical overflow to automatically constrain the phase representation to the domain \( [0, 2\pi) \), obviating the need for expensive floating-point modular arithmetic. The confluence of this angle representation in controllers and quantum algorithms influenced us to add first-class support for this type in OpenQASM 3.

Classical Control Flow:.

OpenQASM 2 circuits were effectively limited to straight line code: any quantum algorithm with more involved constructs, such as loops, could only be specified through meta-programming in a more general tool such as Python. The resulting OpenQASM 2 circuits could end up being quite lengthy in some cases, and lost all the structure from their original synthesis. In OpenQASM 3, we introduce while loops and for loops. We also extend the if statement syntax to allow for multiple instructions within the body of the if, and to allow for an else block to accompany it.

As an example, consider an inverse quantum Fourier transform circuit as written in OpenQASM 2 (Figure 3):

Fig. 3.

View Figure

View Figure

(The barrier statement is discussed in Section 5.1.) One can recognize a natural iterative structure to this circuit, but the lack of a looping construct has forced us to unroll this structure when writing it out. Furthermore, each iteration has a series of if statements that in principle could be combined, as the body of those statements is a \( Z \) rotation in all cases. In OpenQASM 3, we might instead write the above circuit as follows:

View Figure

which preserves the iterative structure of the inverse QFT and uses the angle[4] type (and operations on its bit-level representation) to directly convert measurement bits into the appropriate Z rotations.

Subroutines:.

Sufficiently simple functions (accompanied by sufficiently capable controllers) allow for classical subroutines to be fully implemented within the language itself. Consider a simple vote function, which takes the majority “vote” of three bit parameters. This could be implemented as follows:

View Figure

We extend this functionality to quantum procedures as well. For instance, a repeat-until-success quantum circuit [65] is naturally described by a while loop involving measurements, where the computation terminates only after a particular measurement outcome is observed. That is, the classical controllers make dynamic decisions about which operations are to be performed. The following is one example:

View Figure

External Functions:.

Rather than bulk up the feature set of OpenQASM for classical computation further—which would require sophisticated classical compiler infrastructure to manage —we selected only those elements we thought likely to be used frequently. To provide access to more sophisticated classical computations, we instead introduce a extern mechanism to connect OpenQASM 3 circuits to arbitrary, opaque classical computations.

An extern is declared similarly to a function declaration in a C header file. That is, rather than define commonly used simple subroutines in OpenQASM, the programmer may provide a signature of the form:

View Figure

and then use vote like a subroutine acting on classical bits. In order to connect to existing classical compiler infrastructure, the definition of an extern is not embedded within an OpenQASM circuit, but is expected to be provided to the compilation tool chain in some other language format such as Python, C, x86 assembly, or LLVM IR. This allows externs to be compiled with tools like GCC or LLVM with a minimal amount of additional structure to manage execution within the run-time requirements of a global controller. Importantly, this strategy of connecting to existing classical programming infrastructure implies that the programmer can use existing libraries without porting the underlying code into a new programming language.

Unlike other approaches to interfacing with classical computing, OpenQASM does not have an explicit synchronization primitive such as the WAIT instruction in QUIL [3, 73]. In particular, invoking an extern function does not imply a synchronization boundary at the call site.⁶ A compiler is free to use dataflow analysis to insert any required target-specific synchronization primitives at the point where outputs from extern call are used. That is, invoking an extern function schedules a classical computation, but does not wait for that calculation to terminate. The extern semantics abstract away the particulars of a vendor-specific application binary interface (ABI) for how data are moved to and from the classical function.

4.5 Input and Output Parameters

In addition to the real-time classical compute constructs of OpenQASM 3, we introduce features targeted to support near-time computation, in the form of OpenQASM programs with input and output parameters (described elsewhere as “parameterized circuits” [46]). This functionality is provided through keywords input and output, which act as modifiers on variable declarations, and allow OpenQASM 3 circuits to represent these variables as accepting input parameters and returning select output parameters.

The input modifier can be used to indicate that one or more variable declarations represent values, which will be provided at run-time, upon invocation. This allows the programmer to use the same compiled circuits, which only differ in the values of certain parameters. As OpenQASM 2 did not allow for input parameters or input declaration, for compatibility OpenQASM 3 does not require an input declaration to be provided: in this case it assumes that there are no input parameters. When an input declaration is provided, the compiler produces an executable that leaves these free parameters unspecified: A circuit run would take as input both the executable and some choice of the parameters.

The output modifier can be used to indicate that one or more variables are to be provided as an explicit output of the quantum procedure. Note that OpenQASM 2 did not allow the programmer to specify that only a subset of its variables should be returned as output, and so it would return all classical variables (which were all creg variables) as output. For compatibility, OpenQASM 3 does not require an output declaration to be provided: In this case it assumes that all of the declared variables are to be returned as output. If the programmer provides one or more output declarations, then only those variables described as outputs will be returned as an output of the quantum process. A variable may not be marked as both input and output.

The input and output modifiers allow the programmer to more easily write variational quantum algorithms: A quantum algorithm with some free parameters, which may be run many times with different parameter values which are determined by a classical optimiser at near-time. Rather than write a circuit which generates a new sequence of operations for each run, OpenQASM 3 allows such circuits to be expressed as a single program with input parameters. This allows the programmer to communicate many different circuits with a single file, which only has to be compiled once, amortizing the cost of compilation across many runs. For an example, we may consider a circuit, which performs a measurement in a basis given by an input parameter:

View Figure

For a second example, consider the Variable Quantum Eigensolver (VQE) algorithm [66]. In this algorithm, the same circuit is repeated many times using different sets of free parameters to minimize an expectation value. The following is an example, in which there is also more than one input variable:

View Figure

The following Python pseudocode illustrates the differences between using and not using input and output parameters in a quantum program for the case of the VQE. This pseudocode is fictional but demonstrates the near-term execution model: where there is some classical code coordinating the compilation and execution of OpenQASM programs.

When input and output parameters are not used, the program must be recompiled to account for every change of the input variable theta. Compilation is assumed to be expensive and slow so it will be the main bottleneck toward completion of the overall VQE algorithm.

View Figure

When input and output parameters circuits are used, we can hoist compilation out of the loop. The only part of the program that is changing is the value of θ. The entire program does not need to be re-compiled each time.

View Figure

5.1 Timing and Optimization

A key aspect of expressing code for quantum experiments is the ability to control the timing of gates and pulses. Examples include characterization of decoherence and crosstalk [39], dynamical decoupling [41, 61 , 77], dynamically corrected gates [29, 49], and gate parallelism or scheduling [62]. We introduce such timing semantics in OpenQASM 3 to enable such circuits.

Delay Statements and Duration Types:.

We introduce a delay statement, which allows the programmer to specify relative timing of operations. These statements can take the form delay[t], where t is a value of type duration. We introduce the duration type to support such timing instructions: values of type duration represent amounts of time measured in seconds (typically also modified by an SI prefix). For example, a qubit’s relaxation time (\( T_1 \)) can be measured by an OpenQASM snippet of the following form:

View Figure

Furthermore, any instruction may take a bracketed duration, such as x[30ns] q[1] for a gate x defined with a gate declaration. Instructions with bracketed durations are required to have exactly that duration (although, see the stretch type below). If an instruction is not defined by a defcal consistent with the requested duration, then it may not be executable on hardware.

Boxes and Barrier Statements:.

OpenQASM 3 includes features to constrain the reordering of gates, where the timing of those gates might otherwise be changed by the compiler (or the gates removed entirely as a valid optimization on the logical level).

We introduce a box statement, to help with scoping the timing of a particular part of the circuit. A boxed sub-circuit is different from a gate (see Section 4.1) or def subroutine (see Section 4.4), in that it is merely a pointer to a piece of code within the larger scope which contains it. This can be used to signal permissible logical-level optimizations to the compiler: optimizing operations within a box definition is permitted, and optimizations that move operations from one side to the other side of a box are permitted, but moving operations either into or out of the box as part of an optimization is forbidden. The compiler can also be given a description of the operation which a box definition is meant to realise, allowing it to re-order gates around the box. For example, consider a dynamical decoupling sequence inserted in a part of the circuit:

View Figure

By boxing the sequence, we create a box that implements the identity. The compiler is now free to commute a gate past the box by knowing the unitary implemented by the box:

View Figure

The compiler can thus perform optimizations without interfering with the implementation of the dynamical decoupling sequence.

As with other operations, we may use square brackets to assign a duration to a box: This can be used to put hard constraints on the execution of a particular sub-circuit by requiring it to have the assigned duration. This can be useful in scenarios where the exact duration of a piece of code is unknown (e.g., if it is runtime dependent), but where it would be helpful to impose a duration on it for the purposes of scheduling the larger circuit. For example, if the duration of the parameterized gates mygate1(a, b), mygate2(a, b) depend on values of the variables a and b in a complex way, but an offline calculation has shown that the total will never require more than 150 ns for all valid combinations:

View Figure

In the above example, str1 is of stretch type, to be discussed in the next section, and in this the compiler will resolve it to the proper value to fill out the box to 150ns.

OpenQASM 3 also retains the barrier instruction of OpenQASM 2, which prevents gates from being reordered across its source line, either on a specified qubit (or register) q, or a sequence of qubits (or registers) q, r, ... . For example,

View Figure

This will prevent the compiler from performing optimizations, which involve combining or canceling the CNOT gates on the register r. However, it does not prevent similar optimizations of the h p[0] operations on either side of it. Outside of any box, a barrier statement may also be invoked without any arguments (as in the examples of classical control flow in Section 4.4), in which case it prevents gates from being reordered across its source line, on all qubits.

More generally, delay statements also prevent optimizations or re-orderings of gates, which would move a gate acting on some qubit past a delay statement on the same qubit. The barrier instruction in OpenQASM 3 is similar to a special case of delay, with a duration of zero. The difference between barrier and delay[0] is that the use of delay indicates a fully scheduled series of instructions, that any should not be altered by further scheduling, whereas barrier merely indicates an ordering constraint, and if necessary a scheduling pass may add finite-duration delays adjacent to barriers. In this way, barrier statements may be regarded as helping to provide time synchronization within the given scope and across the qubits on which they are applied. However, the constraints implied by delay and barrier statements do not leak out of any containing box declarations, and thus do not prevent commutation with uses of the box: They are treated as implementation details of the box, and are invisible to the outside scope.

Stretch Types:.

By specifying relative timing of operations rather than absolute timing, it is possible to use OpenQASM 3 to provides more flexible timing of operations, which can be helpful in a setting with a variety of calibrated gates with different durations. We introduce a new type stretch, representing a duration of time which is resolvable to a concrete duration at compile time once the exact duration of calibrated gates are known. A stretch quantity is a value which the compiler attempts to minimize, subject to timing constraints on one or more qubits. (We say that each a stretch value has a “natural duration” of 0, though constraints may impose a larger value on any given stretch value.) This makes it possible for a programmer/compiler to express gate designs such as evenly spacing gates (e.g., to implement a higher-order echo decoupling sequence), left-aligning a sequence of gates, or applying a gate for the duration of some subcircuit. We are motivated to include this feature by the importance of specifying gate timing and parallelism, in a way that is independent of the precise duration and implementation of gates at the pulse-level description. This increases circuit portability by decoupling circuit timing intent from the underlying pulses, which may change from machine to machine or even from day to day.

We refer to the problem of assigning definite values to stretch values, as “the stretch problem”. The stretch type itself, and our approach to the stretch problem, is inspired by how a similar problems are solved in TeX [52] using “glues”, where the compiler spaces out letters, words, and so on, appropriately given a target font. In quantum circuits, we have the additional challenge that timings on different qubits are not independent, e.g., if a two-qubit gate connects the qubits. This means that the choice of timing on one qubit line can have a ripple effect on other qubits. We describe how the stretch problem is solved through multi-objective linear programming in Section 5.3.

A simple use case for stretchable delays are gate alignments. We can use this feature to gain control on how gates are aligned in a circuit, regardless of the latencies of those gates on the machine. For example, consider the following code sample for left-aligning operations on a collection of qubits:

View Figure

The corresponding circuit is illustrated in Figure 4(a) (where the spring symbols on and across qubit wires denote delays with stretch parameters). After the circuit is lowered to a particular machine with known gate calibrations and durations, the compiler resolves every stretchy delay instruction into one with concrete timing, so that the operations performed on each qubit take the same cumulative amount of time.

Fig. 4.

View Figure

We can further control the exact alignment by giving relative weights to the stretchy delays. This method is flexible, e.g., to align a gate at the 1/3 point of another gate, we can use a delay[g] instruction before, and a >delay[2*g] after the gate to be aligned, as in the following example (illustrated as a circuit in Figure 4(b)):

View Figure

The scope of a stretch variable can be bounded by a box statement. If the box statement has been assigned a duration (e.g., to help with scheduling operations in the larger circuit), this imposes a limitation on the total duration of the operations to be performed within the box, which in turn, constrains the stretch values inside. For example:

View Figure

The “natural” duration of instructions within a box (e.g., taking a hypothetical value of 0 for all stretch values) must be smaller than the declared box duration, otherwise a compile-time error will be raised. The stretch inside the box will always be set to fill the difference between the declared duration and the natural duration. If the instructions exceed the deadline at runtime, a runtime error is raised.

Instructions other than delay can also be “stretchy”, if they are explicitly defined as such. Consider for example a rotation called rotary that is applied for the entire duration of some other gate [75]. Once resolved to a concrete time, it can be passed to the gate definition (in terms of pulses) to realize the gate. This scenario is illustrated schematically in Figure 5 and can be expressed in OpenQASM 3 as:

Fig. 5.

View Figure

View Figure

In particular, the duration of a box statement can also be be given as a stretch, in which case its “natural” duration is constrained by the natural durations of its operations, and the duration it takes at run-time depends on the constraints imposed in the larger circuit in which the box block occurs. For example,

View Figure

realizes a CNOT operation on qubits q[0] and q[1], followed by a delay of at least 200 ns, followed by a CNOT on qubits q[2] and q[3].

Because stretches must be resolved through solving a linear program, there are limitations on their use: They can appear only in linear combinations of stretch variables and durations, and their numerical value is only available at a late stage in the compilation process. Because duration types are known explicitly without solving a linear program, they can be used more freely in nonlinear expressions and control flow. The following example is valid with pi_time as duration but would be invalid if it were a stretch.

View Figure

5.2 Calibrating Quantum Operations

OpenQASM describes circuits applying quantum operations such as unitary gates and projective measurements to qubits. Quantum operations are typically implemented with classical time-dependent signals coupled to quantum systems. Control hardware such as arbitrary waveform generators, flux sources, and lasers emit signals to orchestrate the synchronous emission of calibrated control fields. These guide the quantum system to implement the desired quantum operation [40]. Consequently, control system implementations at the hardware and software level are highly platform-dependent. For example, superconducting transmon qubits encode a qubit in a non-linear oscillator formed by a parallel circuit consisting of a Josephson junction and a capacitor. To manipulate the state of the qubit a series of shaped microwave control pulses are applied to it [53]. The design of these control signals is an active area of research, and developments in this area enable software updates to improve the performance of existing hardware systems [45]. The support for calibration grammars in OpenQASM is motivated by the rapid pace of development within the quantum hardware space and the need for hardware/software co-design to extract the maximum performance from today’s quantum computers. Similar considerations have motivated several software projects to directly support signal-level control of quantum hardware, including QGL [4], Artiq [19], OpenPulse [13, 60], JaqalPaw [56], QUIL-T [7], QCCS [8], Qua [6], and Pulser [72].

OpenQASM has added support for specifying instruction calibrations in the form of defcal (short for “define calibration”) declarations, which allow the programmer to specify a microcoded [80] implementation of a gate, measure, or reset instruction within a lower-level control grammar as implemented by the target hardware vendor. This particular language keyword is borrowed from the recently proposed QUIL-T extension of the Quil language [7]. Support for defcal declarations is optional for OpenQASM compilers and target devices. The example below shows how the programmer can select the openpulse calibration grammar (introduced later in this section), and declare the calibration for an rx instruction.

View Figure

The available calibration instructions are determined by the user’s selected defcalgrammar. A defcal declaration has a similar form to a gate declaration, but with some subtle differences. Whereas a gate declaration defines a previously undefined gate in terms of other OpenQASM instructions, a defcal declares the implementation of an OpenQASM instruction for a target device. In a gate, parameters are infinite precision angles in the gate, whereas in the defcal a precision may be specified, enabling the definition of gate calibrations at the native precision of the target hardware. The defcal is defined for physical qubits rather than being the definition of a unitary gate applicable to any qubit. In this case, the defcal is for a fixed qubit ($0), i.e., the zeroth physical qubit on the device. (OpenQASM reserves identifiers of the form $n, where \( n \) is a non-negative integer for physical qubits of the corresponding integer index in the target device.) We assume that compiler mapping passes assign virtual qubits to particular physical qubits in the device.

Calibration grammars may require the ability to insert top-level configuration information and system setup outside of the defcal in order to share that information across multiple defcals. To facilitate this, OpenQASM 3 introduces cal blocks. Within cal blocks the semantics of the selected calibration grammar are valid. Values declared within the cal block may only be referenced from other cal blocks or defcal declarations that capture values from the containing scope. The example below uses a cal block to define frequencies, ports, and frames to be used in later defcal declarations.

View Figure

Through defcal and cal declarations, the programmer may define the implementation of canonical instructions for the target hardware. These operation definitions are not typically invoked from a logical-level specification of an operation. Rather, a target-system compiler links the circuit-level OpenQASM circuit to these definitions, as shown in the rx definition example above. This embeds an extendable translation layer between the circuit model and control-hardware implementations of quantum instructions within OpenQASM. If a defcal does not have a corresponding gate declaration the compiler will treat the call to this defcal as a call to an opaque circuit operation of the same name and signature. In such a case, the compiler is not able to reason about the state of the circuit across calls to these defcals. Consequently, this functionality replaces the opaque keyword of OpenQASM 2.

Calibration Resolution.

The signals required to enact gates on physical hardware may vary greatly based on the kind of gate, the physical qubit type, and the input gate parameters involved. The role of defcal declarations is to specify how a gate or primitive operation is performed, with defcal dispatch support for specialized definitions for specific physical qubits and gate parameters.

For instance, defcal rx(angle[20] θ) $q defines the implementation of a rx gate of any angle on any physical qubit $q, whereas defcal rx(π) $0 specifically targets an \( X \) rotation of \( \pi \) radians on physical qubit $0. The reference to physical rather than virtual qubits is critical, as quantum registers are normally not interchangeable from the perspective of the details of the control stimulus that enacts them.

At compile-time, specialized defcal declarations are greedily matched with qubit specializations selected before instruction arguments. If not all parameters are specialized, the declaration with the largest number of specialized parameters is matched first. In the event of a tie, the compiler will choose the defcal block that appeared first in the circuit.⁷ For instance, given:

View Figure

the operation rx(π/2) $0 would match the defcal declaration on line 3; rx(π) $0 would match the declaration on line 2; and rx(π/2) $1 would match the declaration on line 1. Calibrations for measurements are specified similarly, apart from having a classical bit as part of its signature, e.g., defcal measure $0 ->bit .

To integrate with OpenQASM’s timing system when performing scheduling, the compiler requires the set of physical qubit resources used by the defcal implementation as well as the duration of its execution. The scheduler uses this information to resolve the scheduled circuit specified by the programmer. For this reason, all resolved defcal usages must have compile-time computable durations. If the duration of a defcal depends on its input parameters, the parameters and consequently the definition must be resolvable at compile-time to enable deterministic scheduling of the operations at the circuit level. Calibrations must also be independent of when the operation is invoked, to allow their substitution anywhere the corresponding circuit instruction is applied. Note that some instructions, such as a reset instruction implemented with measurement feedback, might require control flow. A calibration grammar should support such use cases while still guaranteeing the deterministic duration of the instruction.

OpenPulse Grammar.

OpenPulse was initially specified as a RESTful API system that was later extended with an implementation for Qiskit [13, 60]. Within the OpenQASM specification, the OpenPulse grammar provides a hardware-independent representation for programming qubits at the level of microwave pulses [2]. In a typical quantum computing system, control electronics apply stimulus in the form of time-varying pulses to hardware ports. These enact control fields upon the target quantum system. For example, in a superconducting qubit system, smooth pulse envelopes with a carrier frequency on resonance with the superconducting qubit are applied through an arbitrary waveform generator to excite the qubit from its ground state to its excited state. OpenPulse was originally designed to target superconducting qubit systems. In general, it captures the control requirements of quantum systems defined by a time-dependent Hamiltonian of the form \( H(t) = H_\mathrm{sys} + \sum _k \alpha _k(t)H_k \) where \( H_\mathrm{sys} \) is a time-independent drift Hamiltonian and \( H_k \) are control-fields modulated by the time-dependent control knobs \( \alpha _k(t) \) described within the OpenPulse program in the form of pulses emitted to hardware ports. This system model describes many quantum technologies such as ion traps, quantum dots, and neutral atoms [21, 72, 81]. For this reason, it is the canonical defcalgrammar provided within the OpenQASM3 specification.

In OpenPulse all operations fundamentally operate on a port which is a software abstraction representing any input or output component meant to manipulate and observe qubits. As they are uniquely defined by the target system they are declared as extern port d0. Ports are ultimately mapped to some combination of hardware resources. For instance, a port may directly correspond to a digital-to-analog converter. In the quantum system a port typically corresponds to a Hamiltonian term, \( H_k \) with pulses applied to the port defining the time-dependent \( \alpha _k(t) \) control-term. For instance, a port could apply a time-dependent voltage to a qubit, or manipulate the coupling between two neighboring qubits. Ports are both vendor and device specific.

To emit pulses that track the frame of the qubit OpenPulse introduces the frame as the canonical value to which pulses are applied. It is akin to the rotating frame of a Hamiltonian and is responsible for tracking two properties of pulses emitted on a port. Firstly, the frame represents a carrier signal \( e^{i\left(2\pi f t + \phi \right)} \), parameterized by a frequency \( f \) and phase \( \phi \). Frames are tracked throughout a circuit execution by the system’s runtime. Any modifications to a frame within a calibration entry will persist to calls to the same frame elsewhere in the circuit. In this way, it is analogous to a numerically controlled oscillator (NCO). One motivation for keeping track of accrued phase is to allow the natural implementation of the “virtual Z-gate”. This does not require a physical pulse but rather shifts the phase of all future pulses on that frame. When declared a frame is tied to a port. Frames may be defined both within the program scope — frame frd0 = newframe(d0, 5e9, 0.0); — or as an external linkage to plugin to existing calibration frameworks — extern frd0;. A frame contains two attributes, frequency and phase of types float and angle respectively. These may be set and modified through dot notation. For example, frd0.frequency = 4.9e9; frd0.phase += π; sets the frequency for a frame and increments the phase of the frame. These updates will occur at the current time of the frame. Multiple frames may be defined for each port effectively allowing multiplexing over a port’s IO for multiple carrier signals. Consequently, each frame maintains its pointer to an abstract internal clock which is incremented through operations such as play and barrier.

The following code sample demonstrates how to define an implementation of an rz gate for the physical qubit $0.

View Figure

In this example, the gate is realized by updating the frame tracking the qubits. All subsequent pulses that we apply to the frame will have an updated phase, allowing the implementation of the virtual Z-gate.

The manipulation of a port is channeled through the frame which provides a view on top of the port. The primary stimulus applied to a frame is the waveform type. These may be defined either as an array of complex samples which define the points for the waveform envelope — waveform arb_waveform = [1+0im, 0+1im, 0.5+0.5im]. Or as an extern declared waveform template representing a waveform, which will later be materialized into a list of complex samples, either by the compiler or the hardware — extern gaussian(complex[float] amp, duration d, duration sigma) -> waveform;. Waveforms are played on a frame through the play instruction

View Figure

The waveform is therefore emitted with a carrier defined by the frequency and phase of frd0 at the current time of frd0 on port d0. The frame is blocked during execution of the play operation, and its time is incremented by 160dt after execution completes.

It is also possible to calibrate the measure and reset operations. Due to the varied nature of readout protocols in quantum hardware we rely on vendors to define the appropriate external subroutines to access the readout chain. For example, an implementation of measure is shown below.

View Figure

OpenPulse’s timing model is relative. Within a program, there is no explicit reference to a global clock, but instead, only relative references to the starting time of a defcal/cal or the current relative time of other frames through the barrier instruction. This enables OpenPulse operations to be scheduled in a position-independent manner. Each defcal or cal block defines a relative zero-time, which is defined by when the OpenQASM scheduling layer schedules the execution of the block. When a frame is declared it is assigned an absolute time that is equal to the relative zero time for the enclosing block. Every frame used within a cal or defcal starts and ends with an implicit barrier across all used frames, establishing a unified start and end time for all frames within the block. The example below demonstrates the timing behaviour of OpenPulse with the implementation of an echoed cross-resonance gate [70].

View Figure

The example above demonstrates several additional features of the OpenPulse language. The notion and semantics of the barrier frd0, frd1, frd2, cr1_0; statement is borrowed from the circuit layer to allow the OpenPulse grammar extension to synchronize the time of all frames to a unique instant. A defcal may also call another defcal to construct a more sophisticated calibration as shown by the call of x $0;. Furthermore, the use of the external frame frd2 enables the calibration grammar to inform the circuit scheduler that qubit $2 is indirectly used by the gate. The scheduler is therefore made aware that the qubits are indirectly coupled. This allows it to avoid scheduling them simultaneously, such as the case where many qubits are coupled through a resonator bus.

5.3 Solving the Stretch Problem

We now describe how the compiler determines the values of stretch values, in contexts involving operations, with other duration values, and box statements. We treat duration values to be variables in a linear system of inequalities that the compiler must solve, subject to certain constraints. We call this problem the “stretch problem”. If we attempt to execute an OpenQASM circuit, a stretch solving algorithm must be applied to compute explicit durations for all delays.

Our goal is that any OpenQASM circuit with mapped qubits and defcals gives rise to a set of stretch problems that, if bounded and feasible, provides explicit timing for all operations within every basic block. The stretch problem is to determine definite values for all stretch values in a given scope — subject to constraints on gate ordering, such as those imposed by delay and barrier statements, and the range of optimization techniques — so that the operations performed on each qubit can be scheduled appropriately, and in particular take the same amount of time. The stretches get resolved to explicit delays in a single late-stage pass that solves the stretch problem, thereby specifying all delays and a complete schedule for the operations. We define the stretch problem in such a way that it is bounded, and has a unique optimum if it is feasible. If the problem is infeasible for a given target, a compiler error is issued, providing some insight about the unsatisfied constraints. In the case of a circuit without any stretchable delays, the stretch problem may be unsolvable in all but the most trivial cases.

The stretch problem is a lexicographic multi-objective linear programming problem [24], as follows: given a matrix \( A \) and vectors \( c_j \) and \( b \), lexicographically minimize \( c_1^\top x \), \( c_2^\top x, \ldots , c_m^\top x \) subject to \( Ax\le b \) and \( x\ge 0 \). This linear programming problem can be solved in polynomial time and efficiently in practice. For example, one may first solve “minimize \( c_1^\top x \) subject to \( Ax\le b \) and \( x\ge 0 \)” to obtain the cost \( \beta _1 \), then solve “minimize \( c_2^\top x \) subject to \( Ax\le b \), \( c_1^\top x=\beta _1 \), and \( x\ge 0 \)” to obtain the cost \( \beta _2 \), and for forth until all objectives are met. This is described in [24] and the references therein; multi-objective optimization is implemented in software such as CPLEX [25].

The stretch problem is formulated independently for each basic block or box \( \mathrm{B} \). The total duration of the block is mapped to some variable \( \mathrm{T} = x_0 \), which we wish to minimize. The block \( \mathrm{B} \) consists of instructions applied to qubits \( \mathrm{Q} \). An instruction is any task with a non-negative duration that involves a subset of qubits; the duration of each instruction is either known or unknown, and may be associated with variables \( x_1 \), \( x_2 \), and so on. To clarify the presentation of the stretch problem, imagine that each qubit \( q \in \mathrm{Q} \) is associated with a duration value \( D_q \) . The value of \( D_q \) is determined by the durations of operations and delays on \( q \), as well as constraints on when multi-qubit blocks can be performed (depending on the scheduling of operations on the that must come before, on each of the qubits involved). This defines \( D_q \) a function of the non-negative stretch variables \( x_i \). We then impose the constraint that \( x_0 = D_q \) for all \( q \in \mathrm{Q} \) . A feasible solution to this assigns durations to each stretch variable, ensuring that for each qubit \( q \in \mathrm{Q} \), the operations on \( q \) occur at some time \( t\in [0, \mathrm{T}] \). If we lexicographically minimize the variables \( x_i \), we single out a particular solution where, among other things, \( \mathrm{T} = x_0 \) is minimized.

For example, the code below inserts a dynamical decoupling sequence where the centers of pulses are equidistant from each other. The circuit is depicted in Figure 6. We specify correct durations for the delays by using backtracking operations to properly take into account the finite duration of each gate.

Fig. 6.

View Figure

View Figure

The stretch declarations impose the constraints: \( \texttt {s},\, \texttt {t},\, \texttt {r},\, \texttt {xlen},\, \texttt {ylen} \ge 0 \), \( \texttt {s}-\tfrac{1}{2}\,\texttt {xlen} \ge 0 \), \( \texttt {s} - \tfrac{1}{2}\,\texttt {xlen} - \tfrac{1}{2}\,\texttt {ylen} \ge 0 \), and \( \texttt {s} - \tfrac{1}{2}\,\texttt {ylen} \ge 0 \). Some additional constraints \( \texttt {xlen} \ge A \) and \( \texttt {ylen} \ge B \) are imposed by the target platform, where \( A \) and \( B \) are the minimum amount of time possible to realize the operations x $0 and y $0 respectively. Let \( x_{16} \), \( x_{17} \), and \( x_{18} \) denote the (fixed and not explicitly declared) durations of the operations on lines 16, 17, and 18. Then, we obtain the following durations of operations on qubits: (7) \( \begin{equation} \begin{aligned}D_{\texttt {q[0]}} \,&=\, 5\,\texttt {s}\,, \\ D_{\texttt {q[1]}} \,&=\, \texttt {t} + x_{17}\,, \end{aligned} \qquad \qquad \qquad \begin{aligned}D_{\texttt {q[2]}} \,&=\, x_{16} + x_{17}\,, \\ D_{\texttt {q[3]}} \,&=\, x_{16} + x_{18} + \texttt {r}\,. \end{aligned} \end{equation} \) By setting \( D_{\texttt {q[i]}} = \mathrm{T} \) for all \( \texttt {i} \), we obtain additional relationships and constraints on the durations above, specifically: (8) \( \begin{equation} \begin{aligned}\textrm {T} \,&=\, x_{16} + x_{17}, &\qquad \quad \texttt {s} \,&=\, \tfrac{1}{5}x_{16} + \tfrac{1}{5}x_{17}, &\qquad \quad \texttt {t} \,&=\, x_{16}, &\qquad \quad \texttt {r} \,&=\, x_{17} - x_{18}. \end{aligned} \end{equation} \) From the constraints on \( \texttt {s} \) and \( \texttt {r} \), this is feasible if \( x_{16} + x_{17} \ge \tfrac{5}{2}A + \tfrac{5}{2}B \) and \( x_{17} \ge x_{18} \) . The solution, which is obtained by the stretch problem in this case actually determines fixed values for \( \textrm {T} \), \( \texttt {s} \), \( \texttt {t} \), and \( \texttt {r} \), and sets \( \texttt {xlen} \) to its minimum value \( A \), and \( \texttt {ylen} \) to its minimum value \( B \).

Note that the order in which stretch variables are declared determine the order in which they are minimized. This can have a significant effect on scheduling. For a second example, consider the following code sample:

View Figure

Let \( x_4 \) and \( x_5 \) stand for the (fixed and not explicitly declared) durations of the operations on lines 4 and 5. We have (9) \( \begin{equation} \begin{aligned}\mathrm{lexmin}\ \texttt {a},\, \texttt {b},\, \texttt {c},\, \texttt {d}\ & \ \mathrm{s.t.,} \\ \texttt {a}, \texttt {b}, \texttt {c}, \texttt {d} & \ge 0, & \\ \texttt {a} + x_4 + \texttt {c} & = \texttt {b} + x_5 + \texttt {d}. \end{aligned} \end{equation} \) From this, optimising first for \( \texttt {a} \), then \( \texttt {b} \), and so forth, we would obtain \( \texttt {a} = \texttt {b} = 0 \), and either \( \texttt {c} = x_5 - x_4 \) and \( \texttt {d} = 0 \) if \( x_4 \le x_5 \), or \( \texttt {c} = 0 \) and \( \texttt {d} = x_4 - x_5 \) otherwise. This yields a left-aligned schedule. If we had instead declared stretch d, c, b, a; on line 1, we would have optimized the values in the opposite order (minimising first \( \texttt {d} \), then \( \texttt {c} \), etc.) to obtain a right-aligned schedule.

5.4 Multi-level Representation

In previous sections, we introduced the language features of OpenQASM, which can range from relatively high-level constructs such as multi-controlled gates to low-level timing and microcoded pulses. As such, OpenQASM is designed to be a multi-level intermediate representation, where the focus shifts from target-agnostic computation to concrete implementation as more hardware specificity is introduced.

An OpenQASM circuit can also mix different abstraction levels by introducing constraints where needed, but allowing the compiler to make decisions where there are no constraints. Examples of circuit constraints are tying a virtual qubit to a particular physical qubit, or left-aligning some parallel gates that have different durations.

We illustrate this point by considering timing constraints in an OpenQASM circuit. When a delay instruction is used, even though it implements the identity channel in the ideal case, it is understood to provide explicit timing. Therefore, an explicit delay instruction will prevent commutation of gates that would otherwise commute. For example, in Figure 7(a), there will be an implicit delay between the “cx” gates on qubit 0. However, the “rz” gate is still free to commute on that qubit, because the delay is implicit. Once, the delay becomes explicit (perhaps at lower stages of compilation), gate commutation is prohibited (Figure 7(b)).

Fig. 7.

View Figure

Fig. 8.

View Figure

Furthermore, even though stretch is used to specify constraints for the solver, its use in the circuit is like any other instruction. This has the benefit that design intents can be specified on a high-level circuit and the intent will be carried with the circuit, until resolved. The following example for simultaneous randomized benchmarking is an instance of this, where alignment is specified on general unitaries of the Clifford group, which may be decomposed into a variety of ways. In addition, the stretchiness can be included as part of the definition of a gate, in which case whenever that gate is expanded those stretch constraints will be automatically inserted.

6.1 Target-independent Compilation Phase

The target-independent phase applies transformations that do not use information about any particular target system. The goal of these transformations is quantum circuit synthesis and optimization.

Constant propagation and folding. This transformation substitutes the values of constants as they occur in expressions throughout the circuit. We repeatedly apply this transformation as constants are exposed.

Gate modifier evaluation and synthesis. The control, power, and inverse gate modifiers are replaced by gate sequences, and those are simplified when possible based on the structure of the circuit. In this case, the inverse and power modifiers can be simplified by modifying the angle arguments of the phase and controlled-phase gates. For this example, we replace the control modifier and phase gate by a cphase gate from the standard library to emphasize the transformation. For further emphasis, we also change the circuit notation, replacing a controlled unitary gate (raised to a power) by a two-qubit gate with two connected control dots and an angle label.

View Figure

Loop unrolling. The trip count of this loop is constant and statically known. Therefore, the loop can be unrolled. This is not necessary as the machine executing an OpenQASM circuit is assumed to have control flow capabilities. However, doing so in the compiler could expose certain optimization opportunities. For example, the following pass could remove the reset operation in the first iteration, because it is redundant with the initial circuit reset.

View Figure

Constant propagation and folding (repeat). We repeat this step to evaluate and substitute the value of the power variable.

Gate simplification. Gate simplification rules can be applied to reduce the gate count. In this example, rotations with angle 0 are identity gates and can be removed.

View Figure

6.2 Target-dependent Compilation Phase

The target-dependent phase applies transformations that are generically necessary to lower a target-independent OpenQASM 3 circuit to an executable. Each transformation uses information that is specific to a class of target machines, rather than one specific target, and the class of potential targets is refined with each transformation.

Basis translation. As we enter the next phase of compilation, we need to use information about the target system. The basis translation step rewrites quantum gates in terms of a set of gates available on the target. In this example, we assume a quantum computer with a calibrated set of basis gates including phase, h, and cx.

View Figure

Gate simplification (repeat). We repeat the gate simplification transformations to reduce the gate count. In this example, phase gates commute through the controls of CNOT gates and can be merged with other phase gates by adding the angle arguments.

View Figure

Physical qubit mapping and routing. In this step, we need to use the physical connectivity of the target device to map virtual qubits of the circuit to physical qubits of the device. In this example, we assume a CNOT can be applied between physical qubits 0 and 1 in either direction, so no routing is necessary.

View Figure

Scheduling. We can enforce a scheduling policy without knowing or using concrete gate durations. We use stretchy delays for this purpose, which enact a “as late as possible” schedule. The actual gate durations will be available in the next stage where the circuit is tied to certain gate calibration data, and the stretch problem can be solved.

View Figure

Calibration linking and stretch resolution. A pulse sequence is defined for each gate, reset, and measurement. Using their durations, the stretch variables are resolved into delays with concrete timing. Angles are rounded to the precision of the defcal arguments (i.e., to defcal precision) at this step, if they have not already been rounded to the appropriate precision by an earlier transformation.

View Figure

The compiled circuit is now submitted to the target machine code generator to produce binaries for the target control system of the quantum computer. These are then submitted to the execution engine to orchestrate the quantum computation. Additional phases of target-dependent compilation occur that are beyond the scope of OpenQASM 3.

7.1 Comparison to Other Quantum Programming Languages

There has been significant prior work on quantum programming languages and intermediate representations, some of which have directly influenced OpenQASM. Many high-level quantum programming languages are embedded in classical languages. For example, Scaffold [42], QCL [64], and qcor [59] are embedded in C or C++, Quipper [11] in Haskell, ProjectQ [9] in Python, and QIR [5] in LLVM. On the other hand, languages such as OpenQASM and Quil [73] are designed to be standalone and portable intermediate representations.

Classical control flow exists in many of the above languages. These are sometimes only used as a means of code compression (i.e., fully unrollable at compile time) [9, 42], and sometimes are intended to mix classical and quantum compute [10, 73]. In embedded languages, the host language provides direct access to classical types and control flow. OpenQASM 3 expands upon these by introducing new types such as angle, and allowing the semantic definition of purely classical extern functions in the context of real-time computation.

Gate modifiers (at least for “control”), exist in most of the above programming languages. In OpenQASM 3, we utilize these modifiers for two reasons. First, they decouple semantics from implementation — many implementations could exist for a particular modified gate. Second, modifiers in conjunction with two simple language built-ins (U gate and gphase), generate the entire standard gate library.

The use of timing and pulse-level control within quantum circuits has long been present in software and languages used for controlling experiments. Rigorous specifications for this were introduced for example in QGL [4], OpenPulse [60], eQASM [37], Artiq [19], Pulser [72], Jaqal [54], Qua [6], and Quil-t [7]. OpenQASM 3 takes this further by streamlining the incorporation of timing in the circuit model, by allowing timing constraints to be expressed at a level that is decoupled from actual pulse implementations (using stretch). This further motivated the inclusion of a scoping mechanism in OpenQASM 3 in the form of box, which allows references to specific blocks of code and to guide compiler optimizations. This has been addressed before in a more limited form using barriers [27] and pragmas [73].

7.2 Features Considered but Not Adopted

In this article, we have presented the design decisions in OpenQASM 3 and the rationale behind them. In a similar vein, multiple other language features were contemplated but abandoned or left for future revisions of the language. In the following, we briefly touch upon these.

Some languages such as Q# and ProjectQ support resource and memory management, in the form of mid-circuit allocation and de-allocation of qubits. Some languages such as Scaffold allow for the expression of classical code that will then be compiled to reversible quantum circuits (e.g., oracles). In each of these cases, OpenQASM intentionally remains lower-level and more grounded in executable circuits, aim at keeping the compiler’s complexity more manageable.

Conversely, some languages such as Quil have unstructured control flow in the form of explicit program labels and JUMP statements, which are in fact more in the style of a classical assembly language. In order to retain backwards compatibility with OpenQASM 2, we chose not to require any explicit entry points, preferring to allow the program to proceed from the first instruction in a global scope. OpenQASM 3 also adopted the use of for and while loops to express control flow, both to retain easier programmability by humans, and to allow for easier timing analysis by the compiler. These all motivated a design philosophy that it should not be necessary in OpenQASM 3 to manage the (classical) control flow, on a similarly low level to management of quantum operations and resources.

7.3 Considering Further Language Features for OpenQASM

The OpenQASM language will continue to evolve; however, within its governance model, and certain features may be added. An example of such a feature are unitary circuit families and generic subroutines, corresponding roughly to templated function definitions, which may be defined entirely in OpenQASM 3. (While such subroutines could be written in a separate host language, writing them in OpenQASM 3 allows for greater portability.) Another language feature, which is at an advanced stage of consideration at the time of writing it the inclusion of classical arrays as a container type; A third feature, which has been set aside, but has been re-proposed for consideration is a fixed-point real number type. The usefulness of such features, the way that they interoperate or conflict with other features, and how they may be incorporated into the language and supported as features is the subject of discussion in working groups established for this purpose. In this way, OpenQASM 3 will continue to evolve, incorporating features, which are sufficiently important and consistent with the other functionality which it provides, through input from the community.