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 filtering provider.backends(dynamic_circuits=True). To view the simulators and systems supporting dynamic circuits that you can access, click here (requires the user to be logged in to IBM Quantum).

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.

What systems have support for dynamic circuits?¶

Any backend reporting support in the provider provider.backends(dynamic_circuits=True).

Which systems will be supported?¶

Gradually support will be rolled out to most but not all deployed systems depending on control-system capabilities.

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 ALAP (as-late-as-possible) 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 reset or control-flow (if/else/for/while) transition occurs, which will trigger a non-deterministic delay, followed by the next deterministic gating section.

For more information on how to use dynamical decoupling with dynamic circuits, see the Dynamic Circuit scheduling support in the Qiskit IBM Provider.

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.

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

Yes.

Are measurements performed in parallel across qubits?¶

Yes, measurements that occur are independent when topologically ordered within a code-block are applied in parallel. For example:

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

// 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 the control-flow operations
// do not directly follow
// their measurement
bit res1 = measure $1;
barrier $1;
bit res0 = measure $0;

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

Are my qubits initialized for me?¶

Yes, see the Qiskit IBM Provider documentation for available run options

Are nested measurements in control-flow possible?¶

Yes, you are able to use measurements within control-flow to conditionally measure gates and apply conditional operations based on the measurement outcome. Currently you cannot retrieve the measurement result of conditional measurements; this will be resolved in 2023.

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.

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.

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, see Dynamic Circuits basics with OpenQASM 3.

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?¶

Yes.

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.