Design and implementation of a quantum compiler

Tzvetan S. Metodi and Samuel D. Gasster

The Aerospace Corporation
2350 El Segundo Blvd., El Segundo CA 90245, USA

ABSTRACT
We present a compiler for programming quantum architectures based on the Quantum Random Access Machine
(QRAM) model. The QRAM model consists of a classical subsystem responsible for generating the quantum
operations that are executed on a quantum subsystem. The compiler can also be applied to trade studies
for optimizing the reliability and latency of quantum programs and to determine the required error correction
resources. We use the Bacon-Shor [[9, 1, 3]] quantum error correcting code as an example quantum program that
can be processed and analyzed by the compiler.

Keywords: quantum computer, quantum compiler

1. INTRODUCTION
In this paper, we present a compiler designed for the Quantum Random Access Machine (QRAM)1 model, which
is an extension of the classical random access machine.2 The QRAM model has become a widely accepted model
for quantum computers with recently several published examples.3, 4 What has not been discussed, however,
is a clear description of how these architectures can be programmed. The compiler is a tool that allows us to
program these architectures and also to analyze the resources necessary for implementing large-scale quantum
applications using these architectures. As the design of these QRAM-based architectures and physical quantum
components continues to improve, such analysis tool can help engineers in bridging the gap between higher-level
system requirements and low-level device capabilities.

sequence of physical
Classical Subsystem quantum operations Quantum Subsystem
(Hardware/Software) measurement results (Quantum Hardware)

Figure 1. The QRAM model for executing quantum algorithms

As shown in Figure 1, the QRAM model consists of a classical subsystem responsible for generating sequences
of quantum operations to be executed on a separate quantum subsystem. The classical subsystem does all
compilation of the high-level quantum program and any classical pre-processing and post-processing computations
needed by quantum algorithms. The quantum subsystem provides quantum hardware resources to the system in
the form individually addressable physical qubits and logic gates. The classical subsystem communicates with
the quantum subsystem by processing and analyzing the results of quantum measurements of individual qubits.
The compiler is a software program that is stored and executed by the classical subsystem. Its purpose is to
automate the process of transforming a quantum program written in a high-level computer programming language
to the physical operations that are to be executed in the quantum subsystem through several transformation
stages. The automation of this process makes modeling of a full-scale quantum application (complete with fault-
tolerant quantum error correction) feasible since such a model will require the orchestration of many millions of
qubit interactions at each step in the transformation of the program and is not possible to develop by hand. In
addition to mapping a quantum program to a device technology, the compiler is designed for several types of
analyses, including:

Quantum Information and Computation VIII, edited by Eric J. Donkor, Andrew R. Pirich, Howard E. Brandt,
Proc. of SPIE Vol. 7702, 77020S · © 2010 SPIE · CCC code: 0277-786X/10/$18 · doi: 10.1117/12.852548

Proc. of SPIE Vol. 7702 77020S-1

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 Error Correcting Codes and Specifications
Qapp Source Code Logical Architecture Complete Physical Gate Specs (Reliability/Speed)
Physical Device Architecture

Front End (Precompiler) Assembler Back End (Assembly Legalization)

- Qapp Syntax/Semantic - Map first-order error correction circuit to

Analyzer (Parser) - Translate program to quantum
physical device architecture, generating
- Generate Quantum assembly the physical representation of the Qasm
Intermediate Representation -Make the assembly program (logic gates/ qubits = logical
- Optimize the QIR for qubits QIR representation consistent with Qasm gates/qubits) QPR
and gates the logical architecture - Assess logical gate reliability
- Map second (and higher) order error
correction circuits to logical architecture

Figure 2. The three quantum compiler components: Front End (pre-compiler), Assembler, and the Back End (assembly
legalization) and the quantum program compilation flow

• Analyze the reliability and latency of the program execution in order to understand the design trade-offs
at each stage of the compilation process that allow us to maximize reliability and minimize latency
• Quantify the impact of including quantum error correction in terms of the number of resources required
and overall system performance
• Calculate the fault-tolerant threshold failure probability for quantum programs written for fault-tolerance.
The networks for quantum error correcting codes are examples of such programs.
• Analyze top level algorithm execution requirements on the quantum circuit to understand how they trans-
late into specific performance requirements on the physical components
• Quantify the performance of the physical implementation and how this performance might be optimized.
The performance parameters of interest are resource requirements, execution time and circuit failure prob-
ability.

The quantum compiler design follows the standard design of classical compilers,5 which have two well-defined
components: a front end and a back end (Cooper, et al., Page 5 for definitions6 ) ∗ . This design allows us
to take advantage of existing classical compiler techniques and algorithms during each transformation stage of
the quantum program. Figure 2 illustrates the compilation flow as well as the compiler components. As can
be seen in this figure, we have added an additional component, the Assembler. The assembler is responsible
for assembling a representation of the program using a universal set of logic gates that can be implemented
fault-tolerantly. The function of each of the three compiler components can be summarized as follows:

1. Front End (Pre-compiler): The pre-compiler’s function is to translate a human readable high-level speci-
fication of a quantum circuit into a machine readable intermediate representation. The intermediate rep-
resentation allows initial device independent analysis and optimization of the circuit. Part of the analysis
performed by our compiler in the front end is to determine if error correction is necessary.
2. Assembler: After the pre-compiler, the program enters the assembler, whose function is to map the inter-
mediate representation of the circuit into an equivalent low-level representation composed of a universal set
of logic gates, which can be implemented fault-tolerantly. The low-level representation which is generated
by the assembler is the quantum assembly code, analogous the classical assembly code and can be sent to
the back end for legalization.
∗
We note that the organization of our compiler follows loosely the conceptual quantum compiler described by K. Svore,
et al. [7], and for consistency, we have adopted many of the same abbreviations.

Proc. of SPIE Vol. 7702 77020S-2

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 3. Back End (Assembly Legalization): The back end consists of the final code generator (i.e., assembly
legalization), whose function is to map the assembly-level representation onto the device architecture. The
resulting code is ready to be executed directly on a quantum computer or by a device-level simulator.

The remainder of the paper is organized as follows. Section 2 describes the compiler front end, including the
high-level programming language. This section also includes the example implementation of the [[9, 1, 3]] Bacon-
Shor quantum error correcting code.8, 9 Section 3 briefly describes the assembler and the application of the
Solovay-Kitaev algorithm to decompose an arbitrary single-qubit quantum gate into a sequence of quantum gates
which can be implemented fault-tolerantly. Section 4 describes the back end legalization and implementation on
a target physical architecture. Section 5 provides our conclusions.

2. FRONT END: PRE-COMPILER

The front end of the compiler transforms a high-level language specification of a quantum algorithm into a
Quantum Intermediate Representation (QIR). The input to the front end is the quantum program written in
Qapp (for quantum application), which we developed as a programming language that makes the mapping to
an intermediate representation possible. In Subsection 2.1, we describe the Qapp language and its properties
and in Subsection 2.2, we describe the mapping to QIR. An important property of the front end is that all of its
operations are independent of any specific quantum device implementation. This enables the compiler to target
multiple physical device technologies by keeping the front end constant and changing only the back end.

2.1 The Qapp Programming Language

The design of the Qapp programming language is based on the circuit model of quantum computation.10 The
circuit model describes a quantum program as a discrete sequence of unitary quantum gates acting on one or
more qubits. It is a universal model for quantum computation and can be used to efficiently express any quantum
algorithm.11

U2 start_main:
start_function U2 {qreg Q(4)}:
qreg U2 qreg A(4);
bit (x=1);
A U1 U4 qreg B(3);
while (x <= 4)
U2 creg C creg C(3);
qgate U2( Q[x] );
U2 call_function U1 {A};
alu x = x + 1;
call_function U2 {A};
U3 c1 call_function U3 {A[3:4], B}; end_while
qreg call_function U4 {A}; end_function;
B c2 call_function MeasureB {B, C};
c3 end_function;

(a) (b)

Figure 3. (a) Example quantum circuit, quantum registers, and classical registers; (b) Implementation of the given circuit
in Qapp

An example quantum program, based on the circuit model, is illustrated in Figure 3(a). Each line corresponds
to a specific qubit whose state is modified through time (left to right) according to the unitary gates Ui . Figure
3(a) also shows the two primary data types of the Qapp language: quantum registers (qreg) for storage and
grouping of qubits and classical registers (creg) for storing the results of quantum measurement. The third data
type in Qapp is a classical bit type (bit), which can be any integer. The classical bits are used for control of
purely classical constructs (such as “while” loops) that can be inserted in Qapp to make it easier to represent
larger quantum circuits.

2.1.1 Basic Quantum Gate Primitives in Qapp

The Qapp parser does not have the ability to automatically synthesize arbitrary N -qubit quantum operations
into a set of discrete low-level quantum gates. Instead, we use the fact that any N -qubit gate can be decomposed

Proc. of SPIE Vol. 7702 77020S-3

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 into a set of one-qubit gates, two-qubits gates, and quantum measurement10 and restrict Qapp to these three
gate primitives. Table 1 lists the implementation of each of the three gate primitives in Qapp. Any larger
N -qubit quantum gate can be defined as a separate “function” that can be called from any location of the
program. Our choice to restrict Qapp to these gate primitives is consistent with the fact that currently known
quantum device technologies can only execute discrete single-qubits gates, two-qubit gates, and single-qubit
quantum measurement. Since this is not known to be a fundamental limit of the technologies, Qapp can be
easily extended to include any N -qubit quantum gate as a gate primitive.

Low-Level Qapp Gate Primitive Description

qgate G (qubits); Implement a single-qubit gate G on the specified qubits
qgate G (control qubits, target qubits); Implement a two-qubit controlled-gate G
(cbits) = measure (qubits); Measure the qubits and store result in the cbits
Table 1. Set of low-level qgate primitives used by the Qapp language

The specific quantum gates available to Qapp are as follows:

1 Single-Qubit Gates: preparation gate into the state |0 (zprepare), the Hadamard (H) gate, the Pauli
operators {X, Y, Z}, phase rotation by π/2 radians (S), phase rotation by π/4 radians (T ), and any single-
qubit phase rotation by pi/k radians, where k can be any real number. The syntax for the arbitrary phase
rotations in Qapp is: “qgate Rz(k, qubits).”
2 Two-Qubit Gates: The cnot gate (CX), the controlled-Z gate (CZ), the swap gate (SW AP ), and an
arbitrary controlled-phase rotation by pi/k radians, where k can be any real number. The syntax for the
arbitrary controlled-phase rotations in Qapp is: “qgate CRz(k, control qubits, target qubits).”
The above gate set is universal12, 13 and can be used to express any N -qubit operation. In addition, the Qapp
parser is designed such that additional gates can always be added for future compiler releases. An example Qapp
representation of the circuit from Figure 3(a) is shown in Figure 3(b), where each of the quantum operations Ui
is implemented as a Qapp “function”, called from the “main” circuit program. Note that the gate U2 in the
right-hand side of Figure 3(b) can be replaced by any of the single-qubit gates allowed by Qapp. Since it is not
possible to copy quantum data (states),14 Qapp functions pass both classical and quantum data by reference,
not by value. Furthermore, the Qapp parser in the pre-compiler does not have the ability to distinguish between
qubits local to one function from qubits local to another function that share the same names when generating
QIR. For this reason, all qubit resources available to a function must be passed to the function as its inputs.
As shown in Figure 3(b) the Qapp language requires that all quantum and classical registers be explicitly
declared at the beginning of the “main” program. This requirement allows all high-level qubit resources needed
by the algorithm to be available to the front end before each section of the program is translated to QIR. This
design decision was made to based on other programming languages and a desire to “mirror” the structure of a
quantum circuit.

2.1.2 Qapp Registers and Addressing Individual Qubits

The method for addressing qubits in Qapp is motivated by the fact that in many cases a given quantum gate may
operate on multiple qubits during the same time step (see Figure 3(a) for an example of the application of U2
and the measurement gates). To make this property of quantum circuits natural for the programmer to express
in Qapp, the Qapp syntax allows the addressing of any subset of qubits from any given quantum register to be
done within the declaration of a single quantum gate. Table 2, for example, lists all possible ways to address
qubits when applying the single-qubit H gate on two quantum registers, A and B. Note that single-qubit gates
can have an unlimited number of operands.
Addressing qubits within two-qubit gates is nearly identical to the addressing of qubits within single-qubit
gates. The difference is that two-qubit gates can only have two operands, while single qubit gates can have an

Proc. of SPIE Vol. 7702 77020S-4

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 Qapp Syntax Description
qgate H(A[x]); Apply an H gate on qubit A[x]
qgate H(A[x],A[y],B[z]); Apply an H gate on qubits A[x], A[y], and B[z]
qgate H(A[x:y:z], B[c-d]); Apply an H gate on qubits A[x], A[y], A[z], and qubits B[c] through B[d]
qgate H(A); Apply an H gate on all qubits in register A.
Table 2. Ways to address qubits when applying quantum operations

unlimited number of operands. Also, both operands within a two-qubit gate must refer to the same number of
qubits. The first operand refers to the control qubits, while the second operand must refer to an equal number
of target qubits. This is best demonstrated by the example shown in Figure 4, which illustrates a few simple
ways to make a 4-qubit cat-state and the corresponding Qapp syntax for the cnot gates.

1 H H H
qreg 2
A 3
4
qgate CX (A[1], A[3]);
qgate CX (A[1:1:1], A[2:3:4]); qgate CX (A[1-4], A[2-5]);
qgate CX(A[1:3], A[2:4]);

Figure 4. Different circuits for making a cat-state and corresponding Qapp syntax for the cat-state cnot gates

2.2 Mapping of Qapp to QIR and Analysis of QIR

The QIR code is an assembly-like format of Qapp, which has all purely classical operations processed, all loops
unrolled, and all registers expressed either as individual qubits or classical bits. An N -qubit register A(N ), for
example, is converted to the QIR qubit sequence {A1 , A2 , · · · , AN }. The Qapp operation “qgate H(A[1 − 3])” is
mapped to the three discrete QIR instructions “h A1 ,” “h A2 ,” and “h A3 .” Similarly, the two-qubit cnot gate
“qgate CX(A[1 − 3], A[2 − 4])” is transformed to the three discrete cnot instructions“cx A1 , A2 ,” “cx A2 , A3 ,”
and “cx A3 , A4 .” Since QIR is analogous to a quantum assembly language, we will refer to all QIR operations
as “instructions.”
The first opportunity to perform optimization of the quantum circuits represented using Qapp is the com-
pilation step that maps the Qapp representation to QIR. Circuit optimizations can be performed for reliability,
number of computational steps, number of qubits, or number of gates. Optimizing quantum circuits for any of
these properties is one of the most interesting and promising uses for this compiler. One possible optimization
that can be considered when generating the QIR code is the use of technology-independent circuit identities to
replace subsets of quantum circuits described by the Qapp language with equivalent, more efficient gate sequences
(i.e., smaller number of qubits, gates, or computational steps).7, 15 Figure 4, for example, shows three circuits
for making a 4-qubit cat-state that are identical in function, but whose cnot gates are organized differently. It
can be seen that the third cat-state is more efficient than the first two in terms of total number of computational
steps (three instead of four). Thus, if Qapp includes any of the first two cat-states, the mapping to QIR may
replace them with the third cat-state.
Generating QIR is also an opportunity for technology-dependent optimizations of the quantum program.
Qapp has been designed to allow optional technology-specific primitives to guide the mapping to QIR. Currently
the QIR code consists of the same gate types that are expressed in Qapp. However, it may be advantageous
to use technology specific gate libraries in future revisions of the compiler, in order to make the QIR code
easier to synthesize during the later stages of compilation. For technologies that require only nearest-neighbor

