← All episodes
MB

Episode · Jan 29, 2023

Michael Biercuk, Q-Ctrl

Quantum control as the missing layer for stable hardware

Summary

Michael Biercuk, CEO and founder of Q-Ctrl, a company that makes infrastructure software towards making quantum technology useful, is interviewed by Yuval Boger. Michael and Yuval talk about quantum control, a discipline that helps stabilize unstable systems, its application to quantum computers and quantum sensors, Q-Ctrl’s educational software, and much more.

Key takeaways

  • Quantum control treats qubits as noisy analog systems that need active stabilization, borrowing techniques from classical control theory rather than relying only on better algorithms.
  • The same firmware Q-Ctrl builds to suppress noise in quantum computers also applies to quantum sensors, since both are limited by drift and environmental interference rather than just qubit count.
  • Q-Ctrl frames its software as an infrastructure layer, comparable to firmware or an operating system, that has to exist before quantum applications can run reliably at scale.
  • Q-Ctrl also builds educational software to teach quantum concepts, aiming to grow the pool of engineers who understand how to work with these systems.

Get the full transcript on The Quantum Computing Report

Transcript

Yuval Boger: Hello, Michael, and thank you for joining me today.

Michael Biercuk: It's a pleasure to be here. Thank you.

Yuval: So who are you and what do you do?

Michael: My name is Mike Biercuk. I'm the CEO and founder of a company called Q-CTRL, and I'm also a professor of quantum physics and quantum technology at the University of Sydney, where I run a lab that's focused on trapped-ion quantum computing.

Yuval: And what does Q-CTRL do?

Michael: Q-CTRL is a company that builds infrastructure software with the objective of making quantum technology useful. We focus on a real problem that's endemic to all quantum computers and other quantum technologies: instability in the hardware, and error. We provide software that suppresses error so users can get better performance out of quantum computing hardware.

Yuval: And given that you run a trapped-ion lab, does the software work on other types of computers or just trapped ions?

Michael: It's a great question. Everything we build is completely agnostic of the underlying hardware. That is, it doesn't ultimately care if you're using trapped-ion qubits or neutral atoms or superconducting qubits.

We've done demonstrations and validations of up to about 9,000 times performance enhancement in real algorithms on a variety of machines, including machines from, say, IBM that are made from superconducting circuits.

Yuval: How does it work?

Michael: We focus on a discipline called quantum control. Quantum control is the analog of a field called classical control, or control engineering.

That makes everything work. It makes airplanes fly, it makes walking robots. It helps to stabilize what are otherwise unstable systems. My favorite example is a company called Boston Dynamics, who make bipedal robots. I think a lot of people have seen these videos of the robots that dance, and you can hit them with a hockey stick and they stay upright.

Well, they're stabilized using insights from a field called control theory. We do something similar in the quantum domain. This is the area I really specialized in as an academic before I founded Q-CTRL. We look to stabilize dynamically unstable systems using techniques from robust control and what's called deterministic error suppression.

So these are strategies that allow you to implement quantum logic operations or even quantum circuits with a lower likelihood of error, just using these concepts of quantum control, and it's all driven by AI agents that we build.

Yuval: So let's start from a relatively low level. Say you want to optimize the fidelity of a two-qubit gate.

Michael: Mm-hmm.

Yuval: Is that a one-time thing? Is that a periodic thing? Is that an ongoing operation?

Michael: It's a very interesting question. So let me get down into the weeds a little bit here. When we're talking about implementing a two-qubit gate, you're always ultimately implementing some kind of light-matter interaction.

This is generally, you know, a pulse of laser light or a pulse of microwave radiation that induces the coupling between two qubits. Now, in general, the shape of that pulse will be something simple, like on and off, right? You turn it on with some slow ramp, and you turn it off after some prescribed time period that gives you the interaction you want.

It turns out you can be more clever than that. You can shape that waveform: generally, the amplitude of the microwaves and the phase of the microwaves, or I and Q if you like that kind of language. And if you define the envelope correctly, you can implement the same operation with a lower likelihood of error.

Now, your question touches on an important point. Is this static? Do you just do it once and "set it and forget it," as the Americans in the audience may remember from Ron Popeil? In general, you can create what are called robust solutions, which live much, much longer than a standard "just tune it up and calibrate it" approach.

