PaperlayerView exact revision on arXiv

Source-linked AI summary

Qiskit Backend Specifications for OpenQASM and OpenPulse Experiments

David C. McKay, Thomas Alexander, Luciano Bello, Michael J. Biercuk, Lev Bishop, Jiayin Chen, Jerry M. Chow, Antonio D. Córcoles, Daniel Egger, Stefan Filipp, Juan Gomez, Michael Hush, Ali Javadi-Abhari, Diego Moreda, Paul Nation, Brent Paulovicks, Erick Winston, Christopher J. Wood, James Wootton, Jay M. Gambetta

arXiv:1809.03452v1quant-phcs.ET

TL;DR

Quantum computing needs standardized interfaces and language support for both gate-based operations and continuous-time experiment control. The paper specifies Qiskit backends, the Qobj data structure, and OpenQASM/OpenPulse representations, with OpenPulse supporting hardware-agnostic pulse-level control. The specification excludes fully generic classical processing, closed-loop feedback, and longer-timescale device reconfiguration.

  • Problem

    Quantum computing requires a common specification for algorithm designers, circuit designers, and physicists, including language support beyond gates for describing experiment time dynamics.

  • Method

    The paper specifies Qiskit backend interfaces, a schema-validatable Qobj JSON structure, and OpenQASM and OpenPulse experiment representations.

  • Results

    OpenPulse provides hardware- and implementation-agnostic pulse-level control of continuous quantum-device dynamics across a broad class of devices.

  • Takeaways & Limitations

    The specification lets users express abstract gate-based experiments and continuous-time pulse operations through a common backend interface.

  • Takeaways & Limitations

    Fully generic classical processing, closed-loop feedback, and device reconfiguration on timescales longer than one experiment are outside the specification’s scope.

Abstract

from arXiv · show

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.

1 Introduction

Qiskit addresses the need for a common interface and data specification spanning quantum algorithms, circuit design, physics, devices, and simulators. The document defines Qobj-based experiment exchange while delimiting operations outside the specification’s scope.

  • 1 Introduction: Qiskit supports algorithm designers, circuit designers, and quantum physicists working with real devices and simulators.These users investigate algorithms, optimize circuits and gates, and study noise, dynamical decoupling, and optimal control.
  • 1 Introduction: Qobj is a self-contained JSON structure that defines complete OpenQASM or OpenPulse experiments for backend execution.Its schema-based format can be validated before execution.
  • 1 Introduction: OpenPulse enables users to specify exact experiment time dynamics and measurements for cloud-access quantum devices.The document distinguishes users writing OpenPulse experiments from Qiskit contributors and backend providers.
  • 1 Introduction: The specification organizes Qiskit APIs, OpenQASM and OpenPulse experiment formats, and examples for device and simulator use.The document covers API calls, configuration data structures, OpenQASM experiments, and OpenPulse specifications.
  • 1 Introduction: Fully generic classical processing, closed-loop feedback, and device reconfiguration beyond one experiment are outside the specification’s scope.Such capabilities may be added as case-by-case extensions.

2 Qiskit API

The Qiskit API defines interoperable provider, backend, job, and experiment objects for running quantum experiments on devices and simulators. Backend and gate configurations describe capabilities, connectivity, conditionals, latency, and OpenPulse support.

  • API organization: The API organizes providers, backends, Qobjs, and jobs so users can configure experiments, execute them, monitor status, cancel runs, and retrieve results.A backend run validates the Qobj against general and backend-specific schemas before creating the job.
  • Experiment languages: Qiskit represents experiment sequences through OpenQASM gates, measurements, and conditionals or OpenPulse continuous-time operations and measurements.Memory stores measurement output for readout, while fast registers support feedback and OpenPulse can return richer measurement data.
  • Backend interface: A backend interface exposes device or simulator configuration and status, with optional OpenPulse support and properties such as locality, simulation, configurability, and conditional execution.Backend configuration also specifies qubit count, basis gates, coupling maps, registers, register maps, and supported gates.
  • Gate configuration: Gate configurations specify supported qubits, OpenQASM definitions, parameters, conditional behavior, latency maps, and descriptions for each gate.The coupling map identifies where a gate applies, while the latency map records fast or slow feedback to registers.