Proc. of SPIE Vol. 7702 77020S-5

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 interactions,4, 16 the most efficient cat-state circuit may be the second circuit shown in Figure 4 since it requires
only nearest-neighbor qubit interactions.
The quantum compiler is also designed to allow us to analyze the resource requirements for the quantum
circuit being compiled. We have therefore included routines to perform the following analyses:
1 Calculation of the number of computational steps necessary to complete circuit execution.
2 Calculation of the maximum allowed probability of failure per instruction, given that the overall program
must meet some predefined reliability value.
3 A comparison of the maximum allowed probability of failure per instruction with the actual probability of
failure for each instruction if implemented on the target-device technology. This comparison will tell us if
error correction is needed to raise the level of reliability for each instruction.

2.3 Example: The Bacon-Shor [[9, 1, 3]] Error Correcting Code

To demonstrate how the compiler can be used to process a quantum program, we chose the implementation of a
single cnot gate between two logical qubits encoded using the Bacon-Shor [[9, 1, 3]] error correcting code as an
example. The [[9, 1, 3]] code encodes a single logical qubit into the state of nine physical qubits and allows for
the correction of any single error in the state of any of the nine physical qubits. For more detailed description
of logical gates, physical gates, and generally the theory of fault-tolerant quantum error correction, the reader is
referred to the literature [12, 17–19].
We chose the logical cnot gate because it allows us to demonstrate how the compiler can be used to automate
the study of fault-tolerant quantum error correcting codes. Fault-tolerant quantum error correction lies at the
heart of implementing quantum operations for large-scale architectures, but requires large number of physical
qubits and gates and a careful design of the underlying fault-tolerant circuits. The properties of most interest
in the study of fault-tolerant quantum error correction, which cannot be calculated by hand include: the fault-
tolerant threshold failure probability17 and the total number of quantum gates, qubits, and computational steps
needed to implement the underlying circuits. The compiler allows us to calculate two different types of threshold†
values: a theoretical threshold value which is independent of the device technology, calculated using the QIR
representation; and a more accurate threshold value specific to the target device technology, calculated by the
back end. The capability of the compiler to calculate a fault-tolerant threshold value comes from incorporating
an open-source malignant pair counting tool used in prior analysis of quantum computing error correcting codes20
into the compiler implementation.

DC1
DC2
DC(9) X Z DC3
Z X
AC(9) EC EC EC EC AC1
AC2 H
DT(9) X Z Z X AC3
AT(9) EC EC EC EC
repeat for DC7, DC8, DC9

repeat for DC4, DC5, DC6

Figure 5. The circuit for a logical cnot gate using the Bacon-Shor [[9, 1, 3]] error correcting code (The boxes “X EC” and
“Z EC” denote error correction of Pauli X errors and Pauli Z errors, respectively)

The logical cnot circuit that we analyze is shown in Figure 5. The circuit consists of four 9-qubit quantum
registers. The registers denoted with DC and DT are the data logical qubits, where one is the control qubit
and the other one is the target qubit. The registers denoted with AC and AT are the corresponding auxiliary
†
The threshold is the maximum failure probability allowed per physical gate in order for error correction to be effective.

Proc. of SPIE Vol. 7702 77020S-6

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 start_function PrepareForXCorrect {qreg a(3), qreg d(3), creg zprepare A_1,+;
c(3)}:
zprepare A_2,+;
QIR
qgate ZPREPARE(a[1:2:3]);
h A_2;
qgate H (a[2]);
zprepare A_3,+;
qgate CX(a[2:2],a[1:3]);
qgate CX(d,a); cx A_2,A_3;
(c) = MEASURE (a); cx A_2,A_1;
end_function; cx D_1,A_1;
cx D_2,A_2;
start_function XCorrect {qreg D(9), qreg A(9), creg C(9)}: cx D_3,A_3;
call_function PrepareForXCorrect {A[1-3],D[1-3],C[1-3]}; zmeasure C_1,A_1;
call_function PrepareForXCorrect {A[4-6],D[4-6],C[4-6]}; zmeasure C_2,A_2;
call_function PrepareForXCorrect {A[7-9],D[7-9],C[7-9]}; zmeasure C_3,A_3;
(C[1-3]) = qasm_func syndromebs(C);
call_function CorrectErrors {D};
end_function;


DAG
start_main:
 



 

    



qreg DC(9), DT(9); # data control and target qubits