So we've shown that we could make gates, defined or found, if you will, by AI agents, that even after 25 days were still better than that day's best calibrated gate. And it's because the AI agents that do the tune-up actually find bits of physics that humans don't necessarily have insight into, right?

So there are nonlinearities and cross-couplings and little things that the AI agents find via their training process that humans may not know. But in general, even if the window of viable calibration can be extended so much, on a roughly daily basis in our workflow, the AI agents will retune all the one- and two-qubit gates to give the best possible performance, because the systems do drift over time.

These commercial cloud quantum computers, if you run them on a Monday, won't behave the same on Tuesday or Wednesday. That drift is something that we account for with our re-optimization schedule.

Yuval: So does that displace the control signals that the vendors put in? If I were building a neutral-atom computer and I'm using, you know, Rydberg blockade to generate my two-qubit gates, when would you come into the picture?

Is that after a computer is roughly working, or is that earlier on?

Michael: Yeah, it's a great question. We provide products that serve the needs of different users. One kind of user is the researcher, so a team that's building hardware for the first time or building a totally new hardware system.

For them, we provide solutions that they can use well before their system is online to actually design the right control solutions. If they want to find the appropriate design for a Rydberg entangling operation across a large array of neutral atoms, we have a tool called Boulder Opal that's appropriate for that task, right?

The research-y tasks, the deep-down, nitty-gritty details driven by the users themselves. But this idea of replacing the gates is just one step in a whole workflow we offer in a brand-new tool called Fire Opal, which is targeted at end users. So those are people who want to use quantum computers: algorithm designers, developers, and the like.

Now, they're not interested in the how or why; they just want it to work. And so gate replacement is one step in a roughly seven-step flow that we implement. We replace what you could call the machine-language definition for all the one- and two-qubit gates on the machine.

And when we execute an algorithm via our tool, we call from a lookup table of the new gates. But that's, as I mentioned, just one step. We also correct errors at the circuit level. We have some fancy compilers that consume information about the back end, that is, the hardware system, to understand which qubits have the best performance and which have the worst, to avoid the bad ones, and a few other steps.

And in aggregate, we've assembled all of these capabilities such that on a single pass of the workflow, a user gets the best performance but doesn't have to do anything. They don't have to configure anything. There are no settings. There isn't even an option to choose from. It's just Fireopal.execute, and you tell us which back end and which circuit, and that's more or less it.

So we've focused on providing solutions that are tailored to the needs of very different classes of users: those who really want to be hands-on, turning the knobs, and those who simply want the machines to work better.

Yuval: Let me make sure I understand. You mentioned gate replacement. So my circuit has a CNOT gate.

What are you going to replace it with?

Michael: Well, that CNOT gate is almost never native. For instance, on the IBM systems, you have a cross-resonance interaction. That's the physical interaction that gives you a ZX pi-over-two kind of interaction. So there's some net interaction.

If you combine that net interaction with single-qubit unitaries, that gives you the equivalent of a CNOT. But each of those decomposed operations is ultimately some shaped microwave signal, and we redefine the shapes of all of those microwave signals using AI agents. It takes only about six minutes.

As I mentioned earlier, we do this roughly once a day on a calibration schedule, but completely autonomously, with no human intervention. These AI agents find new definitions for those shaped waveforms that give you the same net mathematical operation, like a pi-over-two pulse or whatever it is, and do so with a lower likelihood of error.

So again, that's just one step in the flow. It's only one place where errors can creep in, and our tool set covers errors that emerge not only at the gate level, like we're describing right now, but also at the circuit level, et cetera.

Yuval: It used to be said that you shouldn't buy a car that was manufactured on a Friday afternoon, when everyone just wants to go home. Are you saying the same thing about quantum circuits? You know, use the results shortly after calibration as opposed to an hour before the next calibration?

Michael: Well, it is a true statement that these systems do drift.

Anybody who's used the commercial platforms much, or even their own hardware, understands well that you want to be recalibrated. We have focused on ensuring that there's a calibration window where things never get too "bad," in air quotes. But, you know, generally we find that the platforms now tend to be quite stable.

I will even give credit to some of these organizations for responding to some of the demonstrations we've done. When we published results about drift in the IBM system, the IBM team responded by changing their calibration schedule to keep the machine in a tighter spec range. So the platforms deserve a lot of credit for the hard work they do in making sure these machines perform well.