2.4 Job

A job is an accepted backend experiment identified by a provider-unique job ID and backed by a Qobj containing experiment sequences and configuration. Job methods support status tracking, cancellation, and result retrieval.

  • Job lifecycle: A job represents a submitted and accepted experiment that may be queued, running, or completed, and it is created from a Qobj structure.The job exposes its identifier and associated backend through job methods.
  • Qobj structure: A Qobj includes an identifier, experiment type, schema version, experiment list, job-level header, and configuration settings.Its type distinguishes QASM from PULSE experiments, while experiments run in listed order and repeat until the requested shots are collected.
  • Experiment structure: Each experiment structure contains user metadata, experiment-specific configuration, and an instruction sequence for OpenQASM or OpenPulse.Experiment configuration overrides job-wide settings, and headers pass through unchanged to results.
  • Run configuration: User configuration specifies shots and memory slots, with optional simulator seeds and maximum credits for credit-based backends.Memory records measurement results for readout and cannot be used for feedback, which uses registers instead.
  • Control and retrieval: Job status reports identifiers, lifecycle states, and backend messages, while cancellation removes queued jobs or stops running jobs and can prevent credit deduction.Additional job methods return whether a job is done, running, or cancelled.
  • Control and retrieval: Job.result() may block until all measurement data is available or return data incrementally as backend storage is consumed.The retrieval behavior is backend specific and may reflect data-caching or bandwidth constraints.

2.5 Result Data Structure

The result data structure identifies the backend, Qobj, job, and experiments, and records status, success, metadata, and returned experiment data. Measurement outputs can include counts, memory, simulator state, unitaries, and snapshots.

  • Result organization: A result object records backend identifiers, Qobj and job IDs, execution date, job metadata, status, success, and a list of experiment results.The results list contains one experiment result structure for each experiment in the Qobj.
  • Experiment results: Each experiment result reports shots, status, success, propagated headers, optional seeds, measurement-return mode, and experiment data.The measurement-return mode distinguishes averaged data from data returned for each shot in OpenPulse or snapshot workflows.
  • Experiment results: Shot counts may be a single integer or a two-element range when asynchronous or segmented result retrieval is used.For a range [n1,n2], the returned data covers s = n2 − n1 shots, and the next call starts at n2 + 1.
  • Measurement data: Measurement data may be returned as nonzero-state count histograms, per-shot classical memory, a final statevector, a final unitary, or simulator snapshots.Counts use hexadecimal state labels, while memory contains hexadecimal strings for OpenQASM and OpenPulse Level 2 results.
  • Measurement data: Snapshots group simulator data by snapshot type and label, representing simulator state information at the point where each snapshot command occurs.Snapshot types and schemas are specified separately for simulators.

3 OpenQASM Representation as a Quantum Object (Qobj) Data Structure

The specification maps OpenQASM circuits into Qobj experiment sequences without redefining OpenQASM. It flattens registers into Qobj memory and fast registers and defines commands for gates, feedback, synchronization, reset, measurement, copying, and snapshots.

  • Qobj representation: OpenQASM-to-Qobj conversion parses circuit commands into an execution-oriented format and maps multiple quantum and classical registers into single Qobj registers.The classical register is separated into slow memory for readout and fast registers for feedback.
  • Command set: Qobj OpenQASM sequences reserve commands including bfunc, copy, reset, barrier, measure, and snapshot, with name as the generally required field.These commands encode both quantum operations and classical control within an experiment sequence.
  • Classical control: A boolean-function command masks register bits, compares the masked value with a target, and writes the Boolean result to a register and optionally memory.The resulting register value can control conditional commands.
  • Classical control: A copy command duplicates one register slot into one or more destination register slots.The source and destination slots are specified separately in the command structure.
  • Quantum commands: Gate instructions identify the gate, target qubits, optional parameters, and optional conditional register, while barriers enforce temporal ordering for specified qubits.Gate definitions may include parameter values and conditional feedback when supported.
  • Quantum commands: Reset returns listed qubits to the ground state, and measurement projects specified qubits while writing results to memory and optionally fast registers.Memory destinations must match the measured qubits, and later writes to the same memory slot overwrite earlier measurements.
  • Simulator commands: Simulator-only snapshots record labeled simulator-state data at specified command positions, with snapshot types defined in a separate simulator specification.The snapshot command supplies a label and type for identifying returned data.