qreg AC(9), AT(9); # ancilla for control and target qubits    


creg SC(9), ST(9); # syndrome bits

 

    



call_function XCorrect {DC, AC, SC};

call_function ZCorrect {DC, AC, SC};  



call_function XCorrect {DT, AT, ST};




call_function ZCorrect {DT, AT, ST};

qgate CX (DC[1-9], DT[1-9]);
call_function XCorrect {DC, AC, SC};
call_function ZCorrect {DC, AC, SC};
Circuit Statistics:
call_function XCorrect {DT, AT, ST};
- Total number of gates ............................................ 344
call_function ZCorrect {DT, AT, ST};
- Total number of wait operations .......................... 1014
- Total number of computations steps ......................... 74
end_function;
- Threshold failure probability ........................ 2.3 x 10-5

Figure 6. The Qapp representation of the circuit shown in Figure 5, and the transformation to QIR and subsequent
analysis

qubits used during the [[9, 1, 3]] error correcting process. Each error correction step is divided into a correction
of Pauli X errors and Pauli Z errors (denoted with “X EC” and “Z EC”, respectively). The right-hand-side of
Figure 5 shows the detailed circuit for the correction of Pauli X errors. Aliferis, et al., [21] provide a detailed
description of the difference between fault-tolerant Pauli X correction and Pauli Z correction for codes like the
[[9, 1, 3]] code.
Figure 6 shows the Qapp representation of the circuit in Figure 5, where the functions for correcting Pauli
Z errors have been omitted to save space. Note that the “main” function corresponds to the left-hand-side
of Figure 5 and the functions “PrepareForXCorrect” and “XCorrect” correspond to the right-hand-side of
Figure 5. Figure 6 also shows an example transformation of part of the Qapp program through the pre-compiler
and the resulting analysis. The right-hand-side of Figure 6 starts with the QIR representation of the circuit
described in the “PrepareForXCorrect” Qapp function. The QIR code is then mapped to a Directed Acyclic
Graph (DAG), allowing us to identify all data dependencies between each of the QIR instructions. In reality, the
compiler generates a DAG for the entire application, which exposes data dependencies between all instructions.
Each node in the DAG corresponds to a QIR instruction and an edge between two nodes denotes a dependency
between two instructions. When generating the DAG, dependencies are calculated in two ways: (1) if the two
instructions can be described by two unitary matrices, then the pre-compiler checks if the matrices commute;
(2) if one (or both) of the instructions cannot be described by a unitary matrix, the pre-compiler checks for any
shared data qubits or classical bits.

Proc. of SPIE Vol. 7702 77020S-7

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 By identifying all instruction dependencies the DAG can be used to generate a candidate schedule for ex-
ecuting each instruction. The generated schedule represents computational steps, without assigning a specific
time to each step. The schedule is built one computational step at a time, where at the start of each step a set
of available instructions is created. If two instructions are available but only one can be scheduled for execution,
then the chosen instruction is the one with the higher priority. The priority for each instruction is the value of
the instruction’s longest path to the last node in the DAG. The bits and qubits involved with the instructions
that complete execution at the end of each computational step are freed and all subsequent instructions that
need this data can become available for scheduling during the next computational step. Some instructions may
require more than one computation step in order to complete execution. The number of computational steps
required by each instruction type can be specified by the user and is assumed to be a single step by default.
The resulting QIR schedule can be used to estimate the overall program reliability since it gives the user
knowledge of exactly what instructions are scheduled at each computational step. The number of steps is also a
good indicator of how long it would take to execute the program if a specific time unit is assigned to each step.
Finally, the schedule is used directly to estimate a technology-independent fault-tolerant threshold value, which
takes into account the amount of time qubits spend waiting for instructions to complete execution. The routine
which calculates the threshold treats each computational step through which a qubit spends waiting as a discrete
“wait” instruction in order for it to contribute to the overall threshold value. Figure 6 shows the technology-
independent analysis results for the logical cnot gate using the [[9, 1, 3]] code. The technology-dependent results
are discussed in Section 4.

3. ASSEMBLER
The input to the assembler is the QIR representation of the program. The function of the assembler is assemble a
representation composed of gates which can be implemented fault-tolerantly. We refer to the resulting assembler
generated code as Qasm (for quantum assembly) and note that Qasm is simply an extension of QIR, since QIR
is also an assembly-like language. In fact, if error correction is not required, or the QIR program is composed
entirely of stabilizer gates,22 then the assembler component is skipped and transformation of the program is
passed on directly to the back end. Stabilizer gates include the Hadamard gate, the cnot gate, the Pauli X,
Y , Z gates, the single-qubit S gate, and quantum measurement. Fault tolerant implementations exist for all
stabilizer gates, thus there is no need for the assembler to do anything to them. Another gate for which the
assembler is not needed is the single-qubit T gate, which can also be implemented fault-tolerantly.21
The QIR gates which need to be processed by the assembler are the arbitrary ẑ-axis rotations by an ar-
bitrary angle θ radians (the single-qubit gate Rz(θ) gate and the two-qubit CRz(θ) gate) and the two-qubit
swap gate. The swap gate applied to two qubits Q1 and Q2 is simply converted to three cnot gates as follows:
swap (Q1,Q2); = CX(Q1,Q2); CX(Q2,Q1); CX(Q1,Q2); Similarly, the two-qubit CRz(θ) gates can be decom-
posed into a sequence of three Rz(θ/2) gates and a cnot gate, as shown by Nielsen and Chuang [23], Chapter
4. The conversion of the Rz(θ) rotations into fault-tolerant gates is more difficult. This is implemented in two
different ways, depending on the value of θ:

