Q&A: Architect of New “Inspire”; Quantum-Computing Platform on Spin Qubits and Programming Quantum Chips

Richard Versluis, the system architect, describes Europe’s first public-access quantum-computing platform

7 min read
Photo of Quantum Inspire
Photo: Marieke de Lorijn/QuTech

IEEE Spectrum spoke with Richard Versluis of QuTech in the Netherlands, which last week launched Inspire, Europe’s first public-access quantum-computing platform. Versluis, who is the system architect at QuTech, wrote about the challenges of building practical quantum computers in Spectrum’s April issue. 

Richard Versluis on…

Spectrum: Tell me about QuTech. Is it a company, a government agency, a university, or some combination of the above?

Richard Versluis of QuTechRichard VersluisPhoto: Marieke de Lorijn/QuTech

Versluis:QuTech is the advanced research center for Quantum Computing and Quantum Internet, a collaboration founded in 2014 by Delft University of Technology (TU Delft) and the Netherlands Organisation for Applied Scientific Research (TNO). TNO is an independent research institute. About 70 percent of our funding is from other businesses. But because we receive considerable base funding from the government, we are not allowed to make a profit. Our status is very much like the national labs in the United States.

Spectrum: So you and your colleagues at QuTech started working on quantum computing in 2014. Had you built a full quantum computer there before now?

Versluis: Researchers at the University of Delft began working on quantum technology much earlier, in the 1990s. Indeed, the first qubit in the world was a coproduction between the University of Delft and NEC. TNO, however, only started working on quantum technologies at the start of the cooperation that created QuTech, where we’ve built many quantum computing systems.

We have 25 dilution refrigerators with various types of quantum chips, both for quantum communication and quantum computing. Some have only a small number of qubits and some much more. But up to now, they were only used by graduate students and postdoctoral researchers to perform research on quantum computing.

One of the reasons QuTech was founded was to move towards products (pre-prototypes and demonstrators), which is more the expertise of TNO. We’ve not just been working on quantum chips that could be used in the lab for research purposes, but full systems—with all the hardware, software, and tooling needed to create programmable quantum computer prototypes.

Spectrum: So the Inspire platform is not just another quantum computer chip: It’s both hardware and software and an accessible interface for others outside of your organization to use to access your new system.

Versluis: Yes, that is correct, although the principle is not new. IBM already offers several quantum computers based on superconducting qubits (transmons), with a nice programming interface for external users. They were a huge inspiration for me to start creating such systems at QuTech. There are some differences between the systems of IBM and the systems we have, though.

First, IBM’s systems are more mature—they also have lots more money to spend! They provide more qubits than our systems. The main difference, though, is that we offer a full open-access open-data system. Although we don’t own the code or data that people submit, we require that those people who use our system for free allow us to make their code or data available in open publications.

Another important difference is that we created the first system in the world with a spin-qubit chip (albeit with just two qubits to begin with). This chip is based to a large extent on standard semiconductor technology and the footprint of the qubits is about a million times smaller than the transmon qubits used in our other system and used by IBM. This makes it possible, in principle, to put millions or even billions of qubits on one chip.

BACK TO TOP↑

Spectrum: Tell me a little more about the user-facing side of things. Am I correct that you’ve created a sort of integrated development environment (IDE) with which somebody from outside your organization can start programming something? To run a program on real hardware, does it cost money? Do you have to have your job scheduled, like back in the day of mainframes and punch-card programs?

Versluis: We have a graphical IDE that you can access through all major browsers. It provides a simple editor that allows you to program quantum algorithms. They are checked in real time for syntax errors, and the resulting algorithm is rendered as a “quantum circuit.” You can also select which back end to run the program on, either on one of our simulators or one of our chips.

We also provide an API for interacting directly with the system without the Web-based interface. This API provides an interface for people already working with IBM’s quantum systems or people who are used to using quantum simulators.

You can run a program for free, but for people who want to keep their code to themselves, we offer paid accounts. With these accounts, you can run more complex algorithms on our simulator (you then use the simulator version that runs on one of our national supercomputers, at SURFSara) or on our quantum chips. With a paid account, you can retain full ownership of the code and data.

Jobs will be scheduled. On the simulators, you can put as many jobs as you want in the queue. On the quantum chips, we allow a maximum of three jobs in the queue per account, because we want to provide fair access to these chips to everybody.

