1 Introduction

In the field of quantum computing, the theoretical vision is beyond the current experimental capability of candidate quantum computing hardware. Ideally, a working quantum information processor could be operated by someone who did not have specialized knowledge of the experiment details, but instead, the user could submit a job via an external interface that is then run by the system (see Fig. 1). As with classical computers, users do not, in general, need to be cognizant of the hardware-level machine language, but instead submit the calculations via a higher-level, system agnostic language such as C, Python, or MATLAB™. In this case, a compiler then takes the user’s description of the calculation and a description of the hardware it is to be run on and makes a hardware-specific set of instructions.

Fig. 1
figure 1

Comparison between a a model of the user interface for a classical computer and b the interface to a quantum computer proposed here. In both cases, the user provides a description of the algorithm in a high level language. The compiler takes this and a description of the physical hardware to produce hardware-level instructions that are then executed by the operating system for a classical computer or the experimental control system for a quantum computer

Full size image

Pursuit of a programmable capability also holds efficiency benefits for the experimentalist. Experimentalists are currently facing a mounting problem. As the complexity of quantum hardware grows, it will become increasingly necessary to handle the hardware in a modular and scalable manner. In particular, in an ion trap-based system, the advent of multi-substrate traps (see, for example, Refs. [1,2,3,4]) and then surface electrode traps (e.g., [5,6,7,8,9]) have allowed the trap complexity of transport-based architectures [10] to grow with limits now only set by the density of control signals to the traps. In particular, specialized ion traps with limited control can now be replaced with traps that are amenable to general problem sets.

All these capabilities open up a set of experimental control problems that can be daunting. Tools to manage this complexity, both inside the control software and external to the control software will become increasingly necessary to ion trapping efforts. For example, the execution of a quantum-state tomography routine involving ion transport requires the implementation of a fairly complex set of changing control sequences.

Furthermore, unlike classical computer hardware, quantum hardware will remain temperamental and require continual calibrations to keep adequate gate fidelities. Calibrations and recovery from catastrophic errors, such as ion loss, will need to be automated. Also, unlike a classical system, some quantum calculations will have to repeat until a particular set of requirements (set by the user) on the data have been met. In effect, the operating system of the quantum computer (i.e., the experiment control software) will have to understand the hardware limitations and continually interrupt the repeated execution of the user’s algorithm to check for, and recover from, errors that would corrupt the data.

In this chapter, we describe our approach to constructing an abstracted user interface for complex quantum hardware including control and recovery of the real-world issues that can afflict such hardware. We start in Sect. 2 by describing the technology application at hand, in this case, surface electrode ion traps, and the implications that routing rules on this technology has for a control language. We follow this by describing a hardware-level control language implemented to address these requirements in Sect. 3. In Sect. 4, we introduce a compiler that can translate an abstract platform-independent language into the hardware-dependent control language capable of running an ion trap. In Sect. 5, we describe this abstract input control language and describe several practical applications of this automation capability, including ion loss recovery, calibration, and initial ion position routing. We bring all these features together with a simple demonstration of this system in the laboratory using a multi-zone ion trap and an experimental control system that can execute the control language on this trap. We conclude with a discussion on the future of this type of control system.

2 Surface electrode traps

The methods we will discuss for the quantum compiler are applicable to many physical representations of quantum technologies; however, we will focus on ion trapping and, in particular, ion trapping with surface electrode ion traps [5, 6]. This choice has important implications for the control language the compiler must generate, so we start with a description of this system. Surface electrode ion traps are fabricated from patterned layers of metal on an insulating layer. An example of such a trap is shown in Fig. 2. The two-dimensional nature of these ion traps allows for microfabrication of complex trap layouts that would be difficult or impossible with macrofabricated or microfabricated multilayer traps. There are usually two types of electrodes, the RF electrodes that provide a fixed pondermotive confining potential in usually two directions (generically called the radial directions) and the DC electrodes that provide variable confinement in the third direction (the axial direction). Changing the potentials on the control electrodes (or, in ion trap parlance, applying “waveforms” to the control electrodes) allows for ions to be transported along the length of the trap and can be used to merge multiple ions into the same well or split them apart as shown in Fig. 3.

