Open quantum assembly language (OpenQASM 2) [1] was proposed as an imperative programming language for quantum computation based on earlier QASM dialects [2–6]. OpenQASM is one of the programming interfaces of the IBM Quantum services [7]. In the period since OpenQASM 2 was introduced, it has become something of a de facto standard, allowing a number of independent tools to inter-operate using OpenQASM 2 as the common interchange format. It also exists within the context of significant other activity in exploring and defining quantum assembly languages for practical use [8–13]. These machine-independent languages describe quantum computation in the quantum circuit model [14–16]. Quantum assembly languages are considered low-level programming languages, yet they are not often directly consumed by quantum control hardware. Rather, they are further compiled to lower-level instructions that operate at the level of analog signals for controlling quantum systems. QASM can be hand-written, generated by scripts (meta-programming), or targeted by higher-level software tools.
Our goal is to extend OpenQASM to express classical processing in quantum programs. When OpenQASM was introduced, the language features were essentially limited to a piece of straight line code, i.e. a basic block1 The extension considered here is intended to be backwards compatible with OpenQASM 2, except in some uncommonly used cases where breaking changes were necessary. Recognizing that OpenQASM is a resource for describing programs that characterize, validate, and debug quantum systems, we also introduce instruction semantics that allow control of gate scheduling in the time domain and the ability to describe the microcoded implementations of gates in a way that is both extensible to future developments in quantum control and is platform agnostic.
In extending OpenQASM to include classical processing, we allow for a richer family of computation that incorporates interactive use of a quantum processor in a program or algorithm. However, we do not wish to reinvent all of classical computing. Rather, we recognize different timescales of quantum-classical interactions including real-time classical
computations that must be performed within the coherence times of the qubits as well as near-time computations with less stringent timing. The real-time computations are critical for error correction and circuits that take advantage of feedback or feedforward. However, the demands of the real-time, low-latency domain might impose considerable restrictions on the available compute resources in that environment, such as limited memory or clock speeds. Whereas with the near-time domain we may assume more generic compute resources, including access to a broad set of libraries and runtimes. Consequently, we choose in OpenQASM 3 to limit our focus to the real-time domain which must be most tightly coupled to the execution of gates and measurement on qubits.
We use a dataflow model [17] where each instruction may be executed by an independent processing unit when its input data becomes available. Concurrency and parallelism are essential features of quantum control hardware. For example, parallelism is necessary for a fault-tolerance accuracy threshold to exist [18, 19], and we expect concurrent quantum and classical processing to be necessary for quantum error-correction [20–22].
Our extended OpenQASM language expresses a program, or any equivalent representation of it, as instances of quantum circuits and their associated classical control, i.e. as a collection of (quantum) basic blocks and flow control instructions. This differs from the role of a high-level language. High-level languages may describe programs that generate families of quantum circuits. They make use of external circuit libraries and mathematical software. They may include mechanisms for quantum memory management and garbage collection, or features to specify classical reversible programs to synthesize into quantum oracle implementations. Optimization passes at this high level work with families of quantum operations whose specific parameters might not be known yet. These passes could be applied once at this level and benefit every program instance we execute later. High-level intermediate representations may differ from OpenQASM until we reach the circuit generation phase of program execution, at which point we generate a specific program instance.
Our choice of features to add to OpenQASM is guided by use cases. Although OpenQASM is not a high-level language, many users would like to write simple quantum programs by hand using an expressive domain-specific language. Researchers who study circuit compiling need high-level information recorded in the intermediate representations to inform the optimization and synthesis algorithms. Experimentalists prefer the convenience of writing programs at a relatively high level but often need to manually modify timing or pulse-level gate descriptions at various points in the program. Hardware engineers who design the classical controllers and waveform generators prefer languages that are practical to compile given the hardware constraints. Our choice of language features is intended to acknowledge all of these potential audiences.
Research areas
