Dynamic circuits FAQ


Where should I ask further questions?

Ask your questions in the Slack channel #dynamic-circuits in the Qiskit workspace.

Whom is dynamic circuit support available to?

All users with access to backends that support this capability. Primarily, this is limited to some exploratory system clients. You can verify if backend support is available by checking that qasm3 is present in backend.configuration().supported_features.

What are the primary use cases for dynamic circuits?

Dynamic circuits are critical for algorithms such as quantum error correction (QEC). In general, there are broad classes of quantum algorithms that exchange quantum resources for classical resources to construct exotic quantum channels.

Hardware Platforms

What systems have support for dynamic circuits?

Any backend reporting qasm3 in backend.configuration().supported_features.

Which systems will be supported?

Gradually support will be rolled out to most but not all deployed systems.

Can I upload my own custom runtime program that uses OpenQASM 3?

Yes, please see this tutorial. You can also access it as an interactive Jupyter notebook in IBM Quantum Lab.


Which gate types are supported?

Currently only direct drive single-qubit, and cross-resonance two-qubit gates are supported.

What circuit scheduling protocol is used on the backend?

The quantum circuit model only specifies the dependency graph for circuit operations that are applied to qubits. This means that the timing of circuit operations is not fully constrained unless the duration of all operations is known a priori and operations are applied within a program such that no qubits remain idle (including delays). To fully resolve this timing degree of freedom within a circuit, the compiler applies a scheduling policy. You may be familiar with scheduling policies in Qiskit.

Currently backends apply a default policy of ASAP (as-soon-as-possible) scheduling. This is different then the default ALAP (as-late-as-possible) scheduling policy applied by legacy backends by default. This may result in unexpected differences in circuit performance if you do not apply a scheduling policy at the Qiskit layer to select ALAP to fill scheduling degrees of freedom with delays. For example, the program below will yield poor results, as the qubit is excited immediately under ASAP rather than right before the measurement, as would be expected under ALAP scheduling.

x $0;
delay[1s] $1;
bit result = measure $0;

Currently there are limitations on what portions of your program may be scheduled. See below to learn more about these.

In the future we will support both scheduling procedures with the advent of the pulse dialect.

Can I do dynamical decoupling?

The full scheduling capabilities that are supported in Qiskit are not one-for-one available due to the implementation details of making measurement results available in real-time. You can schedule blocks of gates, and they will behave as expected up until a measurement occurs, which will trigger a non-deterministic delay, followed by the next deterministic gating section.

For example:

// qubit 0/1 relative time = 0
x $0; // qubit 0 at time 160, qubit 1 at time 0
delay[1600dt] $0; // qubit 0 at time 1760, qubit 1 at time 0
cx $0, $1; // qubit 0/1 at time 2360
measure $0; // Ends at some non-deterministic time
// start of next block, relative time = 0, absolute time = ???
x $0; // qubit 0 at relative time 160, absolute time = ??? + 160

Consider the circuit diagram below.

DD figure

It is possible to implement dynamical decoupling with delays as usual in the first block. Within the code generator, scheduling is currently based on lexical ordering of the input assembly-like code (OpenQASM 3 or MLIR), and the first measurement encountered triggers the end of a block of scheduled code. Therefore, it is possible to schedule operations on qubits that are not disjoint from a qubit under measurement, but these instructions must occur before the measurement in the assembly. For example:

// some scheduled gates on Q1/Q2
barrier $0, $1;
x $0; // occurs during the measurement
measure $1;
barrier $0, $1;

// some scheduled gates on Q1/Q2
barrier $0, $1;
measure $1;
x $0; // occurs after the measurement and classical processing
barrier $0, $1;

Development is in progress for adding Qiskit support for scheduling and dynamical decoupling with dynamic circuits. However, there will still be limitations on these capabilities due to fundamental hardware constraints.

Are parametric programs supported?

These are not yet supported (although defined within the OpenQASM 3 language). Support will be coming in 2023.

Can I submit multiple circuits at once?

You can submit multiple circuits at once to the qasm3-runner. These will be merged into a single circuit for execution with reset sequences separating each circuit and result post-processing to separate out the individual circuit’s results. See the runtime’s documentation for more information.

Are single/two-qubit gates performed in parallel across qubits?


Are measurements performed in parallel across qubits?

Yes, measurements that occur back-to-back in the assembly are applied in parallel. For example:

// In parallel
measure $0;
measure $1;

// Not in parallel
measure $0;
x $2;
measure $1;

How are resets implemented?

All resets use a conditional reset implementation with a single round of measurement/gating. As these require a conditional operation, there is currently a synchronization of the hardware required at the end of the reset which has an indeterministic duration.

Do resets take the same time as other conditional logic in the hardware?