Fig. 2
figure 2

Example segment of a surface electrode trap and fabricated from layers of metal and oxide on a silicon wafer

Full size image

In the transport architecture for an ion-based quantum processor [10], individual ions are transported between regions of the ion trap to pair them up with other ions for two-qubit gate operations or to place the ions in dedicated regions for temporary storage, single-qubit operations, or detection. In the last decade, there have been considerable advances in the capabilities of ion traps, with complex junction transport architectures having been demonstrated [2, 4, 7, 9, 11]. These traps support multiple potential wells capable of confining one or more ions in each well.

Fig. 3
figure 3

a Image of a four-ion chain held in a single potential well above the surface of a surface electrode ion trap. The trap is shown schematically behind the image. b–d By time-varying the potentials on the trap’s control electrodes, the ions can be split into two wells, with the number of ions split into each well depending on slight adjustments to the applied potentials. The field-of-view is the same for all four images

Full size image

We can place a single ion at any point along the transport path shown in Fig. 2 by the appropriate choice of potentials on the trap’s control electrodes. When working with single ions, it is common to tabulate the potentials needed to confine the ion at a dense series of locations along the path. However, when working with multiple ions in separate wells, tabulating all the possible locations for the set of ions quickly becomes unfeasible as the number of ions grows.

Furthermore, most computer science algorithms for routing of items along paths are graph-based with the nodes of the graph corresponding to a discrete set of locations. To better map the traps onto a tractable routing problem, we instead break the trap up into discrete trapping regions, each with well-characterized properties, and a description of the connections between each of these regions. Each of these regions, which we will call a ‘zone,’ corresponds to a specific, limited set of electrodes.

However, we should note that in ion trap parlance, term ‘zone’ often refers to the number of pairs of control electrodes minus a few for end cap potentials. In this definition, the zones do not describe independent trapping regions. For example, a trap with five electrode pairs could be considered a three-zone trap where zone one uses the first through third pair, zone two uses the second through fourth pairs, and zone three uses the third through fifth pairs. While it is possible to form a well at zone one and zone three simultaneously, forming a well at zone two excludes the other zones. As the trap complexity grows, however, we believe it becomes useful to replace this loose definition with the definition that a ‘zone’ is a trapping region that acts independently from all other zones beyond one or more connection points (‘nodes’) for transport of qubits (or, more generally, for transport of quantum information) to other zones. Under this definition of a zone, the five electrode- pair example could be considered to be, at most, a two-zone trap; however, additional electrode pairs in each zone would improve the independent control of the two zones. See Fig. 4a for an example of a multi-zone trap with sufficient electrode pairs per zone to allow largely independent control of each zone. In the new parlance, each zone has a type, for example a junction, and there may be many instances of that type as shown in Fig. 4b. Here, we are using the term ‘instance’ as used in programming to describe a particular object out of a set of objects of the same type. As trap complexity grows and there are more instances of each zone type, the efficiency of the zone/interconnect description increases.

Fig. 4
figure 4

a We divide a large trap into functional zones using ‘nodes’ as connections between the zones. The zones are identified by functionality where, for this example, L0 is a load zone, M0 and M1 are ‘memory’ zones where ions can be temporarily stored, and J is a junction. b The result is a set of zones and connections between zones that abstracts the ion trap geometry. The junction J is diagrammatically represented by the four ‘bus’ zones B0 through B3

Full size image

