Transcript

Yuval Boger: Hello, Jonathan. Thank you for joining me today.

Jonathan Reiner: Thank you very much, Yuval. A pleasure.

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

Jonathan: I thought what you said—we’ll start with a simple question first. So who am I? All right. So first of all, I’m a physicist. I was trained at the Weizmann Institute. I graduated from there as a condensed‑matter physicist, where I worked on topological materials, so some relations to a certain branch of quantum computing then. After my graduation, quantum computing was starting to blast, actually, and at this point I also wanted to relocate. So I relocated to Sydney and joined the group of Professor Michelle Simmons. It was also a company—it’s still a company—Silicon Quantum Computing, and I worked there as a postdoc for about four years, working on silicon‑28 and really, really cool quantum‑computing devices based on phosphorus atoms in silicon.

Back in 2022, I decided that I wanted to go back to Israel. I kept in touch with the founders, Jonathan Cohen, Itamar Sivan, and Nissim, whom I know from the Weizmann Institute. And I asked them, you know, how are things in Quantum Machines? And it turns out that things went quite well. I joined Quantum Machines as a product manager, and since then, it’s been three years now in Quantum Machines.

Yuval: So today you are a product manager at Quantum Machines.

Jonathan: Today—I started as a product manager, but today I’m leading a team within the product team called the Product Solutions team.

Yuval: Product Solutions probably addresses customer problems. So what are the key customer problems or challenges that you’re seeing today?

Jonathan: Okay, yeah. This is a very, very good observation. But you know what—maybe to answer this question, I’ll start by describing why I started as a product manager and now I’m leading the Product Solutions team. Maybe I’ll say a bit about the journey we went through at QM to build this structure.

I would say that the challenge we started facing after a couple of years from delivering our first product, the OPX+, the controller, was really a challenge of double‑edged complexity. By that I mean that there is a complexity that belongs to the product itself. We didn’t talk about it—maybe we’ll get to it in a second—but the product is quite complicated. It has aspects starting from mechanical engineering, the density of the outputs, aspects of the analog front end, logic design, various levels of software—a lot of disciplines that you actually need to master in order to be a product manager of such a product. So you need to be an engineer or a physicist with a very strong engineering orientation.

And then on the other side, there is also a complexity that comes from the market. Starting from different qubit modalities—Quantum Machines is trying to serve, at this moment, various qubit platforms. We haven’t bet on the winning horse yet. We’re trying to build control electronics for multiple platforms. So you need to be a really strong physicist and understand spin qubits, superconducting qubits, AMO, with all their different aspects.

Then you also have the business side: different personas as customers—startups, enterprises, national labs—all of them behave differently. So to handle this complexity, we created two teams: a team of product managers with more technical orientation that write product requirements, and a team of Product Solutions physicists. Today we understand that what Quantum Machines is bringing to its customers is a full solution. This team represents the customer side within QM and makes sure that we build in our roadmap the perfect solutions and products.

Yuval: My simplified timeline of quantum is that many years ago the challenge was just to build a qubit that works—or two qubits that work. Then the challenge became error correction. And now the challenge is becoming scaling to a sufficiently large number of logical qubits. Do you see it the same way? Do you think the order is different—scaling first and error correction later? What’s your view?

Jonathan: First of all, I do think that the challenge of building very, very good qubits is still an important challenge. This stands at the basis of everything you build. As someone working a lot on quantum control, I also think that quantum control has to contribute a lot at the physical‑qubit level—things like embedded calibrations and very clean analog signals, and so on.

This attitude, by the way, I heard from a couple of mentors—starting from Professor Michelle Simmons. She’s a big advocate of this approach. Also John Martinis, whom I met in Sydney when he was on sabbatical and is today a close collaborator of Quantum Machines. He worked for many years, in Santa Barbara and now in his new company, on material problems and optimizing things at the single‑qubit level. So I don’t think you can pass the bar—the simple reality of the quantum error‑correction threshold tells us this—without investing in the single‑qubit level.