And then Q-CTRL, via our tools, just makes sure that they perform at their peak all the time.

Yuval: If you reach an optimal pulse for a single-qubit or two-qubit gate, how different is it across the same machine for other qubits or other two-qubit gates? And how different is it between machines of the same manufacturer?

Michael: They tend to look very, very different. The reason for this, in general, is that across the chip and across various architectures, you find all sorts of weird classical idiosyncrasies, if you will, that in aggregate give you a different Hamiltonian at the device level. So what could this be?

This could be the transmission characteristics through the dilution refrigerator to the device. The cross-chip packaging can have microwave resonances. You can have some nonlinearity in a particular circuit element. You can have some unexpected cross-coupling between a pair of qubits that's different from some other pair of qubits.

All of those are related to device manufacturing, and all of them give you, frankly, very widely disparate performance levels across a device. We published some work in Physical Review Applied a couple of years ago where we showed that even on the very modestly sized machines from IBM, five- and seven-qubit machines, you would have enormous performance variations just in the single-qubit gates, right?

From 10 to the minus four all the way up to 2% or 3% errors. And that comes, in many cases, from the chip itself, that is, the circuit that's quantum, but also from all the classical things around it. Now, as a result, when we deploy AI agents or any kind of control that's designed to give you better performance, the solutions tend to differ a fair bit.

In many cases, they're not human-interpretable, right? If we use, for instance, deep reinforcement learning to design a new two-qubit gate at runtime, which we did and published in PRX Quantum in 2021, that doesn't give you insight into what's going on. It's just some funky waveform, and that funky waveform, the result of a 20-dimensional optimization, turns out to saturate the T1 limit in the device in terms of how well the gate performs.

Now, what you get on qubit pair one-two looks nothing like qubit pair five-six. So there's very little you can glean from those waveforms. That's actually why we focus so much on using AI to drive these processes, right? Obviously, we do reduce the parameter space using physics insight.

It's not just free rein, do anything you like. However, using AI agents is, in our view, the most efficient way to do this. They're effectively free, and they can be parallelized easily.

Yuval: Today, some of the transpilers choose the particular qubits based on connectivity, for instance. They could decide to minimize the swaps and so on.

Does the information measured by your tool also feed, or could it feed, into these decisions? Or alternatively, do you have a replacement tool that makes better decisions?

Michael: Both. In our workflow, we do have our own compiler and transpiler. I would not say the front-end compiler is where we have the most innovation.

We borrow insights that are widely used in the community. We've made one that focuses on stability. Some of the compilers and transpilers out there can be quite stochastic. You run the same thing four or five times, and you get widely different outcomes. But really, the interesting stuff happens at the next step, where we consume information about the back end.

That is, what are the T1s and T2s and the error rates, as measured by the hardware provider, in order to do this circuit routing? So your transpiler will be aware of the connectivity, but there's more that you could consume. You could understand: are qubits one and nine quite noisy, and should you therefore avoid them?

Are qubits four and six subject to very substantial readout errors? So that goes into our selection, or layout, tool. We consume information from the back end, as I said, but we also execute test circuits, and those test circuits give us additional information about key noise and error sources that we find tend to dominate circuit-level performance.

Those also go into our circuit layout tool, in order to ensure that we are delivering near the peak of what the machine can provide.

Yuval: Is there an opportunity to use the tool to create faster gates?

Michael: Yes. We did this before, and we published it in PRX Quantum. In that case, we used deep reinforcement learning, but we actually have about nine different optimizers available.

We used deep reinforcement learning to come up with new gates that were three times faster than the default DRAG pulses but didn't suffer increased leakage error. So again, very funny-looking waveforms that don't have any easy human interpretation, but they were able to give gates that were much faster.

The question for an individual user as they define these things is: what is the best path forward? Is it reducing gate time, or is it simply saturating T1 and canceling some coherent error processes? Both are feasible. We tend to focus on not messing with the gate durations, because circuit timing is a very important part of how you make a circuit perform well, and so we generally leave the times fixed.

Yuval: One last question on pulses before we move to another topic.

Michael: Sure.

Yuval: Would control system theory also be applicable to annealing schedules, to shuttling atoms around if you need to move them, and so on? Or is it limited at the moment to gates and qubits?

Michael: Another fantastic question. These kinds of optimization problems, and the classical optimizers that we deploy, the closed-loop optimizers, can actually be used for a very, very wide range of problems.

