Circuit timing¶
A key aspect of expressing code for quantum experiments is the ability to control the timing of gates and pulses. Examples include characterization of decoherence and crosstalk, dynamical decoupling, dynamically corrected gates, and gate scheduling. This can be a challenging task given the potential heterogeneity of calibrated gates and their various durations. It is useful to specify gate timing and parallelism in a way that is independent of the precise duration and implementation of gates at the pulse-level description. In other words, we want to provide the ability to capture design intent such as “space these gates evenly to implement a higher-order echo decoupling sequence” or “implement this gate as late as possible”.
Duration and stretch types¶
The duration type is used denote increments of time. Durations are real numbers
that are manipulated at compile time. Durations must be followed by time units which can be
any of the following:
SI units of time:
ns, µs or us, ms, sBackend-dependent unit,
dt, equivalent to the duration of one waveform sample on the backend
Units can appear attached to the numerical value, or immediately following
separated only by blanks or tabs. 1000ms is the same as 1000 ms.
It is often useful to reference the duration of other parts of the
circuit. For example, we may want to delay a gate for twice the duration
of a particular sub-circuit, without knowing the exact value to which
that duration will resolve. Alternatively, we may want to calibrate a
gate using some pulses, and use its duration as a new duration in order to delay
other parts of the circuit. The durationof() intrinsic function can be used for this
type of referential timing.
Below are some examples of values of type duration.
// fixed duration, in standard units
duration a = 300ns;
// fixed duration, backend dependent
duration b = 800dt;
// fixed duration, referencing the duration of a calibrated gate
duration c = durationof({x $3;});
We further introduce a stretch type which is a sub-type of duration. Stretchable durations
have variable non-negative duration that are permitted to grow as necessary
to satisfy constraints. Stretch variables are resolved at compile time
into target-appropriate durations that satisfy a user’s specified design
intent.
Instructions whose duration are specified in this way become “stretchy”,
meaning they can extend beyond their “natural duration” to fill a span of
time. Stretchy delay’s are the most obvious use case, but this can be extended
to other instructions too, e.g. rotating a spectator qubit while another
gate is in progress. Similarly, a gate whose definition contains stretchy
delays will be perceived as a stretchy gate by other parts of the
program.
a
b
Fig. 4 Arbitrary alignment of gates in time using stretchy delays. a) left-justified alignment b) alignment of a short gate at the 1/3 point of a longer gate.¶
For example, in order to ensure a sequence of gates between two barriers will be left-aligned (Fig. 4a), whatever their actual durations may be, we can do the following:
qubit[5] q;
barrier q;
cx q[0], q[1];
U(pi/4, 0, pi/2) q[2];
cx q[3], q[4];
stretch a;
stretch b;
stretch c;
delay[a] q[0], q[1];
delay[b] q[2];
delay[c] q[3], q[4];
barrier q;
We can further control the exact alignment by giving relative weights to the stretchy delays (Fig. 4b):
qubit[5] q;
stretch g;
barrier q;
cx q[0], q[1];
delay[g];
u q[2];
delay[2*g];
barrier q;
The concepts of box (see Boxed expressions) and stretch are inspired by the
concept of “boxes and glues” in the TeX language [KB84]. This similarity
is natural; TeX aims to resolve the spacing between characters in order
to typeset a page, and the size of characters depend on the backend
font. In OpenQASM we intend to resolve the timing of different
instructions in order to meet high-level design intents, while the true
duration of operations depend on the backend and compilation context.
There are however some key differences. Quantum operations can be
non-local, meaning the durations set on one qubit can have side effects on
other qubits. The definition of duration-type variables and ability to define
multi-qubit stretches is intended to alleviate potential problems from
these side effects. Also contrary to TeX, we prohibit overlapping gates.
Operations on durations¶
We can add/subtract two durations, or multiply or divide them by a constant, to get a new
duration. Division of two durations results in a machine-precision float
(see Converting duration to other types). Negative durations are allowed, however
passing a negative duration to a gate[duration] or box[duration] expression will result in an error.
All operations on durations happen at compile time since ultimately all
durations, including stretches, will be resolved to constants.
duration a = 300ns;
duration b = durationof({x $0;});
stretch c;
// stretchy duration with min=300ns
stretch d = a + 2 * c;
// stretchy duration with backtracking by up to half b
stretch e = -0.5 * b + c;
Delays (and other duration-based instructions)¶
OpenQASM and OpenPulse have a delay instruction, whose duration is defined by
a duration. If the duration passed to the delay contains stretch, it will become a
stretchy delay. We use square bracket notation to pass these duration
parameters, to distinguish them from regular parameters (the compiler
will resolve these square-bracket parameters when resolving timing).
Even though a delay instruction implements the identity operator in the ideal
case, it is intended to provide explicit timing. Therefore an explicit delay
instruction will prevent commutation of gates that would otherwise
commute. For example in
Fig. 5a , there will be an
implicit delay between the cx gates on qubit 0. However, the rz gate is
still free to commute on that qubit, because the delay is implicit. Once
the delay becomes explicit (perhaps at lower stages of compilation),
gate commutation is prohibited (Figure Fig. 5b).
a
b
Fig. 5 Implicit vs. explicit delay. a) An implicit delay exists on \(q[0]\), but it is not part of the circuit description. Thus this circuit does not care about timing and the \(RZ\) gate is free to commute on the top wire. b) An explicit delay is part of the circuit description. The timing is consistent and can be resolved if and only if this delay is exactly the same duration as \(RY\) on \([1]\). The delay is like a barrier in that it prevents commutation on that wire. However \(RZ\) can still commute before the \(CNOT\) if it has duration \(0\).¶
a
b
Fig. 6 Dynamically corrected CNOT gate where the spectator has a rotary pulse. The rotary gates are stretchy, and the design intent is to interleave a “winding” and “unwinding” that is equal to the total duration of the CNOT. We do this without knowledge of the CNOT duration, and the compiler resolves them to the correct duration during lowering to the target backend.¶
Fig. 7 Dynamical decoupling of a spectator qubit using finite-duration DD pulses. The boxes are intentionally drawn to scale to give a sense of how finite gate durations affect circuit timing. This design intent can be expressed by defining a single stretch variable “equal” that corresponds to the distance between equidistant gate centers. The other durations which correspond to actual circuit delays are derived by simple arithmetic. Given a target system with calibrated X and Y gates, the solution to the stretch problem can be found.¶
Instructions other than delay can also have variable duration, if they
are explicitly defined as such. They can be called by passing a valid duration as
their duration. Consider for example a rotation called rotary that is applied
for the entire duration of some other gate.
const amp = /* number */;
stretch a;
rotary(amp)[250ns] q; // square brackets indicates duration
rotary(amp)[a] q; // a rotation that will stretch as needed
A multi-qubit delay instruction is not equivalent to multiple single-qubit
delay instructions. Instead a multi-qubit delay acts as a synchronization
point on the qubits, where the delay begins from the latest non-idle
time across all qubits, and ends simultaneously across all qubits.
cx q[0], q[1];
cx q[2], q[3];
// delay for 200 samples starting from the end of the longest cx
delay[200dt] q[0:3];
A duration can be composed of positive or negative durations, and of
positive stretches. After resolving the stretches, the instruction must end
up with non-negative duration.
For example, the code below inserts a dynamical decoupling sequence where the *centers* of pulses are equidistant from each other. We specify correct durations for the delays by using backtracking operations to properly take into account the finite duration of each gate.
stretch a;
stretch b;
duration start_stretch = a - .5 * durationof({x $0;});
duration middle_stretch = a - .5 * duration0({x $0;}) - .5 * durationof({y $0;});
duration end_stretch = a - .5 * durationof({y $0;});
delay[start_stretch] $0;
x $0;
delay[middle_stretch] $0;
y $0;
delay[middle_stretch] $0;
x $0;
delay[middle_stretch] $0;
y $0;
delay[end_stretch] $0;
cx $2, $3;
delay[b] $1;
cx $1, $2;
u $3;
Boxed expressions¶
We introduce a box statement for scoping the timing of a particular part of the circuit.
A boxed subcircuit is different from a gate or def subroutine, in that it is merely
an enclosure to a piece of code within the larger scope which constrains it. This can be used to
signal permissible logical-level optimizations to the compiler: optimizing operations within
a box definition is permitted, and optimizations that move operations from one side to
the other side of a box are permitted, but moving operations either into or out of the box as
part of an optimization is forbidden. The compiler can also infer a description of the
operation which a box definition is meant to realise, allowing it to re-order gates around
the box. For example, consider a dynamical decoupling sequence inserted in a part of the circuit:
rx(2*π/12) q;
box {
delay[ddt] q;
x q;
delay[ddt] q;
x q;
delay[ddt] q;
}
rx(3*π/12) q;
By boxing the sequence, we create a box that implements the identity. The compiler is now free to commute a gate past the box by knowing the unitary implemented by the box:
rx(5*π/12) q;
box {
delay[ddt] q;
x q;
delay[ddt] q;
x q;
delay[ddt] q;
}
The compiler can thus perform optimizations without interfering with the implmentation of the dynamical decoupling sequence.
As with other operations, we may use square brakets to assign a duration to a box: this can be
used to put hard constraints on the execution of a particular sub-circuit by requiring it to
have the assigned duration. This can be useful in scenarios where the exact duration of a piece
of code is unknown (e.g., if it is runtime dependent), but where it would be helpful to impose
a duration on it for the purpose of scheduling the larger circuit. For example, if the duration
of the parameterized gates mygate1(a, b), mygate2(a, b) depend on values of the variables
a and b in a complex way, but an offline calculation has shown that the total will never
require more than 150ns for all valid combinations:
// some complicated circuit that gives runtime values to a, b
box [150ns] {
delay[str1] q1; // Schedule as late as possible within the box
mygate1(a, a+b) q[0], q[1];
mygate2(a, a-b) q[1], q[2];
mygate1(a-b, b) q[0], q[1];
}
Barrier instruction¶
The barrier instruction of OpenQASM 2 prevents commutation and gate reordering
on a set of qubits across its source line. The syntax is barrier qregs|qubits; and can be seen
in the following example
cx r[0], r[1];
h q[0];
h a[0];
barrier r, q[0];
h a[0];
cx r[1], r[0];
cx r[0], r[1];
This will prevent an attempt to combine the CNOT gates but will not
constrain the pair of h a[0]; gates, which might be executed before or after the
barrier, or cancelled by a compiler.
A barrier is similar to delay[0]. The main difference is that delay indicates a fully
scheduled series of instructions, whereas barrier implies an ordering constraint that will be
resolved by the compiler at a later stage.
A barrier can also be invoked without arguments, in which case the argument is assumed to be all qubits.