4 OpenQASM Qobj Examples

The Qobj examples show how OpenQASM experiments encode circuits, configurations, conditional operations, and measurement outputs for Bell states, teleportation, and repetition-code experiments.

  • Qobj structure: Qobj packages experiment metadata, configuration, and a list of OpenQASM experiments, with shots and memory slots specified at the batch level.The examples use schema version 1.0 and identify experiments through qobj_id, type, header, config, and experiments fields.
  • Bell states: The Bell-state results concentrate counts on the correlated outcomes expected for each prepared state, with smaller counts in the other outcomes.For the first experiment, counts are 450, 10, 20, and 520; for the second, they are 5, 510, 480, and 5 across the listed hexadecimal outcomes.
  • Teleportation: The teleportation Qobj uses joint measurements and conditional operations on Q2 to transfer Q0’s state, while storing the first Q0 and Q1 measurements in memory.The example assumes two feedback register slots and no conditions on feedback or measurement to those registers.
  • Teleportation: The teleportation results are approximately evenly distributed across the four two-bit outcomes in 1000 shots.The reported counts are 250, 220, 260, and 270.

5 OpenPulse Specification

OpenPulse extends Qiskit with hardware-agnostic pulse-level control over continuous quantum dynamics, including timed pulse sequences, readout processing, and simple measurement-conditioned feedback.

  • Scope and motivation: OpenPulse specifies pulse-level control for general quantum devices using complex-valued envelopes relative to user-adjustable global clocks.It is designed to support superconducting qubits, solid-state spins, trapped ions, and NV centers, with single-meter qubit measurements.
  • Scope and motivation: The specification targets experiments beyond OpenQASM, including decoupling schemes, calibrations, pulse shaping, optimal control, and user-defined gate-to-pulse mappings.Devices may provide calibrated pulse libraries, estimated system parameters, and mappings from gates to pulse sequences as starting points.
  • Measurement and feedback: OpenPulse exposes raw readout envelopes and supports simple measurement-conditioned feedback, enabling construction of readout kernels and discriminators and active qubit reset.The interface includes drive and measurement stimulus channels for each qubit, with optional U channels depending on the device.
  • Experiment representation: An OpenPulse experiment is a timed sequence of predefined pulses across channels, with pulse start times discretized in the device-defined unit dt.The pulse library is sent through the API, and the device may provide default pulses and typical OpenQASM-derived sequences.
  • Measurement and feedback: Measurement acquisition commands store outputs in user-selected memory slots, with Level 1 returning kernel-processed complex numbers and Level 2 returning discriminated qubit states.Level 2 results can be pushed to registers so drive pulses can be applied conditionally on register bits.
  • Backend interaction: The backend interface lets users load Qobj experiments, query status, stream measurement memory when supported, and run multiple experiments concurrently by shots.Figure 3 summarizes device specifications, user pulse-library and setting inputs, acquisition into classical memory, and Level 2 masking of drive pulses.

5.1 Additional API Calls