We've looked at things with customers and partners like tuning up the coefficients of deformable mirrors to get the optimal readout efficiency on an array of neutral atoms. That's done in closed loop. It's done fully autonomously by these agents, and it results in much higher readout fidelity.

We have done things as trivial-sounding as tuning up PID loops, right? There are heuristics for how you tune up a proportional-integral-differential servo loop. You can use those heuristics, or you can just allow a computer-controlled agent to perform the search and find better solutions faster, with less iteration than a human using these heuristics.

So there are a range of these very classical problems, atom shuttling and the like, that can be attacked with the same agents. It's why we love them so much. Just let the agent do its thing, and it doesn't actually matter how quantum your process is. There's some reward function that you want to optimize, whether it's black box or it's a deep reinforcement learning agent that figures out what the actions do.

And the agents are very efficient.

Yuval: Your company, I believe, also has a tool for learning quantum computing. How did that come about, and is that just community service, or is there a business rationale behind it?

Michael: It's a little of column A and a little of column B. Obviously, if you look across the ecosystem, many companies have put out various kinds of educational material, because there are lots of people out there who are interested in learning quantum computing.

Now, we discovered that there were many, many inbounds to Q-CTRL from people who had heard about us and were interested in what we did. But in any discussion, it became apparent that they were simply not ready to use our professional tools. They were far too new; they just had brand awareness.

Now, we're very grateful for the brand awareness, but we didn't want to either, one, push them away, or two, start doing consulting, right? We are not application consultants. We are not in the business of helping an organization understand how quantum computing is relevant to them. There are fantastic companies that do that, but it's not us.

And so we thought about what we could do based on some of the things we had built. And there was a little bit of happenstance. We had a product in the market early on that was not successful. That product was looking to provide a very visual interface for quantum control solutions, right?

Performing hard quantum control optimizations with a very visual interface. And we learned through our user feedback that people were very excited about learning from it but weren't so excited about doing with it, that is, solving their hard problems. So we separated those two things.

We have a tool, Boulder Opal, which is really for the R&D teams and is Python-based, and we had this visual interface left over. What we decided to do as we continued to engage with the market was convert that into an educational tool. And what ultimately emerged is what's now Black Opal.

Black Opal is an ed-tech tool. It's like Duolingo for quantum. It has over 350 individual lessons, and it's really designed to put everything in one place, because one of the bits of feedback we had from the community, and even from our own team members who were newcomers to quantum from the business side, for instance, was that they had to look in 20 different places to find the information they were seeking in order to get going in quantum computing.

There are some great YouTube videos. There's the Qiskit textbook, which is fantastic for more advanced things. Here and there, there are bits of information, like "Quantum Country" from Michael Nielsen. But they wanted one place that had it all, and we wanted to deliver it in a different way: with interactivity and visualizations and 3D JavaScript and things.

So Black Opal is that. It gives you everything you need to go from zero to actually programming real quantum computers, and it's extraordinarily visual. It's very beautiful, with lots of interactivity. There are interactive Bloch spheres. There are interactive circuits. You can visualize the effect of circuits using circle notation that we teach you.

You can learn about all the different hardware paradigms, learn about different algorithms, learn about what QASM is and how we program quantum machines at the gate level. All of these things are in one place, including real insights that you don't typically get about why quantum computers are not here at scale.

That is the problem of noise and error, and then how control can help overcome it. So it's a one-stop shop, and it is a retail product that has a big free component, but we also sell it to major enterprises. We found tremendous traction in big consultancies and system integrators who are looking to train up their own teams or to empower their customers.

There is just nothing quite like it in terms of its comprehensive nature or the content. Much of the content, by the way, is made by Chris Ferrie. Chris Ferrie famously wrote "Quantum Physics for Babies," and he's also a professor in quantum technology. But altogether, it's turned out to be a wild success, by focusing on this real need we identified in the market.

Yuval: And is the same control theory also applied to sensors, or is your sensor activity something else altogether?

Michael: Ah, this is another great question. We knew from day one that everything we did was applicable not only in quantum computing but also in quantum sensing. And obviously the investor zeitgeist, if you will, in 2017 and '18, when the company was brand new, was really, really focused on quantum computing.