1. If θ = 2πk for k being any positive integer, then the assembler employs a recursive decomposition of Rz( 2πk )
for which the base case is the S gate. The recursive implementation of the single-qubit Rz( 2πk ) on qubit
Q is illustrated as a quantum circuit in Figure 7. The gates in Figure 7 denoted with A( 2πk ) are used to
prepare an auxiliary qubit into the state Rz( 2πk )| + .21, 24
2. If θ is not equal to 2πk , but is arbitrary, the compiler approximates a single-qubit Rz(θ) gate using
O(log3.97 (1/)) gates from the set {H, T, S} by the Solovay-Kitaev theorem.25 The Solovay-Kitaev ap-
proximation error () is equivalent to a small rotation error applied to the qubit. To compute the desired
sequence required to approximate an Rz(θ) gate, the compiler employs the algorithm of Dawson and Nielsen
[26].

Proc. of SPIE Vol. 7702 77020S-8

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 Rz(π/2k)
Rz(π/2k-1)
Rz(π/4)

Q S X X X
Q k
Rz(π/2 )
A
|0〉 (π/2k)
A
|0〉 (π/2k-1)
A
|0〉 (π/4)

Figure 7. A recursive implementation of a single-qubit Rz( 2πk ) gate on qubit Q

4. BACK END: ASSEMBLY LEGALIZATION

The primary function of the back end is to legalize the Qasm instructions to the Instruction Set Architecture
(ISA), defined by the target device technology. The ISA is defined in a separate user file and specifies the mapping
of each Qasm instruction to the pulse sequences necessary to implement the instruction physically. The resulting
“legal” code, referred to as the Quantum Physical Representation (QPR), is the microcode which is ready to be
sent to the quantum subsystem for execution. The back end also performs the same analysis, as described in
Subsection 2.2, on the resulting QPR code. Optimization of the QPR code is performed by mapping it onto the
geometrical representation of the physical device architecture using a heuristic targeted at minimizing the total
computational time. The mapping process, however, does not change the physical representation of each gate in
the QPR code. This ensures that the design of the microcode for each Qasm instruction will not be inadvertedly
modified by the back end if it is designed to protect the state of the qubits against certain physical error types.
The QPR code generated by the back end is based on the ion-trap device technology.27–30 The ion-trap
technology uses the hyperfine energy levels of atomic ions to represent qubits and laser pulses to implement
quantum gate operations. A complete description of all low-level ion-trap components that are necessary for
scalable quantum computation is given by Home, et al. [30].

...................
ions
U. UU UU UU UU UU UU UU UU 'U

...................
U. ballistic channel
U U U UU UU UU U U U trap zones

...................
U. UU - UU UU UU UU .UU UU - UU U

Figure 8. A screen capture of the back end’s visual interpretation of the ion-trap technology

An abstraction of the ion-trap device architecture is shown in Figure 8, which is an actual screen capture of
the back end’s visualization utility of the circuit given in Figure 5 for correcting Pauli X errors. Note that Figure
8 shows nine qubits for the data (corresponding to the register DC in Figure 5) and nine qubits for the ancilla
(corresponding to the register AC in Figure 5). As shown in Figure 8, ions are stored in designated trapping
zones and are ballistically shuttled from one region to another via the drawn ballistic channels. For two-qubit
gates, ions are moved to the same trapping zone and the vibrational modes provides the mechanism for qubit
interaction.

The QPR code, derived from the trapped-ion ISA, consists of the instructions shown in Table 3. Note that
the ion-trap technology does not allow direct implementation of cnot gates. All cnot gates must be converted

Proc. of SPIE Vol. 7702 77020S-9

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 to two Hadamard gates and a single controlled-Z gate before they can be used in QPR. A basic “move” operation
is defined as the physical movement of an ion from one trap zone to any of the three adjacent trap zones. A basic
“wait” gate is defined as applying the Identity operator on an ion for the duration of a single computational
step and allows the back end to take into account memory errors in the qubits when analyzing the program
reliability and threshold failure probability. In reality, each of the physical gates shown in Table 3 is at a level of
representation that is higher than the actual physical pulses necessary for controlling trapped ions. For future
versions of the back end, we intend to take into account the fact that the QPR representation of each of the
Qasm gates will consist of the pulse sequences for universal quantum computation discussed in recent trapped-ion
experiments30, 32 instead of the gates in Table 3. We must also take into account the fact that each physical
qubit may be encoded into a Decoherence Free Subspace (DFS)31 using a pair of ions instead of a single ion.

QPR Instruction Description