No, resets use a fast path in the hardware. In general, any if statement with a test condition depending directly on a qubit measurement result, with block contents containing only operations applied to the qubit generating the measurement result, will not require synchronization in between (after a short delay between the measurement end and the start of gating).

// uses fast-path
bit result = measure $0;
if (result == 1){
    x $0;

// uses fastpath as decomposed to the above
// in the compiler
reset $0;

// does not use fast path
// however the result is already available
// from the previous synchronization above
// and no hardware synchronization is required
if (result == 1){
    x $0;

// does not use hardware fast-path
// as different qubits are used between
// measurement and gates. A global
// decision (slower) is instead required.
result = measure $0;
if (result == 1){
    x $1;

Do resets occur in parallel?

If the reset test conditions follow a parallel measurement, they will occur in parallel along the fast-path.

// In parallel along fastpath
bit res0 = measure $0;
bit res1 = measure $1;

if (res0 == 1) {
    x $0;
if (res1 == 1) {
    rz(3.15) $1;

// Not in parallel along fastpath
// As measurements are not in parallel
bit res0 = measure $0;
x $2;
bit res1 = measure $1;

if (res0 == 1) {
    x $0;
if (res1 == 1) {
    rz(3.15) $1;

Are my qubits initialized for me?

Yes, see the qasm3-runner runtime program’s documentation for more information on how the qubits are initialized and how to configure the behavior.

Are nested measurements in control-flow possible?

Not currently. This will be fixed later in 2022.

The circuit quality of my dynamic circuits are worse than through the standard Qiskit path.

This could be a bug! Please report it to the #dynamic-circuits Slack channel in the Qiskit workspace. There are several known issues, such as serial measurements, and qubit initialization.

Will hardware support OpenQASM 3 floating point types?

Initially, real-time floating point types will not be supported. When support is added, it will begin will constant floating types, which may be handled at compile time. If real-time support is added, classical calculations involving floats will be slow, as it will be necessary to use soft math. Initially, real-time floats will likely be used as inputs to gate arguments, such as in the case of measurement-dependent rotation angles.

OpenQASM 3

Where can I learn more about OpenQASM 3?

See the specification and the white paper.

What OpenQASM 3 capabilities are currently supported?

See the feature support page for more information.

Why does the backend not support OpenQASM 3 with non-physical qubits, gate definitions, scheduling, etc.?

OpenQASM 3 was designed conceptually as a multi-level IR. The backend compiler is designed to accept input that is specified at the last layer of this IR (the physical layer) and is designed to work on physical quantum circuits. It is more akin to a quantum assembler (e.g., to execute as faithfully as possible the program you specify) for a quantum computer and its control systems - not a full-fledged language compiler. To that end, it is designed to work with Qiskit/other intermediate quantum optimization toolchains that may target it as output and know that what they emit is what will be executed. For now we would recommend optimizing your circuits first in Qiskit with its transpiler to lay out the circuit for the target basis gates and coupling map.

Can I use pulse with OpenQASM 3?

No, the pulse support development is in progress. This will support gate calibrations in the presence of control-flow in a scalable and expressible way. The user interface from OpenQASM will be based on the OpenPulse Grammar.

Can I submit textual OpenQASM 3 programs instead of Qiskit circuits?

Yes, you may replace the input quantum circuits with a list of OpenQASM 3 source programs. These must follow a specific format, as described here.

How must OpenQASM 3 source programs be structured?

Input OpenQASM 3 source programs have these limitations:

  • All operations must use physical qubits, eg., cx $0, $1;.

  • No symbolic algebra is supported, e.g., pi/2.

  • Must only use the backend’s basis gates (use the Qiskit transpiler to perform this conversion).

  • Limited capabilities are supported.

Are barriers being parsed properly from Qiskit down to the hardware?


Are delays being parsed properly from Qiskit down to the hardware?

Yes, delays on qubits are currently supported with units of dt, us, ms and s.

Will every identical classical operation take the same amount of time in a circuit?

It is reasonable to assume that the same classical condition will take the same amount of time to evaluate, on average, when it occurs multiple times in the circuit. While the control system is deliberately designed to reduce them, there are still sources of (small) nondeterminism, so that the actual execution time may differ slightly between each occurrence.

Is there a way to find out after the fact how long each fast-forward operation took?

There is currently no mechanism to gather that information from Qiskit. We can collect timing information for a limited scope, ie., there is not the capability to record an entire execution, but only a small section of one. This capability is limited to internal users.


Why are classical capabilities limited in Qiskit?

Qiskit was not originally designed to support dynamic circuits. These features were initially tacked on, and an extensive re-design is currently in progress. Consequently, the user-facing APIs and transpiler support are limited. At times we may require the usage of specific Qiskit releases and/or Git branches to enable rapid development of new dynamic circuit capabilities.

How are results returned?

Results are currently returned through the standard Qiskit result object. This does not necessarily align with the OpenQASM 3 input/output model, and work is underway to fix this.