A New OpenQASM for a New Era of Dynamic Circuits
By Thomas Alexander, Lev Bishop, Andrew Cross, Jay Gambetta, Ali Javadi-Abhari, Blake Johnson, and John Smolin
As system designers and developers, we make tools suited to the needs of the moment. Over time, our needs change and our tools must evolve with them. We have reached such a moment for the language used to describe circuits in Qiskit: OpenQASM. It is time for an upgrade.
The initial OpenQASM spec, version 2, eschewed many possible features to focus on the core need of describing circuits that could be executed on early quantum systems. It provided a generic mechanism for describing static circuits, that is circuits without classical control flow¹. This is certainly an important (and large!) family of circuits, with sufficient expressibility for most textbook quantum algorithms. From another perspective, though, it is quite constrained. Representing circuits in OpenQASM2 is effectively like setting up a collection of dominoes that you will later knock over — everything must be done in advance and once the dominoes start to fall, it is too late to make changes.
The broader family of dynamic circuits allows for the interaction of real-time classical computation with the gates and measurements of static circuits. Eventual fault-tolerant quantum computers will require dynamic circuits to describe the interaction of classical decoders and qubits in quantum error correction schemes. In the near term, there are already interesting use cases for teleportation and new algorithms like iterative phase estimation and repeat until success that require real-time classical processing.
There are other constraints of OpenQASM2 that we wish to address. For instance, sometimes a gate-level description of a circuit is too high-level. We may need to specify the signals on the control wires attached to the quantum processor. This need motivated the OpenPulse spec. However, today’s Qiskit users are forced to choose between the world of pulses and the world of gates, while blending the two is common in calibration and characterization use cases.
OpenQASM2 is also timing unaware. It contemplates an abstract machine model of unitary transformations and measurements on qubits. Again, however, there are frequent use cases such as coherence measurements (inversion recovery, Ramsey sequences, etc.) and all flavors of dynamical decoupling where having control over timing in a gate-level description is desired. These techniques have been shown to be critical in improving the performance of IBM’s quantum computers.
It is with these use cases in mind that we have a proposed OpenQASM3. Designed for a next-generation of quantum computing hardware that interfaces the classical and quantum regimes, OpenQASM3 proposes a multi-level programming model that will allow the dynamic exploration of quantum systems. In internal development for over a year, we now need your input. Like the name says, OpenQASM3 is open-source. We have already collected feedback from several providers of quantum control and quantum hardware solutions. The initial response has been quite positive. For instance, Moritz Kirste of Zurich Instruments says, “to work on circuit level and yet have full access to sample level in the control hardware is ground breaking. We are thrilled to bring OpenQASM 3.0 to our quantum computing control system.”
We encourage you to check out the full specification, and give us feedback or make contributions so we can make quantum computing better, together.
Learn more about our vision for faster, more efficient quantum computation here.
[1]: The one exception is the ‘if’ keyword which can conditionally execute a single gate.