zprepare Q,+; Initialize the state of qubit Q into the state |0
sgate Q; Apply a single-qubit gate on qubit Q (“sgate” can be any gate)
cz (Q1, Q2); Apply a controlled-Z gate between Q1 and Q2 (cnot gates are not allowed)
zmeasure Q,c; Measure qubit Q and store the result in classical bit c
move Q; Move qubit Q between two adjacent trap zones
wait Q; Apply Identity to Q for the duration of a single computational step
Table 3. Physical instructions available to QPR

QPR analysis and the properties of the quantum program derived by the QPR analysis are the same as
those derived for the QIR circuits, described in Section 2.2. The fact that this analysis uses QPR, makes the
results technology-specific by taking into account the underlying device characteristics. When scheduling the
QPR program, the back end employs the priority-based scheduling algorithm, which dynamically updates the
instruction priorities based on the communication requirements for the ions at each computational step during
the scheduling process.33 The duration of each QPR gate is expressed in terms of computational steps (without
a specific time unit per step), where the number of computational steps per gate is left up to the user to define.
The default configuration is set to a single computational step for each type of gate. In reality the ratio of
the duration of a controlled-Z gate and a single-qubit gate is approximately three to one,30 thus one possible
configuration is to assign one computational step for each single-qubit gate and three steps to each two-qubit
gate. The duration of two-qubit gates, however also depends on the number of movement gates necessary to
bring the participating qubits together.
When looking at the QPR analysis results made available by the back end, it is easy to see why even a
single logical cnot gate is difficult to analyze by hand. Assuming the default gate duration, the QPR execution
length can be calculated to be 292 computational time steps, 344 total number of quantum gates, 585 movement
operations, and as many as 4459 “wait” operations. The “move” operations are derived via an auto-generated
geometrical placement of the ion-trap qubits onto a 2-D device abstraction (see Figure 8). It is also possible to
provide a user-defined placement of the ions as input to the back end (in a text file) for a more customized analysis
of the circuit. The “wait” operations are only assigned when the qubit is active and no quantum operation is
being applied to it. A qubit is inactive when it has been measured and before its state is initialized to |0 for
computation. The fault-tolerant threshold value for the logical cnot gate that corresponds to this particular
configuritation is approximately 1.0 × 10−6 . This means that the physical gates must be manufactured such
that each gate has a failure probability at most 1.0 × 10−6 . Recent experimental work with trapped ions32 has
indicated that the contribution of the “wait” operations to the fault-tolerant threshold is negligible. In this case,
the fault-tolerant threshold calculated by the back end becomes approximately 9.0 × 10−6 , which is a significant
increase of the maximum allowed gate failure probability.

Proc. of SPIE Vol. 7702 77020S-10

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 5. CONCLUSIONS
We have described the design and implementation of a quantum compiler intended for programming and analyzing
quantum programs written for QRAM-based quantum architectures. We have described the three different
compiler components (front end, assembler, and back end) and some of the analysis available to the user during
the front end and during the back end. Based on the analysis performed in the front end, the back end may be
configured, in future versions of the compiler, to apply first-order quantum error correction to the Qasm code.
Each qubit specified in Qasm can be converted to a logical qubit and replaced with the corresponding physical
qubits and low-level machine instructions necessary for error correction. Higher order error correction can then
be applied as necessary on top of the physical machine instructions used to build the first-order logical gates.
We described the Qapp language for programming quantum applications, which provides the abstractions
necessary to easily describe very large quantum circuits and to process and analyze these circuits down to the
physical device level. An important property of Qapp is its extensibility to include any user-defined primitives
and the speed of the interpreter that results from the fact that it does not track of the state of the qubits.
To date we have performed limited verification testing of the compiler. These tests include verification by
inspection and analysis of simple test cases, the [[9, 1, 3]] code discussed in Section 2 being one example. In
addition to extending the functional capabilities of the compiler, future work will involve additional verification
and validation testing.