For any given ion trap, the division into zones is not unique but instead depends on the functional needs and limitations of the system. The more electrodes assigned to a zone, the easier it is to control ions in that zone and the easier it is to prevent control potentials in one zone from affecting the next. However, increasing the number of electrodes in a zone reduces the number of zones a given trap can be divided into and limits the set of potential ion configurations for supporting a quantum circuit routine. To reduce cross talk of potentials between zones, it is important to localize the electrodes to pads near the zone. Electrical connections to the electrodes should be shielded by a ground plane. However, there will always remain some cross talk of the potentials between zones. This will mainly affect ion pair merging and separation which can be sensitive to field changes. For these situations, it may be necessary to limit operations in nearby zones during merge or separation. Careful modeling of the devices will be needed to ensure appropriate isolation between zones.

This approach to partitioning an ion trap into functional units has been used previously for designing and modeling larger traps [11]. As the trap size grows, it becomes impractical to treat the trap as a single, monolithic trapping system. The component library-based layout of an ion trap allows for the fabrication of ion traps that can start to approach the ideal of a modular system where each component in the design library can be mapped naturally onto zones.

As with any real system, ion traps exhibit non-ideal behavior that falls outside the descriptions of the ideal algorithms that we are trying to run on the hardware. Such behavior must be automatically handled by the control software so that the system can continue to operate and complete experimental data sets. Non-ideal behavior includes drifts in stray electric fields and ion loss. The former can be handled with automated calibration sequences. But as the hardware becomes larger, it will become necessary to abstract the calibration sequences to handle the increasing number of zones that need calibration. Similarly, ion loss will scale linearly with the number of trapped ions, and possibly faster if ion chains are included in the scheduling solution. To replace a lost ion, or to simply bring a system up to the initial conditions at the start of an algorithm, the ions must be loaded into the trap from some neutral flux via a process such as photoionization. The experiment control system must then route the new ions from a dedicated loading region to the desired final locations, possibly rearranging the other trapped ions as well.

3 Low-level instruction language

In this section, we introduce an instruction set that describes hardware-level operations that the experiment control system can read in and execute. The purpose of this instruction language is to automate the experiment control system by having an external system indicate what operations need to be implemented. We aim to keep the instruction set limited to a reasonable size. Just as in classical architecture instruction set design, there is a trade-off in size of the instruction set versus efficiency of the language. A larger, more customized instruction set allows the programmer to more explicitly optimize the resulting execution, but requires more expertise on the part of the programmer and increases the number of features an implementing experimental system must support. Colloquially, we call the commands in this instruction language OPCODEs (OPeration-CODEs) after the opcodes used in classical computing’s assembly language. See Fig. 5 for example OPCODEs.

While we describe this as a hardware-level language, we still abstract complex operations, such as gates and ion transport, leaving the implementation of these operations up to the experiment control system. The reason for this continued abstraction is to keep the number of OPCODE commands limited, thereby reducing the complexity of the implementation. In the next section, we will describe a compiler that generates these OPCODEs from a higher level, circuit-oriented expression which is independent of the experimental parameters. While the compiler will have to understand the physical layout of the ion trap, we do not want the compiler to have to track time-dependent calibrations, such as laser frequencies or stray field compensations, so the OPCODEs abstraction layer delegates these decisions to the experiment control system. As a last note, while concurrent operation of trap zones is an identified future need, our current OPCODEs language implementation is a purely serial format. A future OPCODEs version could support blocks of parallel instructions.

Fig. 5
figure 5

a Shows a sample trapping structure for modeling an ion trap. Each memory zone ‘M’ is bordered by an integer-labeled node. b A sample OPCODE sequence alongside syntax explanation for selected OPCODEs. A description of all OPCODEs is found in Table 1. This sample sequence transports each of three ions (initially, one ion in M1 and two ions in M3) into M2 where each ion is cooled and state-initialized (via the PREPARE_Z OPCODE). The control system in b refers to the experiment control system that is interpreting the OPCODEs

Full size image