Now, it’s very true that when you go to larger scale and start thinking about quantum error correction, there is a whole new set of problems you need to deal with. And many of those problems are transferred into the domain of quantum control, which QM is a main player in.

Yuval: As you think about the challenges that customers are facing today versus two years ago, what has changed?

Jonathan: Right. So two years ago, many customers just wanted to get things going. One of the things that QM brought—one of the things that really made us leaders in the field—was the ability to give customers, mostly academics but also startups, the ability to start quickly. They wanted to iterate quickly over their experiments and qubit‑control protocols.

One of QM’s early success routes was to come up with a very flexible high‑level language, QUA. This language is Python‑like and very easy to use to program your dream experiment. But it was still, by virtue of a compiler that is core IP for us, able to squeeze a lot of performance from the system: low‑latency feedback operations, precise timing of operations, harnessing FPGA resources using our unique processor‑based architecture—what we call the hybrid control approach—while writing code quickly.

That was true two years ago. Today, things have changed. There is much more emphasis on very good analog performance because we’re trying to squeeze every bit of fidelity from the qubit. And on the other hand, there is the question of low latency and efficient links within the control system and to external accelerators. Today it is understood, as people attempt quantum error correction, that many workflows will be classical workflows offloaded to FPGAs, GPUs, CPUs, other FPGAs, or even ASICs.

So today people really care about these integrations. And this comes with interest in high‑level software. People want to make sure that if they write gate‑level descriptions or a layer above—like a logical‑qubit language—they have compilation and a full software ecosystem that allows optimization, error mitigation, error suppression, and expansion of the entire stack.

Yuval: In which parts of these—error correction, error mitigation, calibration, and so on—does Quantum Machines provide?

Jonathan: We start from the very bottom. We don’t make qubits, but we connect to them at the physical level, and then build up. The first layer, after being able to write pulse‑level protocols, is the calibration layer. This is definitely where we’re expanding a lot.

In the early days, we would tell customers: look, you can do whatever you want with QUA—and they would write their own calibration nodes. Over time, we gained so much experience in calibration that we could contribute significantly. Alongside the customer success team, we created open‑source software libraries based on QUA embedded in Python. Customers use them and they perform optimally on our hardware.

We expanded beyond that. We understood that you need to automate calibration workflows. About a year ago, we released a new product called Qualibrate—an open‑source software that allows the user to handle calibration workflows. This is a very interesting problem: to find the right balance between freedom for the user—who wants to iterate quickly—and a robust workflow with potential for massive automation.

Qualibrate has a GUI, but one that does not limit the user. The most important thing is that users can bring their QPUs to maximum performance without feeling limited.

Now we are expanding to the level above calibration: quantum error correction. We started showing first demonstrations. Our motto is that the control hardware should not be the bottleneck. So we collected product requirements: what do we need to build the right hardware infrastructure for quantum error correction? A couple of requirements involve latency of feed‑forward and bandwidth.

This led us to develop another product called OPX‑NIC. The initial development was done with NVIDIA—we call this reference architecture DGX Quantum. This system is connected at very low latency to our controller. The unique thing is that users can write CUDA or C++ if they’re using the GPU or CPU, and iterate quickly over different quantum‑error‑correction decoders without being limited by hardware.

After we built it, since QPUs that support large‑scale error correction aren’t widely available yet, we found another interesting use case: using reinforcement‑learning agents running on the accelerator to perform calibration very quickly without assumptions about the system. This is another trajectory we’re going to invest in.

Yuval: Some estimate that to build truly useful quantum computers, you’ll need about a million qubits. That’s a lot of Quantum Machines boxes. Is that realistic, or will customers not need a million control lines?

Jonathan: Yeah, so I once heard someone say—when confronted with this—that this is only if you choose the wrong type of qubits. So yes, in some architectures, we might need millions of physical qubits to do something meaningful. People are making plans based on that.

Accordingly, we will need to change the form factor, price, density, and power consumption of our electronics. It cannot look like 500 or 600 Quantum Machines boxes connected together.