REFERENCES
[1] Knill, E., “Conventions for quantum pseudocode,” Los Alamos National Laboratories, Technical Report
LAUR-96-2724 (1996).
[2] Cook, S. A. and Reckhow, R. A., “Time-bounded random access machines,” Journal of Computer Systems
Science 7, 354–375 (1972).
[3] Metodi, T. S., Thaker, D. D., Cross, A. W., Chong, F. T., and Chuang, I. L., “A quantum logic array mi-
croarchitecture: Scalable quantum data movement and computation,” Proceedings of the 38th International
Symposium on Microarchitecture (MICRO-38) (2005).
[4] Fowler, A. G., Thompson, W. F., Yan, Z., Stephens, A. M., Plourde, B. L. T., and Wilhelm, F. K., “Long-
range coupling and scalable architecture for superconducting flux qubits,” Phys. Rev. B. 76(174507) (2007).
[5] Aho, A. V., Lam, M. S., Sethi, R., and Ullman, J. D., [Compilers, Principles, Techniques, and Tools],
Addison Wesley, 2 ed. (August 2006).
[6] Cooper, K. D. and Torczon, L., [Engineering a Compiler], Morgan Kaufman Publishers, 5 ed. (March 2008).
[7] Svore, K., Cross, A., Aho, A., Chuang, I., and Markov, I., “Toward a software architecture for quantum
computing design tools,” In Proceedings of the Workshop on Quantum Programming Languages (QPL)
(2004).
[8] Poulin, D., “Stabilizer formalism for operator quantum error correction,” Phys. Rev. Lett. 95(230504) (2005).
[9] Bacon, D., “Operator quantum error correcting subsystems for self-correcting quantum memories,” Phys.
Rev. A 73(102340) (2006).
[10] Barenco, A., Bennett, C. H., Cleve, R., DiVincenzo, D. P., Margolus, N., Shor, P., Sleator, T., Smolin, J.,
and Weinfurter, H., “Elementary gates for quantum computation,” Phys. Rev. A. 52(3457) (1995).
[11] Deutsch, D., “Quantum theory, the church-turing principle and the universal quantum computer,” Proceed-
ings of the Royal Society of London A-400, 97–117 (1985).
[12] Shor, P. W., “Fault-tolerant quantum computation,” in Proc. 37th Symp. on Foundations of Computer
Science, IEEE Computer Society Press , 55–65 (1996).
[13] Steane, A. M., “Efficient fault-tolerant quantum computing,” Phys. Rev. Lett. 78, 2252–2255 (1997).
[14] Wootters, W. and Zurek, W., “A single quantum cannot be cloned,” Nature 299, 802–803 (1982).
[15] Maslov, D., Falconer, S. M., and Mosca, M., “Quantum circuit placement: Optimizing qubit-to-qubit inter-
actions through mapping quantum circuits into a physical experiment,” E-Print arXiv:quant-ph/0703256v1
(2007).

Proc. of SPIE Vol. 7702 77020S-11

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms

 [16] Kane, B., “A silicon-based nuclear spin quantum computer,” Nature 393, 133–137 (1998).
[17] Aharonov, D. and Ben-Or, M., “Fault tolerant computation with constant error,” Proc. 29th Ann. ACM
Symp. on Theory of Computing (STOC) 29, 176–188 (1997).
[18] Gottesman, D., “Fault tolerant quantum computation with local gates,” Journal of Modern Optics 47,
333–345 (2000).
[19] Steane, A. M., “Error correcting codes in quantum theory,” Phys. Rev. Lett 77, 793 – 797 (1996).
[20] Cross, A. W., DiVincenzo, D. P., and Terhal, B. M., “A comparative code study for quantum fault-
tolerance,” E-Print, arXiv:0711.1556v1 (2007).
[21] Aliferis, P., Gottesman, D., and Preskill, J., “Quantum accuracy threshold for concatenated distance-3
codes,” Quant. Inf. Comp. 6, 97–165 (2006).
[22] Gottesman, D., “The heisenberg representation of quantum computers,” Hobart, Group theoretical methods
in physics , 32–43 (1998).
[23] Nielsen, M. A. and Chuang, I. L., [Quantum Computation and Quantum Information], Cambridge University
Press, Cambridge, UK (2001).
[24] Gottesman, D. K. and Chuang, I. L., “Quantum teleportation is a universal computational primitive,”
Nature (402), 390–392 (1999).
[25] Kitaev, A. Y., Shen, A. H., and Vyalyi, M. N., [Classical and Quantum Computation], Amer Mathematical
Society (July 2002).
[26] Dawson, C. M. and Nielsen, M. A., “The solovay-kitaev algorithm,” Quant. Inf. Comp. 6, 81 (2005).
[27] Cirac, J. I. and Zoller, P., “Quantum computations with cold trapped ions,” Phys. Rev. Lett 74, 4091–4094
(1995).
[28] Steane, A. M., “The ion trap quantum information processor,” Applied Physics B: Lasers and Optics 64(6)
(1997).
[29] Kielpinski, D., Monroe, C., and Wineland, D. J., “Architecture for a large-scale ion-trap quantum com-
puter,” Nature 417, 709–711 (2002).
[30] Home, J. P., Hanneke, D., Jost, J. D., Amini, J. M., Leibfried, D., and Wineland, D. J., “Complete methods
set for scalable ion trap quantum information processing,” Science 325, 1227 – 1230 (September 2009).
[31] Lidar, D. A., Chuang, I. L., and Whaley, K. B., “Decoherence free subspaces for quantum computation,”
Phys. Rev. Lett. 81, 2594 (1998).
[32] Hanneke, D., Home, J. P., Jost, J. D., Amini, J. M., Leibfried, D., and Wineland, D. J., “Realization of a
programmable two-qubit quantum processor,” Nature Physics 6, 13 – 16 (2009).
[33] Metodi, T. S., Thaker, D. D., Cross, A. W., Chong, F. T., and Chuang, I. L., “Physical operations scheduler
in a quantum information processor,” in Proceedings of the SPIE Defense and Security Symposium, Orlando
FL 5(6244-29) (2006).

Proc. of SPIE Vol. 7702 77020S-12

Downloaded From: http://proceedings.spiedigitallibrary.org/ on 05/20/2015 Terms of Use: http://spiedl.org/terms