Gates¶
In OpenQASM we refer to unitary quantum instructions as gates.
Applying gates¶
Every gate applies to a fixed number of qubits.
Assuming g0
, g1
, g2
, … are gates defined on 0, 1, 2, … qubits then they can be applied as
g0;
g1 q1;
g2 q1, q2;
g3 q1, q2, q3;
Broadcasting¶
If any arguments of a gate are quantum registers instead of qubits, then all such registers must be of the same length and this syntax is a convenient shorthand for broadcasting over the qubits of the register. For example, the circuit
qubit[1] qr0;
qubit[3] qr1;
qubit[2] qr2;
qubit[3] qr3;
g4 qr0[0], qr1, qr2[0], qr3; // ok
g4 qr0[0], qr2, qr1[0], qr3; // error! qr2 and qr3 differ in size
has a second-to-last line that is equivalent to
g4 qr0[0], qr1[0], qr2[0], qr3[0];
g4 qr0[0], qr1[1], qr2[0], qr3[1];
g4 qr0[0], qr1[2], qr2[0], qr3[2];
Use of this syntax constitutes a promise to the compiler that the expanded set of broadcasted gates
is mutually commuting and thus the compiler can take advantage of the opportunity to reorder the
gates freely for optimization purposes. In certain cases a compiler might be able to detect a
non-commutativity and raise a warning, but it is not required to do so in all cases. If the gates do
not commute and a specific order is required by the programmer, than a for
loop may be used to
set that order.
Parameterized gates¶
As well as gates that each represent a fixed unitary, OpenQASM also supports gates that represent families of unitaries, parameterized by angle variables. To distinguish the (optional) angle parameters from the (required) quantum arguments, if any angle parameters are present they must appear before any quantum arguments, and be delimited by parentheses. For example
fsim(θ, ϕ) q[0], q[1];
Defining gates¶
There are 3 mechanisms to construct new gates:
A new named gate can be introduced by a hierarchical definition from a sequence of existing gates;
Anonymous new gates may be defined by applying gate modifiers to existing gates;
The built-in gates comprising the one-qubit gate
U(θ, ϕ, λ)
and the zero-qubit gategphase(γ)
. The definitions of these gates is part of the language specification.
The built-in standard library of OpenQASM 3 includes several gate definitions for convenience.
The next subsections go through these cases.
Hierarchical gates definitions¶
The gate
statement associates an identifier with a corresponding unitary matrix (or parameterized family)
transformation by a sequence of other (built-in or previously-defined) gates.
For example the gate
block
gate h q {
U(π/2, 0, π) q;
gphase -π/4;
}
defines a new gate called h
and associates it to the unitary matrix of the Hadamard gate. Once we have
defined h
, we can use it in later gate
blocks.
The definition does not imply that h
is
implemented by an instruction U(π/2, 0, π)
on the quantum computer. The implementation is up to
the user and/or compiler, given information about the instructions supported by a particular target.
A minimal compiler implementation might simply expand gate
definitions repeatedly until reaching
definitions for which defcal blocks are known. A more sophisticated implementation
might use the gate definitions of the gates with associated defcal
blocks to
build a gate library, and use methods based on KAK decompositions to rewrite into this hardware library.
The gate
statement also allows defining parameterized families of unitaries. For example, a CPHASE
operation is shown schematically in Fig. 1
and the corresponding OpenQASM code is
gate cphase(θ) a, b
{
U(0, 0, θ / 2) a;
CX a, b;
U(0, 0, -θ / 2) b;
CX a, b;
U(0, 0, θ / 2) b;
}
cphase(π / 2) q[0], q[1];
Again, this definition does not imply that cphase
must be implemented with
this particular series of gates. Rather, we have specified the unitary
transformation that corresponds to the symbol cphase
. The particular
implementation is up to the compiler, given information about the basis
gate set supported by a particular target.
In general, new gates are defined by statements of the form
gate name(params) qargs
{
body
}
where the optional parameter list params
is a comma-separated list of variable
parameters, and the argument list qargs
is a comma-separated list of qubit
arguments. The parameters are identifiers that behave as angle
type with unknown
size. A compiler might recognize certain constructs and replace them with mathematically-
equivalent versions that would be true for arbitrary precision, or it might do calculations
at a fixed angle
size, for example corresponding to the size of angle
parameters in the corresponding
defcal
definitions.
The qubit arguments are identifiers. If there are no
variable parameters, the parentheses are optional. The arguments in qargs
cannot be indexed within the body
of the gate definition.
// this is ok:
gate g a
{
U(0, 0, 0) a;
}
// this is invalid:
gate g a
{
U(0, 0, 0) a[0];
}
Only built-in gate statements and calls to previously defined gates can appear in body
.
For example, it is not valid to
declare a classical register in a gate body. Looping constructs over these quantum
statements are valid.
The statements in the body can only refer to the symbols given in the parameter or argument list, and these symbols are scoped only to the subroutine body.
An empty body corresponds to the identity gate.
To avoid infinite recursion, gates must be declared before use and
cannot call themselves. The statement name(params) qargs;
applies the gate,
and the variable parameters params
can have any type that can promote to angle
type.
Quantum gate modifiers¶
A gate modifier is a keyword that applies to a gate. A modifier \(m\) transforms a gate \(U\) to a new gate \(m(U)\) acting on the same or larger Hilbert space. We include modifiers in OpenQASM both for programming convenience and compiler analysis.
Control modifiers¶
The modifier ctrl @
replaces its gate argument \(U\) by a
controlled-\(U\) gate. If the control bit is 0, nothing happens to the target bit.
If the control bit is 1, \(U\) acts on the target bit. Mathematically, the controlled-\(U\)
gate is defined as \(C_U = I \otimes U^c\), where \(c\) is the integer value of the control
bit and \(C_U\) is the controlled-\(U\) gate. The new quantum argument is prepended to the
argument list for the controlled-\(U\) gate. The quantum argument can be a register, and in this
case controlled gate broadcast over it (as for all gates). The modified
gate does not use any additional scratch space and may require compilation to be executed.
As a limiting case, the controlled global phase gate
ctrl @ gphase(a)
is equivalent to the single-qubit gate U(0, 0, a)
.
// Define a controlled Rz operation using the ctrl gate modifier.
// q1 is control, q2 is target
gate crz(θ) q1, q2 {
ctrl @ rz(θ) q1, q2;
}
The modifier negctrl @
generates controlled gates with negative polarity, ie conditioned on a
controlled value of 0 rather than 1. Mathematically, the negative controlled-\(U\) gate is
given by \(N_U = I \otimes U^{1-c}\), where \(c\) is the integer value of the control bit
and \(N_U\) is the negative controlled-\(U\) gate.
// Define a negative controlled X operation using the negctrl gate modifier.
// q1 is control, q2 is target
gate neg_cx(θ) q1, q2 {
negctrl @ x q1, q2;
}
ctrl
and negctrl
both accept an optional positive integer parameter n
, specifying the
number of control arguments (omission means n=1
). n
must be a compile-time constant. For an N
qubit operation,these operations are mathematically defined as
where \(c_1\), \(c_2\), …, \(c_n\) are the integer values of the control bits and \(C^n_U\) are the n-bit controlled-\(U\) and n-bit negative controlled-\(U\) gates, respectively.
// A reversible boolean function
// Demonstrates use of ``ctrl(n) @`` and ``negctrl(n) @``
qubit[3] a;
qubit[2] b;
qubit f;
reset f;
ctrl(3) @ x a[1], a[0], a[2], f;
negctrl(3) @ ctrl @ x a[0], b[1], a[2], b[0], f;
negctrl @ ctrl(2) @ negctrl @ x a[0], b[0], a[2], a[1], f;
negctrl(2) @ ctrl @ x b[1], a, b[0], f;
Inverse modifier¶
The modifier inv @ U
replaces its gate argument \(U\) with its inverse
\(U^\dagger\). This can be computed from gate \(U\) via the following rules
The inverse of any gate \(U=U_m U_{m-1} ... U_1\) can be defined recursively by reversing the order of the gates in its definition and replacing each of those with their inverse \(U^\dagger = U_1^\dagger U_2^\dagger ... U_m^\dagger\).
The inverse of a controlled operation is defined by inverting the control unitary. That is,
inv @ ctrl @ U = ctrl @ inv @ U
.The base case is given by replacing
inv @ U(θ, ϕ, λ)
byU(-θ, -λ, -ϕ)
andinv @ gphase(a)
bygphase(-a)
.
// Define a negative z rotation and the inverse of a positive z rotation
gate rzm(θ) q1 {
inv @ rzp(θ) q1;
}
// Equivalently, this can be written as
gate rzm(θ) q1 {
rzp(-θ) q1;
}
Power modifier¶
The modifier pow(k) @
replaces its gate argument \(U\) by its \(k\)th
power \(U^k\) for some positive integer or floating point number \(k\) (not necessarily
constant). In the case that \(k\) is an integer, the gate can be implemented (albeit
inefficiently) by \(k\) repetitions of \(U\) for \(k > 0\) and \(k\)
repetitions of inv @ U
for \(k < 0\).
// define x as the square of sqrt(x) ``sx`` gate
gate x q1 {
pow(2) @ sx q1;
}
Built-in gates¶
- gate U(θ, ϕ, λ) a¶
The built-in single-qubit gate
U
represents the unitary matrix\[\begin{split}U(\theta,\phi,\lambda) := \frac{1}{2}\left(\begin{array}{cc} 1+e^{i\theta} & -ie^{i\lambda}(1-e^{i\theta}) \\ ie^{i\phi}(1-e^{i\theta}) & e^{i(\phi+\lambda)}(1+e^{i\theta}) \end{array}\right).\end{split}\]This definition is \(2\pi\)-periodic in each of the parameters θ, ϕ, λ and specifies any element of \(U(2)\) up to a global phase [1] . For example
U(π/2, 0, π) q[0];
, applies a Hadamard gate to qubitq[0]
(up to a non-standard global phase).
- gate gphase(γ) ¶
The global phase gate.
From a physical perspective, the unitaries \(e^{i\gamma}V\) and \(V\) are equivalent although they differ by a global phase \(e^{i\gamma}\). When we add a control to these gates, however, the global phase becomes a relative phase that is applied when the control qubit is one. A built-in global phase gate allows the inclusion of arbitrary global phases on circuits. The instruction
gphase(γ);
accumulates a global phase of \(e^{i\gamma}\).Just as every n-qubit gate can be thought of as generating a tensor product with the suitable identity matrix to cover all other qubits in the gate, subroutine, or global scope containing the instruction, similarly
gphase
behaves as a 0-qubit gate and when applied in a context with m qubits in scope, behaves as applying the unitary\[\operatorname{gphase}(\gamma) := e^{i\gamma} I_m,\]where \(I_m\) denotes the identity matrix with size \(2^m\)
For example
gate X q { U(π, 0, π) q; gphase -π/2; } gate CX c, t { ctrl @ X c, t; }
defines
CX
as the standard CNOT gate.
Relation of the built-in gates to hardware-native gates¶
For non-parameterized gates, the choice of U
and gphase
as the built-in gates, along with one
two-qubit entangling gate CNOT as defined gives a universal gate set that can represent general n-qubit
unitaries with an \(O(2^n)\) size description [BBC+95]. This basis is not an enforced compilation
target but a mechanism to define other gates. For many gates of
practical interest, there is a circuit representation with a polynomial
number of one- and two-qubit gates, giving a more compact representation
than requiring the programmer to express the full \(2^n \times 2^n\)
matrix. However, a general \(n\)-qubit gate can be defined using an
exponential number of these gates. Thus there is no particular privilege incurred by hardware implementations
that natively support the built-in gates.
For parameterized gates, the choice of built-in gates does constrain which hardware-native gates are well- supported, because conversion between parameterized basis sets in general can be involved, requiring careful selection of branch cuts and other logic that would not likely be feasible to specify as compact mathematical expressions, nor to evaluate at runtime for cases where the parameters depend on quantum measurements.
For many current platforms the qubits are defined relative to a
rotating frame and the rotating wave approximation (RWA) holds. This is the domain covered by the OpenPulse
specification. For this case, the only supported form of run-time parameterization
will likely be via a rz
implemented by specialized frame-tracking hardware.
This gate is covered by the built-in U
as a special case U(0, 0, ϕ)
However, if other forms of run-time parameterization become important, it may be necessary to revise OpenQASM,
to give meaning to those gates, for example by adding new basis gates or additional gate
definition syntax.