Ever since we released the first superconducting quantum processor online as a hosted device over three years ago, we have witnessed an explosion of engagement and new research generated through that access. Yet, the community is broader still, with a diverse set of experimental platforms and system builds quite different in various aspects to our own superconducting qubit devices. Hence, to truly accelerate research and development, we need a software framework that can be universally applied across the available qubit technologies, with the overarching goal of enabling novel quantum experimental demonstrations. Creating an open software platform supporting this broad effort is the only way we will truly succeed with quantum computing.
From its outset, our open-source Qiskit quantum computing framework has been designed to be extensible, and to support research beyond the IBM quantum systems based on superconducting qubits. This inherent flexibility allows for straightforward integration of additional gates, optimization passes, and providers (sources of different systems). Taken together, Qiskit has the flexibility to target different underlying quantum hardware with minimal additions to its code base. To demonstrate this, we have recently added support in Qiskit for trapped ion-based quantum computing devices, and enabled access to the five-qubit trapped ion device at the University of Innsbruck (UIBK) hosted by Alpine Quantum Technologies (AQT). This device resides in Innsbruck Austria, nearly 6,500 km away from where the IBM quantum systems in New York.
The latest Qiskit 0.13 release features support for trapped ion devices via the introduction of XX – or Mølmer-Sørenson (MS) gates – transpilation between superconducting and trapped ion gate sets, and the qiskit-aqt-provider for communicating with the Innsbruck device. Enabling this support took a grand total of three days from concept to data, and highlights the ease at which differing qubit platforms can be incorporated into the Qiskit framework. Here we showcase these new features and demonstrate how a Qiskit user can write a circuit once, and seamlessly execute it on IBM quantum and AQT backends.
Supporting a new qubit platform in Qiskit requires two components. First, if the native gates do not currently exist, they must be specified. For the case of trapped ions, this involved specifying the global MS gate, and its corresponding two-qubit building block the XX-rotation gate (rxx). Once defined, the decomposition rules between different basis gates must added. This allows the Qiskit transpiler to take an input circuit defined in one basis, and output the same circuit rewritten in any other supported gate set. The decomposition between cx, rxx, and global MS gates is shown below.
Figure 1: Decomposition rules between superconducting and trapped ion entangling gates. At bottom, the decomposition of a three-qubit global ms gate into pairwise cx interactions.
Second, in order to execute the circuits, the new quantum computing device must be reachable. In Qiskit, this entails writing a ‘provider’ that handles the API connections, authentication, as well as job submission and retrieval between Qiskit and the host backend. The format for this is spelled out in the Qiskit Specification. Once written, a user can write a quantum circuit in Qiskit, and by simply importing the provider, compile it for the devices accessible via that provider. This means that any of the libraries built into Qiskit, be it for quantum applications and algorithms (Aqua), or benchmarking and noise estimation tools (Ignis), can all be developed and applied to multiple quantum computing technologies effortlessly.
Figure 2: The write once run anywhere Qiskit pipeline. Users supply a single input circuit and communicate the desired target device platform via the choice of backend passed to the Qiskit transpiler. Bottom-left, the resulting Bernstein-Vazirani circuit compiled for the fully-connected five qubit AQT device. Bottom-right, the same circuit targeting the IBM Quantum Yorktown backend with bow-tie entangling gate topology.
Example: Creating Entangled States
Entanglement1 over multiple qubits is a key resource in quantum computation. In this section, we show how to prepare maximally entangled states known as Greenberger-Horne-Zeilinger (GHZ) states on both superconducting and trapped ion quantum computers using Qiskit. This example is instructive, as there are multiple ways to program GHZ state preparation, each being suited to a particular architecture. No matter how the circuit is constructed, Qiskit is able to translate it to the specified architecture. However, the state fidelity will depend heavily on whether the programmed circuit is close to the native architecture gate set or not. Our focus here is mainly on translation rather than optimization.
The table below shows two different ways to program a GHZ state in the left column. These circuits are chosen because of the way they map to the native gates on our systems of interest. In the second and third columns, we show how each circuit gets translated to the hardware via the Qiskit transpiler. The key difference in these systems is that the native two-qubit interaction on IBM quantum systems is the ZX interaction, whereas on trapped ion systems the XX MS interaction is favored by many teams. Furthermore, trapped ion systems can apply the XX interaction onto the entire quantum register via the global MS gate that creates a GHZ state with a single invocation.
The top circuit in this table is the standard textbook method for creating a 4-qubit GHZ state using Hadamard and CNOT (CNOT is equivalent to a ZX interaction) gates. The bottom circuit achieves the same task using a single global MS gate. One can see that the top circuit is more suited to superconducting backends (produces shorter circuit when compiled), whereas the bottom circuit are more suited to trapped ion backends.
Figure 3: Four qubit GHZ states expressed in the native gate sets of the IBM [u1, u2, u3, cx] and AQT [r, rx, ry, rxx, ms] quantum systems along with the equivalent transpiled circuit in the alternate choice of basis gates.
Indeed, after executing each circuit, we notice that the top circuit performs much better on a superconducting system, whereas the bottom performs well on a trapped ion system.
Figure 4: Histograms of runs on a superconducting and trapped ion system. The histograms show the statistics of the output collected after many runs of the circuit on each system. As a reminder, in a GHZ state, we are looking for peaks at the two ends of the histogram, i.e. the probability of observing 0000 and 1111, and near-zero values for the probabilities of other observations.
For near term quantum computing systems, circuit optimization plays a critical role in the successful execution of many algorithms. Such techniques are often closely tied to the specific gate set used by a device, as well as specific hardware characteristics such as gate errors, readout errors, and qubit coherence times. Qiskit has a wealth of circuit optimization passes, many of which are tailored to the IBM quantum systems and their basis gates. Employing similar methods for trapped ion systems, and in particular exploring and extending the noise-aware compilation strategies in Qiskit to this new platform is a fascinating compiler challenge going forward.
With this article, we aimed to illustrate how the Qiskit framework allows simple extension mechanisms to promote the exploration of alternative quantum computing hardware architectures.