Jobs that run on the simulator (up to 31 qubits) can have run times ranging from a few seconds to a few days, depending on the size and complexity of the algorithms. Jobs that run on the hardware must be very short, because of the limited coherence time: They are typically executed within less than a millisecond. You usually execute an algorithm a few thousand times, which leads to a total run time of a few seconds for one algorithm on a quantum chip. But there is some overhead in terms of compiling the algorithms into control signals, uploading these to the control hardware, and the return time of the Internet. This makes one job typically take 30 to 60 seconds to run.

BACK TO TOP↑

Spectrum: Doesn’t it take an enormous amount of computing to simulate a 31-qubit quantum processor?

Versluis: To simulate 31 qubits (using 64 bits per qubit, double precision) takes about 100 gigabytes of memory, which we execute on one node on Cartesius, one of the supercomputers in the Netherlands. We could simulate up to 37 qubits on this system, but we are not offering that capability to the general public. With a lot of tweaking you could push things to about 40 qubits on such a system, but that would require 32 terabytes of memory.

BACK TO TOP↑

Spectrum: Tell me more about your spin-qubit chip.

Versluis: The Spin-2 processor is indeed novel. Not the chip itself: There are other, mainly academic, institutes that work on spin-qubit chips and have them in their labs and do experiments with them. Ours is, however, the first system in the world using such a chip for quantum programming, with a full gate set.

This requires a system that automatically calibrates the chip and keeps it tuned to correct for any drifts that occur over time. Every 4 hours or so, the system will check its main functions and automatically calibrate itself when needed. The calibration takes from 1 to 30 minutes.

The other quantum-computing chip we have, the Starmon-5, differs in some aspects from the IBM chips. The IBM chips available offer much higher coherence times, but the QuTech chip combines really fast two-qubit gates with higher accuracies. Also, IBM offers a full gate set for its chips, whereas we don’t for this chip (for now).

The philosophy we’ve followed—to provide open access with a Web interface—follows in IBM’s footsteps, and IBM really deserves the credit for pioneering such online systems.

BACK TO TOP↑

Spectrum: My previous understanding was that the leading candidate for quantum bits were superconducting loops and that the second most popular strategy was to use trapped ions. So this spin-qubit approach is taking me by surprise. Has this been a promising candidate all along? Or did you and your colleagues make some sort of advance in fabrication that just now allowed it to be built?

Versluis: Ion traps and superconducting qubits are indeed leading the pack in numbers of qubits at the moment. However, with both systems it is pretty uncertain whether and how they can be scaled to a few hundred qubits or even to the millions of qubits that would be needed to do error correction, which is generally accepted as one of the few ways to build fault-tolerant quantum computers.

Spin-qubit chips are more difficult to fabricate. The processes used are similar to those used in CMOS fabrication, but the devil is in the details. You have to make systems where you can trap a single electron in one place and are able to control and measure its spin. This is quite complex.

People have been working on spin qubits for many years now, because their tiny size makes them attractive. Spin-qubit systems have a typical pitch (distance between qubits) of a few tens of nanometers. (In our system, the pitch is 50 nm.) But because you are controlling a single electron, the system is very sensitive to noise caused by neighboring electrons and atoms that also have spin, which is a magnetic property. So it is like you are controlling a small magnet surrounded by other magnets.

This is one of the reasons why our spin-based chip only has two qubits for now. We have to tune and calibrate these systems often and we need to compensate for cross talk. This cross talk extends over hundreds of nanometers, so when we add more qubits, the tuning system will become more complicated. We have solutions that work in the lab, but those are not robust enough yet to put online.

Going from 2 to 10 qubits in an actual system outside the lab will take us maybe a couple of years. Just as people experienced in the development of the earliest transistors, the initial steps are sometimes the most difficult.

BACK TO TOP↑

Spectrum: Let me wind down with a question about what can be computed with your Starmon-5 processor. Is this just a demonstration system for exploration and learning or can it compute something of value faster or more cheaply than it would cost to perform that same computation classically?

Versluis: Both of our systems for now are for exploring and learning, and also finding out about the technical challenges and requirements for scaling. We cannot compute anything of value faster or more cheaply than can be done classically. Even with Google’s chip, the one that was used for their supremacy experiment, it was not possible to do anything of value yet. Although that experiment did show that with chips with a few dozens of qubits you can do things that you cannot do classically anymore, even with supercomputers.

I think that in about five years we’ll be able to do things with programmable quantum chips that you cannot do classically within the same time. But they will still not be really useful and will have limited economical value. But I also think that within 10 years we’ll be able to use quantum computers to our advantage and that they will outperform classical systems on some specific use cases of value.

BACK TO TOP↑

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}