The list of OPCODEs must include all experiment directives needed to implement circuits on the physical system. Additionally, we include commands and directives to allow for automatic system initialization and recovery from failures. For example, in addition to gates, the control language specifies ion loading and movement manipulations as well as Doppler cooling events, system state assertions for error handling, and ion ejection commands. Our choice of operations in the OPCODEs syntax is not unique so we will not fully specify this language here. However, the following paragraphs provide descriptions of a few key OPCODEs.

There are two OPCODE commands to support control on the number of ions in the trap. The first is the LOAD command which instructs the experiment control system to load a single ion at a designated zone. The zone must be capable of loading an ion so the compiler (described in the next section) producing the OPCODE instructions must have a system model that tracks the capability of each zone, including the load capability. The second OPCODE is the EJECT command which instructs the experiment control system to eject an ion out of the trap. The EJECT command runs a waveform which ejects all ions out of the designated zone. This command is typically only used if the experiment control system accidentally loads two ions at the same time but could be used when switching between two routines that require different numbers of ions.

There are three OPCODE commands which provide ballistic instructions. The first is the MOVE OPCODE. This OPCODE governs movement of ion wells in the trap. The LOAD instruction automatically places a well in the load zone but to move the ion into a different memory zone the MOVE OPCODE transports the ion between zones. The movement events are specified in half-zone segments to facilitate the electrode sharing that must occur between zone transports. The MOVE OPCODE either moves the well from the center of the zone to a designated node at one end of the zone or vice versa. The compiler ensures that all MOVE commands appear in pairs, with one or more ions moved from the center of one zone to a shared node and an additional MOVE taking the ion from the node to the center of the new zone. The second ballistic OPCODE is MERGE. In order to move multiple ions into the same well, a special waveform must be run that merges the two well waveforms together. The merge is always performed by moving a qubit from one of the zone’s nodes into the central zone well. The waveform is specialized to whether one, two, or more ions already reside in the central well. The syntax for the MERGE OPCODE includes specification of the merging node and the number of qubits already contained in the central well. The SEPARATE OPCODE provides the reverse functionality of the MERGE OPCODE, removing a single ion from a well that contains one or more ions. Separation is the most sensitive command because ions can easily be lost due to the shallow well needed to split the well in two. As such, the experiment control system will have to incorporate stray field calibrations into the waveforms. Since these stray fields can be slowly time-varying, the experiment control system will have to occasionally run calibration measurements and adjust the waveforms corresponding to the SEPARATE command, and to a lesser extent, the MERGE and MOVE commands. This is an example of why we leave some abstraction in the OPCODEs. If we were to include waveform details in the OPCODEs, the experiment control system would not be able to make these necessary automatic adjustments without querying the compiler to regenerate the OPCODE sequence.

The final set of OPCODE commands govern the qubit state of the ion and ion cooling. These include all the one- and two-qubit gates, the measurement operations, the state preparation operations, sympathetic ion cooling, and doppler ion cooling. The OPCODE syntax for these is simply \(\langle operation name\rangle , \langle zone name\rangle \) where the presumption is that all qubits residing in the zone will have the operation applied. For the purposes of transport with an OPCODE instruction set, sympathetic cooling ions can be treated the same as the qubit ions and transported individually to and from zones where the qubit operations take place. Sympathetic ions would be merged into those zones along with one or more qubit ions and separated out after the cooling and gate operations are complete. Alternatively, sympathetic cooling ions could be paired with qubit ions, with both being transported as a unit [12]. See Table 1 for a complete listing of OPCODEs.

Table 1 Listing of currently planned OPCODEs
Full size table

4 High-level language and a quantum compiler

The details of the OPCODEs language are a concern to the experimentalist running the physical system but are outside the interest of a quantum algorithm writer. To bridge this gap, we created a classical control language that describes the manipulations necessary to implement a circuit on a real device and then built a compiler to translate from the user level to the series of OPCODEs described in the previous section.

Table 2 Teleportation circuit in CHP-like syntax
Full size table