It was the newest and shiniest thing. In late 2020, we finally had enough stability in the company to start expanding into a new area, and we began hiring for an activity in quantum sensing. Now, our work in quantum sensing is not just what you'd call component-level innovation. We are not making better glass cells or smaller atomic devices.

We do some of that, but our innovation is at the software level. We look at how these control-theoretic concepts, deployed as software, can augment the performance of quantum sensors, because quantum sensors are limited by physical processes that are almost identical to those that limit quantum computers.

When you take a quantum sensor out of a beautiful, pristine laboratory environment into the field, you typically lose about 1,000x in performance, whether in sensitivity or stability or whichever metric you prefer. That's because of background clutter. There's all sorts of stuff in the environment that interferes, like magnetic field fluctuations, but it's also because of something called platform noise.

When you take, say, an atom interferometer and put it on a boat, the engine vibration causes a new source of error. It causes sigma X and sigma Z-type errors associated with laser amplitude and frequency fluctuations. Those can be combated using control-theoretic concepts. So we focus on deploying robust control, that is, making the devices more resilient against error in software, but also on developing totally new protocols that are unlocked by leveraging robust control.

There are a lot of things that people have tried over the years that have never really worked, because the errors in the individual constituents, the individual components of, say, a sequence of operations and light-matter interactions, are just so bad that they overwhelm what you see. When you combine these concepts with robust control, you can really do new things.

So we've accomplished some extraordinary things that we will reveal next year. But one thing I will note is that we decided to build our own quantum sensors. This is because there is no platform that is the quantum sensing equivalent of IBM Quantum or Amazon Braket. We don't have the ability to log on to someone's quantum sensor and try our software, so we've decided to build our own.

We have both commercial off-the-shelf benchtop demonstrators and field-deployable systems that are augmented in software.

Yuval: As we get close to the end of our conversation, you mentioned investors, so I'm curious: how large is the company? How is it funded? What are your plans for the coming year?

Michael: Q-CTRL is right now just about 80 people, in Sydney, Los Angeles, and Berlin. LA is our fastest-growing office; Berlin is our newest. We are entirely funded by venture capital, so we have a wide range of backers from Silicon Valley and a handful from Australia. We're very proud of the investor base that we have, which includes names like Sierra Ventures and Data Collective.

We have In-Q-Tel, we have Horizons Ventures. There are really fantastic organizations on our cap table. There are some exciting new things that you'll hear about in 2023, but overall, we are expanding quite rapidly, and we are hoping to double the size of the company in the next 18 months or thereabouts.

So at a time when they say "flat is the new 2X" in the current environment, we decided to skip that and go right for 2X.

Yuval: So, a hypothetical question: if you could have dinner with one of the quantum greats, dead or alive, who would that be?

Michael: I mean, I would love… It's almost quantum. How about this? I would love to have dinner with Marie Curie. It's because she, in her public expressions, spoke about things that transcend just science. In fact, one of my favorite quotes comes from her, about fear and understanding.

"There's nothing to fear…" Ugh, I'm going to butcher the quote if I try to do it off the top of my head. But, "Now is the time that we should understand more, so that we should fear less." I think that kind of mind, one that crosses the scientific and the social, is something very profound, and I would love to interact with her if I had the opportunity.

Yuval: How can people get in touch with you, and what kind of people are you interested in hearing from?

Michael: Well, you can always find us at q-ctrl.com. You can find me on Twitter, @MJBiercuk, B-I-E-R-C-U-K. Well, at least you can for now; we'll find out if that lasts. I'm also on Mastodon, for what it's worth, and LinkedIn.

We're interested in hearing from people who are end users of quantum computers, or teams that build quantum computers and really want to do as much as possible with the machinery without worrying about what's happening "under the hood," in air quotes. We want to make quantum technology useful with our technology.

We're also interested in anybody who wants to get into the field, because we are hiring like mad. As I mentioned, we will double the company in the next 18 months or thereabouts. So if you have a background in software engineering, or a background in quantum control… We operate the world's largest team of experts in quantum control.

There is nowhere like it on the planet. That is the technical core, if you will, of everything we do, and we'd love for people to bring their skills and join us. But we are also growing in business development and government relations and people management and all the things that make a startup into a great, successful company.

So we're always interested to hear from anybody in the community who wants to be part of this extraordinary journey.

Yuval: Michael, thank you so much for joining me today.

Michael: Thank you, Yuval.