[Paper Review] Qiskit Backend Specifications for OpenQASM and OpenPulse Experiments

David McKay, Thomas Alexander+18 more|arXiv (Cornell University)|Sep 10, 2018

Quantum Computing Algorithms and Architecture1 references108 citations

TL;DR

This paper defines a standard interface and data structures (Qobj) for running OpenQASM and OpenPulse experiments on Qiskit-compatible backends, enabling standardized communication with simulators and devices and introducing OpenPulse for pulse-level control.

ABSTRACT

As interest in quantum computing grows, there is a pressing need for standardized API's so that algorithm designers, circuit designers, and physicists can be provided a common reference frame for designing, executing, and optimizing experiments. There is also a need for a language specification that goes beyond gates and allows users to specify the time dynamics of a quantum experiment and recover the time dynamics of the output. In this document we provide a specification for a common interface to backends (simulators and experiments) and a standarized data structure (Qobj --- quantum object) for sending experiments to those backends via Qiskit. We also introduce OpenPulse, a language for specifying pulse level control (i.e. control of the continuous time dynamics) of a general quantum device independent of the specific hardware implementation.

Motivation & Objective

• Provide a common API for Qiskit-compatible backends (simulators and hardware).
• Define a standardized Qobj data structure for sending quantum experiments.
• Introduce OpenPulse for pulse-level control independent of hardware implementation.
• Specify how OpenQASM experiments are represented as Qobj data structures.
• Outline backend configuration, properties, defaults, and status information for robust execution.

Proposed method

• Define a provider-backend-job architecture with methods: get_backend, available_backends, run, status, result, and cancel.
• Describe the Qobj data structure for both QASM and PULSE experiments and its validation via schemas.
• Specify OpenQASM representation as a Qobj with experiment sequences and instruction commands (gate, barrier, reset, measure, snapshot).
• Detail the OpenPulse specification including backend configuration, Hamiltonian specification, pulse library, and time-sequence control.
• Provide example configurations, gate configurations, and sample OpenPulse experiments to illustrate usage.

Experimental results

Research questions

• RQ1 How can backends (simulators and hardware) be interfaced through a common API in Qiskit?
• RQ2 What data structures (Qobj) and schemas are needed to represent OpenQASM and OpenPulse experiments for execution and result retrieval?
• RQ3 How can OpenPulse enable pulse-level control across different quantum devices while remaining backend-agnostic?
• RQ4 What are the required and optional backend configuration, properties, and defaults necessary to support OpenQASM and OpenPulse experiments?

Key findings

• A unified Qiskit API model is established, coordinating Provider, Backend, Job, Qobj, and Result to enable concurrent experiment execution.
• A self-contained Qobj JSON structure is defined to encapsulate complete experiments in either OpenQASM or OpenPulse, with schemas for validation.
• OpenQASM experiments are represented within Qobj using a defined set of sequence commands (gate, measure, barrier, reset, copy, boolean function, snapshot) and memory/register handling.
• OpenPulse is introduced as a language for specifying continuous-time dynamics and pulse-level control, with detailed backend configuration, defaults, and pulse library integration.
• The specification supports various backends (devices or simulators) and outlines how results may include measurement data, state vectors, unitary matrices, and snapshots.