There are a variety of candidate high-level languages for a quantum computer [13,14,15,16,17,18], and the design of such a language is a research field in its own right. We chose an input syntax similar to the CHP format [13]. This simple format is essentially a sequence of gates, one per line, where each line begins with a specification of the gate type and ends with a whitespace-separated list of indices for the qubits affected by the gate (see Table 2 for example). This syntax choice is suitable for our demonstration because it:

  1. 1.

    allows the programmer to focus on the quantum information manipulations (gates), instead of details such as registry selection and data routing,

  2. 2.

    is currently limited to non-branching instruction sequences, which matches current limitations on our experiment control system,

  3. 3.

    specifies gates at the physical qubit level, which again simplifies our task,

  4. 4.

    and could be produced as a back end compilation output from some higher-level language or tool [19].

For our implementation of the quantum circuit compiler, we utilized the GTRI QMP tool (Quantum Machine Parameterizer), described in [19], which is capable of modeling layouts and performing quantum circuit scheduling on them. QMP includes a Hardware Description Language (HDL) for describing the physical system that QMP maps the algorithms onto.

To translate a platform-independent language into the OPCODEs control language, we take the HDL layout file along with a hard-coded set of rules about the limitations of the target platform to identify an OPCODEs routine that will perform the gate sequence on the target hardware. The scheduler respects the following rules:

  1. 1.

    creation of a qubit can only happen in the load zone,

  2. 2.

    single-qubit gates can only happen in an interaction zone, unaffected qubits must be absent from the gate region during gate operation,

  3. 3.

    two-qubit gates also require just the effected qubits be in an interaction zone,

  4. 4.

    two qubits cannot pass through each other,

  5. 5.

    and if two qubits are to reside in the same memory location, they must undergo the merge & separate well operations (instead of simple well movements).

Obviously, on a small layout, these rules create a tight limitation on what algorithms can be achieved. Compilation errors indicate an inability to identify a control sequence for the target layout that can satisfy these rules. Just as for a classical computer, the ability to execute a program is ultimately limited by the hardware of the computing device.

As shown in Fig. 5, each OPCODE sequence begins with an ASSERT statement that makes an assertion about the required initial state of this system. This assertion statement indicates how many ions are expected to be in each zone of the trap before the OPCODE routine can begin and is used for automatic, run-time initialization by the experiment control system as described later.

The compilation process from CHP into OPCODEs performs a fundamental paradigm shift in the expression of the quantum circuit. At the CHP level, the gate sequences address qubits. At the OPCODEs level, the expression addresses hardware regardless of whether a qubit is present. For this technology case, we address zones instead of qubits. At the CHP level, there are no specifications related to parallelism or placement. At the OPCODEs level, the parallelism and placement decisions are now fully determined. In general, quantum compilers that target real hardware will need to track both arenas of information and apply the appropriate conversion.

5 OPCODE language implementation by the experiment control system

Once the OPCODEs to execute an algorithm are sent to the experiment environment, the experiment control system must provide an implementation of the instructions. Ideally, the experiment control system will be able to run a particular algorithm repeatedly to gather sufficient statistics without user intervention, handling issues such as ion loss and calibrations automatically. Figure 6 shows the experiment control system that takes a file containing the compiled OPCODEs and repeatedly performs the sequence of operations listed in the file. In addition to interpreting the OPCODEs, the experiment control system has to both create the waveform and automatically handle initial ion placement and recovery if an ion is lost.

Fig. 6
figure 6

Algorithm coded into QMP is passed to the experiment control system and then translated into specific device commands using a waveform library. The LabQMP provides state transition command sequences for failure recovery support (such as failure due to ion loss)

Full size image

5.1 Waveform generation

The OPCODEs in an algorithm have to be translated into a set of electrostatic potential wells to hold the ions. There are two approaches to defining the waveform for each OPCODE.