We make progress step by step with the community. Already now, in seven or eight years of Quantum Machines, we delivered two product generations with a 5× improvement across density, cost, and power. But we need to be more aggressive. That requires research into new technologies—cryogenic electronics, ASICs, and making architectural commitments.

In the future, we won’t see server rooms with racks and racks of controllers. But we do need higher density. We need better qubits so that we won’t get to millions of physical qubits per logical qubit. Every week we hear new ideas for reducing the physical‑to‑logical overhead—and from the control side we will contribute to this reduction as well.

Yuval: What does it take, in your experience, to run a quantum computer? Assuming I install one on premises, with a lot of Quantum Machines hardware connected—what skillset should I hire for to manage the system?

Jonathan: That is a very interesting question. Maybe I’ll tell you something about my team. One branch of Product Solutions is bringing product requirements from customers, so we need highly trained physicists. Another sub‑team is the research team, which acts as a super‑user. They calibrate quantum computers with partners and at our own facilities at the Israeli Quantum Computing Center in Tel Aviv.

There, I learn what skills are needed to operate a quantum computer. At this point, you still need strong physicists. Many problems have to do with understanding qubit physics. Breakthroughs in calibration or system‑performance improvements often come from physics.

They also need to be good programmers—though with AI coding tools, this is easier. They shouldn’t be afraid to write software at a high level.

Depending on the facility, they may or may not need hands‑on experimentalist skills. But they need to understand the system: amplifiers, filters, etc. These things are still relevant at scales of tens or hundreds of qubits.

Yuval: You mentioned the “wrong qubit modality” earlier. What’s your favorite modality?

Jonathan: So here we have a problem of inheritance. Many advocates of different qubit types have spent their careers on them, and it’s hard to back off from that.

From this perspective, I am a big fan of spin qubits—this is my alma mater. I find appealing the idea that if we solve the problem on a unit cell, say 10, 16, or 32 qubits, we could replicate this using silicon fabrication technologies: mature, reproducible, cheap.

In my team we divide people by domain expertise; I consider myself a spin‑qubit physicist.

That said, like everyone, I’m very impressed by the rapid progress in AMO—both ions and neutral atoms. They’ve smashed some barriers very quickly in the last five years.

Yuval: As we get close to the end, I wanted to ask about IP. When Quantum Machines helps with calibration, machine learning, and now error correction—do customers worry about their IP becoming yours? Where is the distinction?

Jonathan: Oh yes, absolutely. This is a sensitive question, so I’ll answer carefully. When you work at the level of support we provide—our customer success team is almost 50 people—you get exposed to some level of customer IP. And we work with many parties; we are not exclusive with anyone. This poses a challenge.

So this is a question of maturity and professionalism. We are working hard to set firm standards: making sure customer‑facing people are not working with competitors; providing software features that allow customers to classify and protect content.

For example, traditionally in a local lab network, users send programs and everyone can access them. But in larger, multi‑user, cloud environments, you might have a unique calibration routine with IP you don’t want to expose. So we implemented measures allowing users to encrypt programs used for calibration, while leaving others open.

As a community, moving from lab to industry, we must pay attention and ensure customers feel their IP is well protected.

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

Jonathan: Okay. I started from the nuts and bolts of quantum computing—fabrication, measurement, now control electronics. But one question that always fascinated me, and I never had the chance to look at closely, is the question from the other side: the fundamental limits.

One of the greatest physicists asking this type of question is Seth Lloyd from MIT. I’ve heard him many times. He asks things like: what does the Hamiltonian of the universe look like? Or more tangibly: what are the physical limits of quantum computers that come from thermodynamics?

For me, this is super interesting. A quantum system, entanglement spreading, decoherence—even in a closed system if it’s big enough. Looking at the barrier between quantum computing and thermodynamics is fascinating.

So having dinner with Seth Lloyd and hearing his perspective would be a really fun night out. And he’s also very entertaining. Maybe you should invite him to the podcast.

Yuval: Jonathan, thank you very much for joining me today.

Jonathan: Thank you, Yuval.