OpenPulse backends expose device-specific configuration, defaults, Hamiltonians, readout processing options, pulse libraries, and timing information through additional API structures.

  • Backend configuration: OpenPulse backend configuration adds measurement levels, LO ranges, input and output discretizations, repetition times, multiplexing maps, channel bandwidths, kernels, discriminators, and latency data.The configuration also includes optional acquisition and conditional latencies, which supersede earlier register and gate latency maps.
  • Backend configuration: Configuration data can describe U-channel count, a Hamiltonian, U-channel local oscillators, measurement options, timing values, multiplexing, bandwidths, and latency arrays.The example includes meas_levels, dt 1.3333, dtm 10.5, and repetition times [100,250,500,1000].
  • Backend defaults: Backend.defaults() supplies estimated qubit and measurement frequencies, a pulse buffer, a default pulse library, an OpenQASM-to-OpenPulse command definition, and default kernel and discriminator choices.The pulse library may reflect the latest calibration or a default estimate, helping avoid calibration-run bottlenecks.
  • Hamiltonian specification: The Hamiltonian data structure provides machine-readable and human-readable descriptions through parsable terms, variables, oscillators, and a required LaTeX string.It must specify coupling and control-channel operation using Pauli or ladder operators, while qubit frequencies come from qubit_freq_est.
  • Kernel and discriminator specification: Kernel and discriminator structures identify named readout-processing functions and their default parameters, but the API does not formally specify their internal behavior.A boxcar kernel averages the measurement output, while max_1Q_fidelity thresholds the IQ plane into states 0 and 1.
  • Pulse library: Pulse libraries represent predefined pulses by unique names and sample arrays that are referenced in OpenPulse command sequences.The pulse library is the basis for specifying experiments as sequences of predefined pulses.

5.2 Experiment Sequence Commands

OpenPulse defines timed commands for driving, changing frames, holding values, and acquiring measurements, with optional conditional behavior and backend-specific processing.

  • Command types: OpenPulse experiment sequences support drive pulses, frame changes, persistent values, and acquisition commands.Drive pulses specify library name, start time, channel, and optional conditional execution; frame changes advance subsequent pulse phases, while persistent values hold until replaced.
  • Input pulses: Drive pulses identify a pulse-library entry, integer-dt start time, target channel, and optional register-based condition.The conditional applies when level-2 measurement and backend conditionals are supported.
  • Frame changes: Frame changes apply an independent phase advance to subsequent pulses on a channel, with time, channel, and phase specified.The phase is expressed in radians and its allowable precision is device specific.
  • Persistent values: Persistent-value pulses hold a complex channel value until the next pulse, including across experiments when the device permits it.Channels return to zero after a Qobj completes, and the value magnitude is bounded by 1.
  • Acquisition: Acquisition commands specify measurement timing, qubits, memory slots, and optional kernels, discriminators, and register slots.Kernels and discriminators determine level-1 and level-2 processing; identical-time acquisitions may share acquired data but can be unsupported by a device.
  • Acquisition: Kernel and discriminator application follows the qubit order, while a single listed function may process multi-qubit data jointly.Devices document whether multi-qubit processing is supported, and acquisition count or spacing may be limited.

5.3 Time Sequence Specification

OpenPulse represents an experiment as a time-ordered sequence of action items, supporting drive and measurement operations, acquisitions, persistent outputs, and feedback between measurements.

  • Sequence structure: An OpenPulse experiment is a time-ordered list of action items defining pulses, frame changes, measurements, and acquisitions.The specification illustrates sequences combining qubit drives, measurement stimuli, and acquisition commands.
  • Feedback: A sequence can include two acquisitions and condition a later pulse on the register result from the first acquisition.The feedback example writes the first measurement to a register before applying the conditional pulse.
  • Channel behavior: Between pulses on one channel, the output is zero unless a persistent-value pulse holds a specified value until another pulse occurs.

5.4 Measurement Output

OpenPulse measurement output has three processing levels: raw signal samples, kernel-derived complex IQ values, and discriminator-derived computational states.

  • Output levels: OpenPulse defines Level 0 raw output, Level 1 kernel-processed complex IQ output, and Level 2 discriminator-processed qubit states.Devices need not support all three levels.
  • Level 0: Level 0 returns the downconverted measurement-output envelope as amplitude points sampled at equal dtm intervals.The output can be averaged or retained per shot, with memory organized by shots, slots, and slot size.
  • Level 0: Level 0 output is high-bandwidth and memory-intensive, and all measurements must have the same length.The specification recommends using this level sparingly and in averaging mode.
  • Level 1: Level 1 applies a selected or default kernel to Level 0 data and returns a complex IQ number for each memory slot.The kernel converts the output measurement pulse into a complex value.
  • Level 2: Level 2 applies a kernel and discriminator to output a computational-basis state, producing a histogram comparable to OpenQASM results.Level-2 measurements can also write to registers and support pulse masks based on register values.