In the first method, we define waveforms for each zone that gives the set of potentials that we need to apply to all of the trap electrodes. The set of waveforms for a zone would include all the waveforms needed to apply each OPCODE to that zone. These waveforms not only have to include the potentials for the zones being addressed but has to create wells at the center of the other zones to hold the ions that might be sitting in those zones. The number of waveforms we need is roughly (# of zones)*(# OPCODEs). This works for simple traps but is not scalable. We use this method for the demonstration system we describe later.

In the second method, we define a set of waveforms for each type of zone. Each waveform implements a single OPCODE on that type of zone and only uses that zone’s electrodes plus a waveform to simply hold the ion(s) in the zone when the zone is not being addressed by an OPCODE. These component waveforms are then mapped onto the trap to make the complete waveform. This method of waveform assembly allows for a scalable architecture. However, this requires careful handling of the ions at the common end nodes during handoff of the ion between the zones. For example, the potentials from a MOVE command from zone M1 in Fig. 5 to border label 2 and a following MERGE command into zone M2 (see also Fig. 7 in Sect. 6) have to overlap for a short period of time to keep the ion confined when it is handed off. Ideally, we would define a set of potentials near the zone boundary for the handoff so that the waveforms for a MOVE OPCODE is the same no matter whether it is followed by a MERGE OPCODE or by a MOVE OPCODE in the zone it is handing off to.

In addition to generating the canonical waveform, the experiment control system will also have to apply adjustments to counter small stray electric fields. Adiabatic transport of ions across linear regions of a trap are fairly stable to drifts in the stray electric fields. In contrast, merging and separation of ion pairs requires fine-tuning of the potentials to keep from heating the ions during the merge and to create the separation during splitting. Fields need to be adjusted down to few volts per meter for merge and separation. Stray fields in a surface electrode trap can drift at this level over the course of a few hours and in particular, after ion loading. For a small trapping system, it is feasible to write routines to tune up a few merge–separation zones, but with a larger system, we need to instead work with a template for each type of zone. In an automated zone calibration (AZC) sequence on a merge–separation zone, the system would route the ions to the necessary start conditions for that zone, as specified by the template, run the associated operation, e.g., a separation, then perform an analysis that adjusts a waveform parameter, in this case the axial field in that zone, dependent on the outcome of the analysis.

Similar to the waveform calibrations, quantum computing experiments will also require continual calibrations of the hardware to keep adequate gate fidelities. For small systems, hand-coded calibration routines are feasible. But as the hardware becomes increasingly complex, hand-coding will become inefficient. Instead, the calibration routines will have to be derived from the HDL description along with a calibration description for each type of zone.

5.2 Initialization and recovery

Given a user’s instruction sequence initial OPCODE state assertion, the control system will have to initialize the ion placements, possibly loading additional qubits if needed or shelving extra qubits for later use. Consequently, in addition to a quantum compiler that can generate control sequences for an input circuit, there also needs to be a routing system for transport of qubits into desired initial positions. The routing system will take the HDL description, the current state placement of ions and the desired placement of ions, and generate a transport list of operations. In our demonstration, QMP was extended and modified to provide LabQMP, a windows-compatible tool that sits on the same machine as the classical control software and provides simple state transition OPCODE sequences for assistance in routing. See Fig. 6.

Fig. 7
figure 7

a Trap architecture used for the demonstration. b Movement of potential wells between the zones during adjacent MOVE and MERGE commands. In the final step, the potential returns to the initial three well solution

Full size image

The automated initialization and loss recovery capability can be an important aid to data collection. The circuit programmer specifies the circuit to be executed, but in the laboratory environment, the routine will undergo tomography and so must be executed many times. In a real ion trap, the presence of properly located ions in the trap must be verified before good data can be collected from the routine because ions can be lost during the course of trap operation. This verification is typically accomplished by an experimentalist optically checking for the presence of ions in between executions of a routine—a process which can be time consuming and fundamentally undermines the concept of having a control language that automates the execution of a circuit. To overcome this issue, we install a camera which can view a broad area of the ion trap to detect the presence or absence of ions in all memory locations simultaneously. In our demonstration, between program executions, the experiment control system fans the fluorescence laser beam to cover the trap, takes a picture, and counts ions in each memory zone. If an ion is missing, the experiment control system sends a request to LabQMP to calculate an OPCODE sequence that will load a new ion into the trap and position each ion as is required for the beginning of the experiment routine. The experiment control system then executes this recovery sequence and checks that the new ion was successfully loaded. The experiment control system iterates as needed until the correct number of ions are present in the correct locations. The automated state recovery (ASR) sequence is utilized as follows:

  1. 1.

    the experiment control system performs a block of routine executions;

  2. 2.

    the experiment control system pauses to detect whether or not ions are present in the correct locations as specified by the ASSERT OPCODE at the beginning of the instruction sequence;

  3. 3.

    if ion loss was detected, the data from the prior block of routine execution is discarded (since we do not know exactly when the loss occurred), new ions are loaded and routed to desired state;

  4. 4.

    loop back to item 1 until all planned experiment blocks are complete.

6 Demonstration system

We demonstrated a simple implementation of the circuit compilation and automated system intialization/recovery using a GTRI generation ‘IIc’ ion trap. This is a linear ion trap, i.e., no junctions, and has fifty electrodes that we divided into four zones, labeled M1, M2, M3, and LOAD with the latter serving as the ion-loading zone [20]. The architecture is shown in Fig. 7a. This is the same architecture shown earlier in Fig. 5a.

The limited number of control electrodes in each zone makes it difficult to generate the waveforms for each OPCODE by assembling a basis set of zone waveforms as described earlier. Instead, waveforms were derived for the MOVE/MERGE/SEPARATE OPCODEs applied to each zone using the whole set of trap electrodes to form a complete set of wells for all the ions, including ions that are not involved in the transport. The movement of the confining wells is shown schematically in Fig. 7b for a MOVE and MERGE OPCODE.

We used a low-magnification imaging system and an array of fluorescence beams to image the ion positions during a simple set of transport OPCODEs. Delays between OPCODEs were inserted to allow time for the camera to capture the ion motion when the ions were at the center of the zones and at the zone borders. The results of the transport are shown in Fig. 8.

Fig. 8
figure 8

Camera frames showing transport of two ions under the control of an OPCODEs sequence. Each frame change corresponds to the operation of a single OPCODE. The OPCODEs are shown overlaid on the right at the transition between frames. The ion path between frames has been highlighted

Full size image

In a further demonstration of the OPCODEs, we implemented LabQMP as discussed in the previous section to allow for on-the-fly routing of ions. Given the initial positions of the ions in the trap as determined from image processing on the camera capture, and a final desired set of positions, LabQMP returned a sequence of OPCODEs that would rearrange the ions to the desired final positions. The control software would then execute this sequence of OPCODEs. The OPCODEs LabQMP returned would include LOAD commands if there were too few ions in the initial configuration and EJECT commands if there were too many. During the LOAD OPCODEs, the control software would wait until a successful ion load event was confirmed via imaging of the loaded ion on the camera. After the load event, the control software would continue to read in the OPCODE sequence.

The effectiveness of automatic routing will be limited by the effectiveness of the imaging system to detect the ions. For this demonstration, the wide field-of-view imaging used made it difficult to distinguish one ion from two in a single zone. This lead to occasional routing errors, including ejecting ’extra’ ions when two ions were detected, but there was only a single ion in the well. However, the experiment automatically recovered from routing errors when the control software again checked for the correct ion positions after the routing. Improved imaging would largely remove this issue.

The speed of automatic loading was limited by the warm-up time of the neutral atom source. Collisions between a newly loaded ion in the load zone and the neutral flux would routinely kick the ion out of the trap. We found that it helped to transport a new ion quickly away from the load zone and the neutral flux, check that the ion was still present, and then continue the auto-routing OPCODE sequence. This prevented the situation where the ion was lost due to collisions in the time between being detected and the auto-routing sequence being run. Again, the experiment control system would automatically recover from any such failures, but that added additional overhead to the LOAD operation. This intermediate check of the ion also allowed for improved detection of the number of ions loaded as the load zone had larger background scatter (due to the loading slot) than the rest of the trap.

Routing via LabQMP allowed for Automatic Zone Calibrations of the MERGE and SEPARATE waveforms in the M1, M2, and M3 zones. For each zone, the calibrations were automated via a routine that would, as a first stage, request a single ion in that zone followed by execution of a SEPARATE OPCODE. The system then detects whether the ion remained in the original zone or transported to the nearby zone. A simple search algorithm then determines the compensation axial electric field which separates the two ion transport possibilities. At the compensation field, the single ion is finely balanced between moving or not moving during the split operation. When there are two ions in the well, each ion is pushed by the other off of this balance point: One ion is biased toward remaining in place and the other ion toward transport to the nearby zone. In the second stage of calibration, two ions were loaded and the compensation field further tuned to provide the maximum stability against drift in the stray fields around the trap. These corrections were then added to a calibration lookup table that was used adjust the waveforms for both SEPARATE OPCODEs. The demonstration system did not include motion-dependent qubit operations so heating from the separation could not be measured. For systems that can access the motional sidebands, a third calibration stage could fine-tune the calibrations to minimize the quanta-level heating. Because LabQMP provided the routing and the camera obtained the ion positions for each LabQMP call, events such as ion loss were handled automatically. Specifying the full set of calibrations to perform is as simple as providing a table with the set of zones to calibrate, an adjacent zone to each of the calibration zones, and a single search algorithm parameter for each zone. LabQMP handled all the rest of the architecture-specific operations.

In the future, automatic recovery and ion state initialization via LabQMP will allow for a scheduled circuit, or series of circuits, to be executed (possibly with many repetitions) with user supervision necessary only in the case of hardware issues. Even with such a small trap, quantum circuits meaningful to a theoretician, such as the teleportation circuit shown in Fig. 9, are feasible. Our goal for the near future is to demonstrate millions of unattended repetitions of a simple circuit such as this.

Fig. 9
figure 9

(Top) example of a teleportation circuit that could fit on the demonstration system and (bottom) the mapping of the circuit onto ion motion. We restrict all gates and detection events to the M2 zone

Full size image

7 Future and outlook

An end goal of this work is to provide a quantum programming platform that a theoretician can use to perform a quantum circuit on a real quantum experiment. In the meantime, we have achieved two notable milestones: First, by creating a classical control system that can automatically load ions, route them to a desired configuration, and move them through the ballistic maneuvers required to implement a small circuit, and second, by demonstrating an architecture-independent compiler that can take a small quantum circuit and compile into instructions the classical experiment control system supports.

While we did not call out OPCODEs for single- or multi-qubit gates, it is a fairly simple extension to add support for these to both the OPCODE syntax and the high-level algorithm syntax. Scaling to large numbers of ions will require connectivity between nonadjacent ions. Options for implementing this connectivity include swapping ion pairs in place [21], using the collective motional modes of ions in a chain [22, 23], adding optical interconnects [24], or implementing transport junctions [7, 9, 11]. For each case, support for additional OPCODES will likely become necessary, e.g. the JUNCTION OPCODE mentioned earlier. Finally, parallel independent qubit routing may be a possibility when larger traps become available. The QMP tool, which we used for the compiler, already supports HDLs with both the gate and junction features and it seems that it is eminently feasible to apply the system automation discussed in this chapter to a more complex trap with junctions and gates.

The field of quantum information processing is rapidly advancing. It is always difficult to predict the time-line for the development of such cutting edge technologies, but the basic components for a quantum processor have been demonstrated. We are likely to see demonstrations of increasingly complex quantum circuits over the next few years and tools such as the ones described here will become an important component of such experiments.