6 Example Configurations for OpenPulse

The examples show OpenPulse backend configurations describing diverse hardware models, control channels, measurement capabilities, timing parameters, and Hamiltonians.

  • Backend configuration: Backend configuration examples expose device metadata, supported measurement levels, timing units, channels, gates, kernels, discriminators, and Hamiltonians.The examples also pair configurations with backend defaults such as frequency estimates, buffers, pulse libraries, and command definitions.
  • Fixed-frequency qubits: Fixed-frequency qubits coupled through fixed-frequency buses are modeled with cross-resonance control lines, multiplexed measurements, and available OpenPulse levels.The example specifies two qubits, two additional control lines, up to 1 GHz drive bandwidth, and one kernel and discriminator.
  • Tunable qubits: The tunable-qubit example represents flux control around DC and exposes device-set DC flux biases through the returned Hamiltonian information.Its configuration includes separate measurement maps and channel bandwidths for the tunable controls.
  • Tunable buses: The tunable-bus example models two flux control knobs for difference- and sum-frequency driving while retaining separate measurement lines.Its backend configuration includes corresponding u-channel local-oscillator scales and bandwidths.
  • Ion trap: The ion-trap example supports only level-2 fluorescence detection, uses a default kernel, and describes three ions coupled through Raman-beam motional modes.The specification states that this information can be used to construct a Mølmer–Sørensen gate.
  • NMR: The NMR example represents three qubits with multiple LO frequencies on one drive coil and one receiver coil, with measurement drive implemented as filtering.The example notes that the global magnetic field must be conveyed outside the specification and that timescales are greatly increased.

7 Sample Pulse Libraries for OpenPulse

The section presents Black Opal pulse-library examples that implement robust X operations using Gaussian-segmented controls and evaluates them with filter functions.

  • Pulse library examples: Black Opal provides sample pulse-library entries in the JSON format required by OpenPulse.The examples are created with the Black Opal package and illustrated in the accompanying figure.
  • Pulse library examples: The “walsh gaussian” control implements a net X operation robust against dephasing, overrotation, and phase errors.It uses Walsh functions and discretized Gaussian segments optimized for the device’s sample timing.
  • Pulse formats and filter functions: Figure 4 shows drive amplitude and phase on the left, and corresponding filter functions on the right, for controls built with fixed segment durations.The controls are scaled to an arbitrarily selected duration of 40 µs for laboratory-frequency units.
  • Pulse library examples: The “BB1 gaussian” control implements a net X operation robust against driving-strength fluctuations and pulse-timing errors.Its varying rotation axes are represented by complex-valued samples for the x and y driving components.
  • Pulse formats and filter functions: Lower filter-function values indicate lower noise susceptibility for the two controls.The filter function is presented as a heuristic measure of noise susceptibility.

8 Sample Experiments for OpenPulse

The section demonstrates OpenPulse experiments through a Rabi oscillation example and shows how Qobj configurations, pulse sequences, and measurement results are represented across measurement levels.

  • Rabi experiment setup: The examples use a Rabi oscillation experiment that varies drive amplitude at three points: 0, 0.5, and 1.0, with amplitude 1.0 treated as a π-pulse.The backend configuration includes OpenPulse support and provides device, measurement, and pulse-control metadata.
  • Rabi experiment setup: The pulse library contains two Gaussian drive pulses with peak amplitudes 1.0 and 0.5, plus a square measurement pulse.The experiment sequences apply these pulses at different amplitudes before acquisition.
  • Qobj execution: A single Qobj packages the three experiments, pulse library, measurement settings, local-oscillator frequencies, repetition time, and five shots.The experiment is submitted with Backend.run(Qobj), and results are retrieved with Job.result().
  • T1 experiment: The section also introduces a T1 experiment whose experiment dictionaries align measurement pulses while varying the preceding control sequence.The example uses “pulse2” as a π pulse and includes calibration, wait, and acquisition sequences.
Loading 1809.03452v1…