Embedded - 483: An Ion of the Highest Fidelity

Episode Date: August 23, 2024

Rick Altherr spoke with us about high-speed control, complicated systems, and making quantum computers. If you want to know more about building quantum computers, take a listen to Rick’s MacroFab episode: The Nuts and Bolts of Quantum Computing. If you want to make your own quantum circuit simulator, it only takes 27 lines of Python: A Quantum Circuit Simulator in 27 Lines of Python. What about if you actually want to know about quantum computing? Rick suggests Quantum computing for the very curious while we look back at Embedded.fm 344: Superposition, Entanglement, and Interference with Kitty Yeung, talking about her Quantum Computing Comic book and Hackaday lecture series.  Rick works for IonQ where they do trapped-ion quantum computing (there are different physics methods for making ions dance to the tune of quantum computing). If you want to talk to Rick, maybe to get his advice about your resume or career prospects, he sets aside a few hours each week to share his wisdom: https://calendly.com/mxshift You can also find Rick on Mastodon and LinkedIn. He was also the guest on 311: Attack Other People's Refrigerators about security hacking and mentoring. Transcript

Welcome to Embedded. I am Elysia White, alongside Christopher White. Our guest this week is Rick Alther, and we're going to talk about transporters, spooky action at a distance, no-cost mentoring, and other requirements of the infinite improbability drive. Really? Hi, Rick. Welcome back. Hey, thanks for having me. Could you tell us about yourself as if we saw you walking around DEF CON carrying some really strange gold bling? Hi, my name is Rick. I am a full stack engineer. I've done everything from ASIC design to user experience on everything from embedded systems to hyperscale.

I have done a lot in information security work in x86 servers and firmware. And now I design real-time control systems for quantum computers. Real-time control systems for quantum computers. Real-time control systems for quantum computers. Not quantum control systems for real-time computers. No, that would be a very different thing. That there probably is, I mean, that would be like Miro's company. Yeah, okay. Are you ready for lightning round?

Is anyone ever ready for lightning round? We are. We've done it 500 times. Yeah. It's kind of easy from this side. How is the cat in Schrodinger's box feeling? Depends on when you measure it. How many standard computing processors does it take to run one qubit worth of circuitry? About 36.

That tripped her up because the next question is how many standard computing processors does it take to run one qubit? I think that arcade cabinet took like three. What is your favorite type of physics? Oh, I don't know that I have a favorite type. I did really poorly in physics. That's why I'm a software engineer. But we're going to talk about quantum computing. There's going to be lasers in here.

There's going to be weird tunneling things. There's probably going to be relativity nonsense. That's engineering. be weird tunneling things. There's probably going to be relativity nonsense. That's engineering. That's downstream of physics. I've had to learn a lot of physics to make to do my job, but physics is not why I'm here. And E&M,

I mean, that was probably, you know, core. Yeah, but if you're doing physics, quantum physics instead of quantum computing computing you're learning about how the universe isn't real and nothing matters versus trying to solve problems let me write that down the universe isn't real and nothing matters anyway uh well there's a show title getting to the old standards complete one project or start a dozen uh i would love to complete one project, but I always start a dozen.

What's your favorite fictional robot? I really like Marvin. Do you have a tip everyone should know? I know I thought about this ahead of time and now I completely forgot. Was it a computing tip? I don't remember. Does it take notes? Sorry.

I mean, that's perennially a tip for me. So you were on the MacroFab podcast with Parker and Steven in July. Yeah. Could you summarize that hour or hour and a half long podcast in like 20 solid seconds? There's a lot of classical computing that happens to make quantum computing happen. And ultimately, quantum computers are not quite ready

to do useful things today. But in the next five years years that will probably change. And so there's this idea, when we talked to Kitty Young, art by physicist Kitty, we talked about how to program for quantum computers, how to work within the simulator to make algorithms. But that's not what you work on. Correct. So my employer, IonQ, makes actual quantum computers based on trapped ion technology. So one of the common things that comes up early in discussions about quantum computers is that when you move into the world of physical quantum computer implementations, it's kind of like the 1940s for digital computing.

There's a wide array of possible technologies for implementing quantum computing, and we don't really know what the tradeoffs are between all of them. We know some of them. So there's a whole bunch of different companies that are all pursuing wildly different directions. They're all quantum computing. They're all able to run those same quantum algorithms. But the physics and the actual machine design and the capabilities of what type of algorithms or what size of algorithms can be run on these machines is wildly different. So trapped ion happens to be one approach. The ones that you often see in magazines and news articles where it looks like a chandelier, those are superconducting. And there's like five or six other kinds that are also being pursued

right now. And there's at least one kind of high-profile company, if I remember correctly, and the name is escaping me. Is it IBM? No. Quantum-ish Computing? They, like, they... Yeah. Well, I mean, there's a bunch of companies that are reasonably well-known.

So IBM is definitely there. They do superconducting and are quite prevalent. D-Wave is what I was thinking of. Right. D-Wave also does superconducting. A lot of what folks talk about there is they build a machine that specifically is geared towards running simulated annealing problems. They're using superconducting qubits, but the design of the system is geared towards that one particular problem. Okay, so they're not as general purpose as what other companies are trying to do. Correct.

So from what I understood from the Macrofab podcast, which Christopher hasn't heard, so he'll keep us honest, but for the rest of you, I'm just going to assume you've heard at least part of it because it was really interesting and it talked about how you actually start to build these things. But I didn't really understand how you do controls. And on that show, you talked about seeing fluorescing ions and capturing ions and all the things you can do to make them spin or not spin or cool them down or heat them up or make them do little jazz lines. But one of the things that struck me most was at some point you said five picoseconds. Uh-huh. And I remember from a Grace Hopper conference talking about a nanosecond wire and how long that was. And it's like, I'm going to go with 10 inches, but something around there.

And that's the distance light travels in one nanosecond. And the important part of that is that when you're designing circuitry that needs to handle that sort of thing, you really have to start thinking about distances. Do you have to worry about that? Or is five picoseconds, you know, a couple, well, 5,000 10-inch wires? It's, um... Is pico smaller than nano?

Yeah. Yeah. Oh, okay. So now, you know, my question is even more valid. Sorry. It's like an inch and suddenly you're... It's like a millimeter. All right. I don't care. It's small.

So there's two different timescales at play. And that's part of where things get a little confusing. So what we are controlling is laser pulses primarily. And we do need to control precisely when a laser pulse begins. Essentially, the ion that is captured in the ion trap has a phase precession, a rate of rotation that's already happening just naturally. And we need to time our laser pulses to interact with that ion associated with that phase precession. So we have to line up our laser pulses to be in phase or out of phase to cause certain effects to happen. So one of the challenges is getting that time alignment on a single channel. And in our case, we only run at 250 megahertz, which is four nanoseconds, which is still fast, but it's not nearly as fast as picoseconds. And so for that, there's a clock distribution system and

everything, and it's a very tightly controlled 250 megahertz. And one of the key pieces with the quantum computing is that you don't actually have to be aligned with the qubit at the start of the computation. The very first thing you do is an initialization process where you use a laser pulse to actually set the quantum state to a particular value and when you do that you're also initializing a phase alignment between the laser pulse and the qubit so you essentially establish an absolute reference point by that first laser pulse so the four nanosecond the accuracy of that four nanoseconds has to do with every clock tick afterward. And we know that we can accurately model at four nanoseconds and we can actually figure out how much phase adjustment we need to do

in our arbitrary waveform generator to match the phase precession of the qubit. Where we get into the picosecond range is that in cases where you're doing entanglement, where you have two qubits that you're actually interacting with simultaneously, the simultaneously is the important part. We need it to not only be on that four nanosecond tick, but we also need those two pulses to happen simultaneously, as close as possible. Otherwise, you incur an additional error of just the time difference between the two channels. And that's where we actually maintain that.

We use a clock distribution system that has PLOs and phase alignment. And so that's where we ensure that the clock, when it is reaching RFPGAs that implement these arbitrary waveform generators, they have delayed the clock such that they all are coincident. They all experience the clock edge within a few picoseconds of each other. And what length are the pulses of the lasers on the order of? Time-wise or wavelength? Time-wise. Oh, time-wise. I would have to go look.

They vary. They're fairly short, although a single gate operation, which is actually a couple of different pulses, can take up to 100 microseconds. Okay. I'm assuming these are like diode or diode-pumped lasers. No, actually. So we typically have the laser as a constantly-on laser source. Oh, okay.

And then the arbitrary waveform generators are actually driving a variety of devices. One is an electro-optical modulator. Another is an acousto-optic deflector. And another one is an acousto-optical modulator, another is an acousto-optic deflector, and another one's an acousto-optic modulator. And so the idea is that we can use GPIOs to basically turn on or off the laser with a shutter.

And we can also use the AOMs to the RF comes in as a modulated waveform and that causes a physical material to distort that when you shine the laser through it the modulation from the RF modulates the laser pulse itself.

Okay. That's much easier to understand. Those of us who didn't take optics or really any of this what I got from that was you have some different modulators, acoustic optical modulators, which makes it sound like you're changing frequency ranges.

And you're looking for... No, that's all I got. So he's got a laser that's always on, and they want to either deflect it or make it so it's not going through anything, or add a modulation on top of it. And so they've got materials that they can either pass an electric current through, which will change the property of the material so that the laser is stopped or allowed through, or another material that they can apply RF to,

and that causes physical changes in the crystal or whatever that alters the wave shape of the laser. The wave shape or the amplitude? The amplitude, yeah. Or possibly changes the wavelength. That's also possible, but I don't know what they're doing. But they could also change the polarity? Well, the polarization, certainly.

Polarization. Yes. Yes. Those are all things that can be controlled. In our case, it tends to be that we have an IQ waveform that we've generated with the arbitrary waveform generator. And we modulate that into a constant tone for the RF itself. And then when the AOM sees that, it mostly ends up being a modulation on amplitude. Cool.

It starts to look like a radio circuit. It is. An AOM can be thought of as an upconverter. Okay. Okay, so you have like 14 of these that you all have to keep synchronized? So on current systems, we have 32 channels of arbitrary waveform generator, and they are all synchronized and execute on these four nanosecond clock ticks, 250 megahertz,

and they're all synchronized on that clock tick being observed within a few picoseconds across the system. So this goes back to my initial flailing question, which was that means that you have to know how long your traces are. You have to know how long your traces are. You have to know how far everything is from one another in order to do this synchronization because an extra couple inches adds error.

Is that right? Okay. Yes. And in fact, for the clock distribution, there are thankfully off-the-shelf chips that implement that for you. So you can take two of these clock chips and put them at opposite ends of a cable, and they basically measure and communicate back and forth what the phase difference is. And so they will automatically delay one end so that the phase alignment at those chips is the same.

Wait, you bought an off-the-shelf solution? For that timing part, yes. Can I come work for your startup? Sorry. Be careful. There's lots of bad off-the-shelf solutions out there, too. I know. I just, I'm tired of seeing people trying to invent the same things over and over again.

It seems expensive, but your time is so expensive. Okay, sorry. But you talked about other control systems. So you must be feeding back what you get from your system so that you can create these waveforms. Well, there's a variety of control systems at play. There are various kinds of servos that are looking at different waveforms, mostly in the optical space,

where you're actually looking at the output from one of the lasers, either before or after modulation, to account for physical effects in the optical path that you can't control for otherwise. Then at the higher level, the control system around a quantum computer is you run a sequence of gates,

and by virtue of quantum computing, like quantum effects, you can't observe what's happening as the intermediate states. So you're essentially doing these laser pulses to change the physical structure inside of the ion. And at the end, when you go to measure it, you need to actually, that's the only time you actually see the result, but you only see a one or a zero at the end. And so the higher level control system is things like, I need to run this sequence of gates. I need to then perform this measurement process of causing the ions to fluoresce and counting their ions or counting the photons emitted by each ion. And I have to run calibration procedures that determine where the threshold is between what we call a bright or a dark ion.

Because the number of photons emitted is not a physical constraint that stays constant. It's got a lot of variables with temperature, with pressure, with all sorts of different attributes of what's going on in the system. And so we have to run those calibration procedures. And so there's higher level control loops that are taking that information and applying corrections to feed into, to make the determinations about was that a bright or a dark, as well as, you know, minor adjustments for where we aim the laser pulse to actually hit the ion correctly. So a lot of these are control loops that run very slowly, but they have real-time effects

in terms of being able to apply the corrections as we perform the instructions that are actually running. But a lot of the control system aspect that I talk about is actually just implementing a classical processor that allows you to perform these sequences. It's not necessarily a feedback system, but it's

still a control system. And you say classical computer to differentiate it from a quantum computer. That tends to be the terminology in the field. I don't particularly like it. I mean, they're digital computers. That's what they are. Yeah, they stole it from regular physics. Everything in physics that's not quantum is classical physics.

Right. Yep. Inherited. So, okay, so you've said there's a lot of FPGA that's doing the tight timing control stuff. And so what surrounds that? So there's just a standard

microcontroller or embedded Linux? There would be some Raspberry Pis involved. So it's actually multiple FPGAs. So each eight arbitrary waveform generators is one FPGA. Okay.

And so we have to have multiple FPGAs to hit all the arbitrary waveform channels. Then we have another FPGA that deals with generating GPIOs because we also need those to be time correlated. And so a lot of the challenge is actually building another FPGA that is just coordinating all the other FPGAs and designing all the instruction sets. These are essentially each arbitrary waveform generator channel and the GPIO dispatcher. They are all their own independent digital computers

that are running their own independent digital computers that are running their own independent programs where the instruction includes a timestamp of when to execute the instruction. And so then there's a top-level FPGA that deals with taking a program in and actually staging into all the different processors the different instructions for each channel, and coordinating the start of the overall program.

This is like a microcosm of a whole network, right? You need to have NTP, and you need to have the corrections. Have that, have 1588, have reference inputs. Putting timestamps on the instructions is a leap that I wouldn't have thought of. That's cool. Yeah. I was imagining something much more fixed function, like, okay, we have these arbitrary

waveform generators, and we tell them which waveform and we tell them when to start and stop, but this sounds like it's much more general purpose. Well, it is kind of that. These are specialized digital computers and that the instruction for an arbitrary waveform generator is, at this particular time, start playing the samples at this memory location, with this amplitude, mixed to this carrier frequency, with this phase adjustment, and play it for this long. That's still a lot. That's all one instruction.

Yeah. I mean, that seems so simple. You just, you know, it's like you're a violinist's still a lot. That's all one instruction. I mean, that seems so simple. It's like you're a violinist. Play a tone. How hard could it possibly be? And then you also have the conductor who's telling the entire orchestra to do that simultaneously. You're pretty new to quantum computing. Yes. I mean, you've done, I think we talked with you when you were working more on security and hyperscaling, making computers that are better able to take care of themselves. That's how I think of it.

How did you, I mean, did you just wake up one morning and say, I don't know what I want to do today. I think the only solution is quantum. There's so many hear not hear jokes. Nobody ever does that except in 1915. I was looking around at some options and I was still working heavily in the security area. And I applied actually for a in the security area and I applied actually for a director of security position with this company. And the response I got was, we've actually decided we're not going to be hiring for that role this year.

But your background includes a bunch of control systems and embedded systems work and we would like to talk to you about that. So I was very clear up front that I knew absolutely nothing about quantum computing. And they assured me that that was not a problem. And it turns out that that's very true. Just like in a lot of other domains, when you, you may come out of a university with, you know, I know how to write software, and then you realize that it's very specialized when you're talking about building stuff in the automotive world, or when you're building stuff in medical, or when you're writing programs for a Mac versus writing it for Windows. It's the same thing. Like, I need to learn about all of the special aspects of quantum computing. But ultimately, I'm running Yocto on a bunch of systems.

I've got FPGAs that I'm interacting with. I'm writing device drivers. We're writing most of our software in Rust. It's a pretty standard software setup for an embedded system. But you're not shipping thousands of units yet. No, in fact, we have shipped, what, one. The way this has worked to date is we build the machines for our own use within the company. We offer that

as a cloud service for being able to run quantum circuits. So we actually do own and operate four quantum computers that we've built, but as far as produced for other companies or other organizations, it's a very limited number. It's an area that the company is working into. of classical computers where the IBMs of the world were more about handling your data and your algorithm needs,

not necessarily in producing computers right away. Right. And largely it's because they're expensive, they're hard to build, and you need the specialist to be able to help you operate the machine and probably help you adapt to whatever algorithm you're trying to do to actually run on the machine.

And that's two specialists. One is the algorithms person, and one is the engineering caretaker of the device. Mm-hmm. Listening to the Macrofab podcast, yours doesn't have to be super cold. It just has to be in vacuum. Is that right? So trapped ion, in theory, can operate at room temperature at standard atmosphere pressure. The challenge is the reason that it is under cryo and under vacuum

are purely about reducing noise and air resources. So if you imagine that you have a line of ions being held, where each ion is held in an electromagnetic field, if an oxygen molecule happens to just whiz past and hit it, it's going to knock your ion right out of that field. The energy from that oxygen molecule is going to be so much stronger. So putting it in vacuum reduces the chances of that. Cooling it down reduces the chances of that. But it also means that we don't have to be under as deep of cryogenic temperatures as some of the other technologies. So like superconducting, they have to get down to actually being a superconductor,

and then they have to go colder to actually reduce their noise. So those systems often have to reach millikelvins, where our system can operate in the 3 to 5 Kelvin range. I don't even have a concept. It's very cold. Yeah. Yeah, and when we come back to control systems, the very slow control systems are things like

the system that actually runs the cryostat and is regulating the liquid helium cooling system. And is that just going to be a standard control system, like a PID loop that's running fast enough that it can react well? Okay. Yep.

And then you also need to have some form of trapping the electrons, keeping them in their little row for their can-can dance. Yeah. So that is a separate piece of equipment. But yes, largely the trap itself

is, think of it as a channel down the length of the trap device. And you're causing these ions to come into that trap one at a time. And we could talk about how if you're causing these ions to come into that trap one at a time. And we could talk about how if you're interested. And along the length of this channel are little electrodes. And so those electrodes get hooked up to another chassis that has a bunch of DACs and RF generators.

And we use static voltages as well as, or I guess not static, but DC voltages as well as RF to generate an always changing RF field, or electromagnetic field, that actually creates a little pocket that the ion

is trapped in. This is one of the things where you can't actually get an ion to be perfectly held in position, but you can build a rotating electromagnetic field that creates a little section where it's basically always

falling back towards the center. Screaming in its little cage. What are these ions of? So usually in our systems, it's either ytterbium or barium. Those are heavy. They are very heavy. There's a lot of different ions that can be used for these types of operations.

And part of what you're looking for is how stable is the ion over time, but also how wide the energy band gap is between two energy states. Because ultimately, in our trapped ion systems, we're actually using the energy level of the ion to encode the quantum information or one dimension of the quantum information. So that's the whole thing with the lasers and everything is actually doing Raman transitions to go between these two energy states. And so you want them to be very, very rigid energy states, but you also want them to have a wide enough gap that you can do the transitions between them relatively straightforward. Presumably wide enough that they emit a photon that is easily detectable? Correct. Okay.

Yes. In origami, we would call it bistable. Yeah. Yeah, it's very similar. Yep. Okay. So, are you sure that... You can't see the ions.

Even with, like, a microscope, you can't. Well, you can. So this is one of the cool things with trapped ion is that because we use the fluorescence to actually measure them, that fluorescence can be in the visible spectrum or it can be in an infrared spectrum. So you can basically choosing whichever ion species you want changes which wavelength that it fluoresces at. But you can actually just put a camera that is sensitive to that range

through an optics path, and you can actually look at individual ions on the screen. You can't do it while it's computing, but you can do it in steady state when it's just ion. You can look at the photons that they emit. Right, you can't look at the ions themselves. Yeah, they don't like to be seen.

Well, it's a pretty close approach. Yeah, what's the difference? They're very shy. What's the difference? I mean, that's all we're seeing is photons bouncing off of something and re-emitting things. I'm just not sure any of this is real. It's real. I mean, we're talking about...

Things that are very small. Smaller than a golf ball, certainly. Exactly. Yeah, yeah. Maybe marble-sized. It's very hard to manage them. So, you have all these systems, and it's a very... They're kind of a diverse set of systems, right?

You've got a cryogenic system. You've got something that's dealing with the ions, and none of this has to do with quantum computing except to set up the computer. That's right. So what does it look like to actually talk to this computer? What is the user interface of this computer? I know this one. It's Python. Okay. So I just import PyQuantum and I'm done?

Pretty much. Yeah, I mean, if you're trying to run programs, there are a couple of different frameworks that are, Qiskit is one of them. Another one is Pennylane. And yeah, they're largely written in Python. And you describe what your quantum circuit is using whatever gate set is interesting to you. And that sort of is a reference back to the, we don't quite know what the best way to build these machines are.

Just like in Boolean logic, you can build anything out of and and not. In quantum, there's a variety of different gates that you can use as a primitive gate set to build any other gates, but there's different sets. And we don't actually know which one is ideal. And the native gate set of a machine is different for these different technologies.

Before you go on, is that like there used to be computers that were trinary and there used to be computers that were based on, I mean, there's NAND and NOR as two separate ways of implementing Flash. Is that what you mean when you say there's different gate sets? They're based on different gates? Yeah. I mean, they talk about it as quantum gates. And you can think of it similar to an AND or a NOT or an AND or a NOR.

And there are similar gates. There is a c-not gate, which is kind of like an XOR with some special properties. But these gates, if you were to draw it as schematic, it's much the same way. That's why we talk about quantum circuits, is you actually do draw it out kind of like a schematic with boxes for the different gates. But there are different universal gate sets. And so each machine has a different set of is an abstract universal set that is mostly used when actually creating quantum circuits. And part of the challenge in some of the high-level software is actually doing that translation, which is very similar to converting from C to your assembler for your individual machine.

It's a very similar process. You have to look at the gates that you have, and you have to translate them to the gates that the machine actually implements. Okay, but presumably between this Python script, whatever, yeah, script that describes the quantum circuit, presumably that gets boiled down to a lot of control system stuff that does, or is the setup separate?

Like maybe in a 1916s computer, somebody would come in and flip a bunch of switches in the morning and then somebody would come in and put the punch cards in. Is the Python the punch cards and has nothing to do with how the computer is set up? Or does it actually, or is there a translation layer that says,

okay, they want to do this circuit and now I need to do this with the cryo, and I need to trap these ions? Well, I mean, there's going to be a step in between there. The sort of LLVM step. Well, but does it at all? It's a little bit of A and a little bit of B. So there are a bunch of systems that are just there to keep the machine operating,

just like you have the fan control circuit in a classical computer. That's akin to the cryo system. And there's a bunch of those systems that are just running constantly to keep the system in its operating environment. And those are typically implemented on software processes on an x86 machine running Linux. They're fairly slow, and they mostly talk to specialized hardware to do those operations.

The programs themselves, you start from this Python framework, and you write your circuit in that framework. And yeah, there is a translation step. So each provider that makes quantum computers offers a plugin to these frameworks that converts it to the native gate set of their systems. That's step one. Then step two is submitting it to their cloud service, because these are all cloud services so far. And inside the cloud service, typically it goes through an optimizing compiler, which does a bunch of things like removing redundant gates, finding alternate circuit implementations that are equivalent but use fewer gates or fewer qubits. The optimizer.

Right. So you run an optimizing phase. And then it comes down to actually converting this optimized circuit for a specific machine. So coming back to the discussion about calibrations, each machine, we're operating with individual ions that are a naturally occurring thing, right? They're an elemental source. And they don't have perfect behavior. They're all slightly different. And in fact, the machine itself will change as temperature, pressure, all sorts of things, right? There's all sorts of different components in the system where mechanical alignments will shift, components wear out, etc. So in between running actual circuits, we will run other programs that

basically perform calibration measurements of the system. And we'll do that multiple times a day. That information gets fed back into this control. You can think of it as a compiler. It's not quite a compiler. It's kind of more like an assembler, but it's also not really an assembler. But we're taking that optimized quantum circuit and you're applying all this knowledge about the physical state of the machine. So you know, for example, the fidelity of each individual ion, how likely it is to actually produce the correct output at the end of a circuit. And so you can choose that an ion that is going or a qubit that is going to have a lot of gates on it, or the most gates on it in a circuit, you might allocate that to an ion that has the highest fidelity. You might also rearrange the qubits to allow for some faster execution depending upon what's happening.

And all that happens, and then you convert it into the raw instruction stream that actually gets fed down to the control systems. So we need to basically write a program per arbitrary waveform generator, a program for each IO output. And all those programs, you know, we're translating from that circuit into the individual laser pulses on specific ions at specific times. And then how those laser pulses get enacted because it's usually multiple things. You have to open the shutter and turn on the modulation for the laser

at exactly the right time kind of thing. The flow chart for this must be enormous. So, okay. So I have kind of a high level dumb person question um so there's all this setup time to set up the problem and then presumably the problem is whatever thing you're solving happens effectively instantaneously. But is it like a fusion situation where, yes, we can run fusion, we got a watt out,

and that's very exciting, but we can't really do anything? Or is it, or is the time, see what I'm asking is kind of, is the time constant of setup so overwhelming the benefit of running the problem on a quantum computer that it washes it out?

Yes, Rick, are quantum computers useful? No, that's not what I'm asking. I'm asking, no, because they're definitely useful for solving a set of problems that we're working on. But is the trade-off there that the computers we have do it fast enough that there's a benefit? Does that make sense? It does make sense. And that's actually what a lot of active discussion in the industry is.

So often you've probably heard people talking about quantum supremacy, which I hate that term. But it's the idea that at some point, running quantum algorithms is so much faster than anything classical computation can do. But in the nearer term, that type of benchmark is so far in the future. In the nearer term, we have these quantum computers that are able to run programs. I guess there's a little bit there of the setup time is measurable. It is a significant portion of the execution time. But the actual execution time itself is also important. Because quantum circuits don't execute instantaneously.

Right, okay. Each gate that you have in the circuit is a step that has to be executed. And so it takes a certain amount of time to actually cause that effect to happen. So the laser pulse for a single cubic gate might take 100 microseconds, but for a two-cubic gate, it can take 500 microseconds. And you might have a thousand gates of different mixes. And so just like you have instruction execution times, you have gate execution times. But as far as

the size of the computers that we have and the types of problems that we can run on them, there is this give and take with, can you simulate a quantum computer on a digital computer faster than you can actually run it on a quantum computer?

And so far, the answer has generally been yes. You can run simulations faster and more efficiently than actually running the quantum computer. Now, the quantum algorithms themselves tend to have a linear relationship. To make the problem larger, the actual scaling up of the quantum problem is you need a linear number of qubits or you need a linear number of gates. It's not actually linear, but it's closer to linear.

Where when you look at the quantum simulation problem, it requires exponentially more classical computation hardware to actually perform a larger quantum computation. When you increase by one qubit, it requires an exponential increase in the calculation power. So there's going to be this crossover probably in the next five years where for some types of problems that fit into the number of qubits

and the number of gates that you can run on quantum computers will be more cost effective than building out a quantum or a classical system to run a simulation of the same size so where where is the focus on optimization of these computers then? Is it more on the surrounding infrastructure to have the setup happen faster, or is it more on the actual qubit management, getting the gates faster, that kind of thing? It's both, because they're related, unfortunately.

At least in a trapped ion system, the number of ions that you can put in the trap is actually quite large. You can make a trap hold a lot of ions. The challenging part is that the way entanglement is done through an ion chain is through the axial motion. I'm going to take a little detour here to answer your question.

So when you run a 1Q gate, you're actually doing a laser pulse on one particular ion. And you're either inserting or removing energy from that ion to adjust its energy level. But when you do 2Q gates, what you actually want to do is cause an entanglement between the two gates. And if you're inserting or removing energy from a laser pulse, that's one aspect of it. But you also need to capture an information transfer from one ion to the other.

Well, if you have this chain of ions, ions naturally repel each other. So when you have a chain of them, they're all lined up with space between them, kind of like a Newton's cradle. And they also have a relationship where if you cause, well, they all tend to vibrate a little bit in that space. They're all kind of pushing on each other and moving around. But they're constrained in two axes and only allowed to move in one.

So they kind of move along the length of the chain. They're wobbling back and forth just a little bit, pushing on each other. So the way you get that information transfer from one ion to the other is you actually hit one ion with a laser to do the

laser pulse to insert or remove energy. But that actually causes, if you time it just right, you actually get the ion to push one direction or the other along the axis and basically cause that motion, just like when you strike the first ball in a Newton's cradle. And because of the repelling force between the individual ions, they all move with that. It ricochets, or not ricochets, but it ripples down the length of the ion chain. So if you time your second pulse at another ion further down the chain just right, you insert energy at the same time that that axial motion passes through that second ion. So the reason that this is all important is that as you make your chain longer and longer and longer, you incur more error as you try to figure out that timing relationship of actually doing 2Q gates. So your 2Q gates get

less fidelity as your chains get longer. So in terms of scaling it up, there's questions of, well, how long can you make the chain before your fidelity falls off? We don't know. That's active research. And then there becomes a question of how do you knowing that that is a limitation how do you scale up to having multiple zones that you can be working is that you know having two different sections of the same trap where you are doing quantum operations that don't have that coupling of um you can't do two Q gates between them because they don't have a relationship. They don't have that axial motion capability. Another area of research is having two traps where you actually use fiber optic cable to couple the photons between and use that as the

information transfer. So there are a lot of things in the, how do you make the physics work? But they couple back into, there's a whole bunch of setup questions that come into play when you get into that. If you're trying to do the photonic interconnect, how you prepare the qubits becomes very different. My eyes are wide and my brain is zipping around like its own little ion trapped in my head. Okay, I'm going to ask questions I have written because I need time to process. This one's actually from Owen. How did the DEF CON audience react to the way the demo model of the real quantum computer in real 24 karat gold was presented? This is the callback to the bling.

Yeah, so we brought an ion trap, which I would love to show the picture, but this is a podcast. It is a fairly small device. It's a microfabricated piece of metal made out of pretty exotic materials. And part of that does actually have a gold plating on it. And that's in a display case. Because gold here is the cheap part? I wouldn't say it's the cheap part, but I wouldn't say it's the expensive part either. But you have problems with oxidization.

You have problems with just like all sorts of things. You need materials that hold up under vacuum, and you also need them to maintain pristine through all the different environmental changes you're going through. So that's where the folks that designed the traps, it often involves a lot of exotic materials and processes. But we brought that in this display case, and it's just sort of a nondescript little display case. And if you don't know what it is, it just kind of looks like a funky-looking object. It doesn't look like a computer part. So we had a whiteboard that just said, you know, real quantum processor in 24 karat gold and an Admiral Ackbar drawing that said, it's a trap. So actually, that was very well received by the DEF CON crowd. They, you know, it's kind of playing at the, look, it's a

quantum computer. It's like the bleeding edge of technology, bleeding edge of science, and yet we can talk about it and have fun with it. We don't have to be too serious about it. And it drew in a lot of people. They would see this whiteboard, and they're like, well, what does it say? And then they're like, real quantum processor. Oh, wow, that's really cool. And then we'd, you know,

they would want to get a really close look of it and everything else. And they also brought an entire chassis of the control electronics that we took apart and let people poke at and ask questions about too back to how you got into this um you were working in security and one of the things that quantum computers are known for is their ability to crack keys, passwords. Is that still something you work on? Or have you kind of shifted over to, wow, there's a whole bunch of new delicious information in the physics here? So Shor's algorithm is a well-known algorithm for factoring numbers. And it's considered to be considerably faster than the equivalent for

classical machines. The problem is that nobody can run it. There aren't any classical machines that can simulate a quantum computer big enough for it to run it quickly for the size of numbers used in things like RSA. And certainly quantum computers are not that big. So one of the messages at DEF CON was every time somebody came up and then they saw quantum computer, they're like, so can this break RSA keys? And the answer was always no.

Like that's 20 plus years away. But there's a lot of other more interesting things that can happen in the near term. But then with my background on the security side and coming especially from firmware security, it's a lot of steering the conversation back to a quantum computer is one small piece of quantum computation technology. You know, like everything happens inside of this trap at a scale that you can't see. And everything around it is classical computers. You still have all of the same IT challenges, all the same firmware security challenges, all the same software security challenges throughout this entire system that makes the quantum computer. So even though I'm spending all of my time primarily focused on instruction set design

and how you run programs on this I do get involved with the discussions around and how do we actually secure these machines how do we design them to be enterprise ready put this in somebody else's data center and they can have confidence that it's running the correct software that it hasn't been tampered with, etc. And then we also had a panel discussion talking about, well, what are the

new and interesting parts about quantum computing as far as security goes? And really, we came back with, nobody really even knows what to ask. It seems like there's probably side channels that we're not aware of that come from how the machines work. In pure quantum theory, when you measure a qubit, the quantum information has been destroyed. But there can be remnants in the control system of what sequence of operations were run. We won't know the exact quantum information, but we can tell you about what algorithm was run. So there's things like that that are slowly being figured out, and this is a very new area. Even though quantum computing

itself is decades old, it's still in that very early age of understanding the capabilities and also the practical realities of the machines that implement it. It's cool that people are thinking about that level of security implications, though, at this stage, because people weren't thinking about side-channel attacks in 1965 or whatever,

right? So with standard microprocessors. So I think that's pretty interesting that effort is being made to at least consider, okay, what's new about this and what could be done? What sort of attacks are there? Moving into this job and being able to talk about the latencies and the delay channels, Ewan had another good question. Was there much cross-disciplinary terminology that overlapped causing confusion? I'd say there's more terminology differences where the same concept has different names.

Yeah. And figuring out where those are has been a problem. There's also been a lot of difficulty bridging the gap in knowledge that is only germane cross-disciplinary when you actually get to the point of building quantum computers like this. So I had a thing post recently on my Mastodon talking about teaching physicists about branch delay slots. And this is a real thing, and it comes in because we're talking about how do you do conditional execution in a quantum circuit. So there is a way where I can measure only a subset of the qubits, and then I want to be able to change the behavior of the rest of the circuit. But I have to do this in a real-time system. And the idea that in a large complex system with all these processors running in parallel, that I observe the result at one physical place in the system,

and that the time it takes to actually communicate the branch direction that I want to all of the processors, all of the components in the system, takes a significant amount of time, is just something that the physicists have never even had to think about. Yet this is also something that we as software folks, even embedded software folks, don't usually think about it because it's something that happened so long ago. I mean, it's still an issue in processor design today, but it's become a very niche part of processor design to think about how long your branch information takes to propagate. And we have known solutions for it. This is where speculation comes in. The whole reason,

one of the big reasons for speculation is to fill that time with useful work. But in a quantum system, I can't speculatively do laser pulses. I can't undo them. So we're having to go back and revisit some of these things that are well-known in classical computing and completely unknown from the physics side and bring it together and say,

there's well-known patterns here, but we can also point to why they don't work now. I have so many, again, in my brain. It's like that time that I worked with the biochemist about hydrophobicity of chemicals and their uptake in the human body. And I was optimizing the code. And I said, well, why don't we do this? And he said, wow, that's a really interesting chemical insight.

And I'm like, no, it's just that the code would be more efficient if we did that, because they're effectively the same path. Yep. And we have those exact kind of conversations all the time. Switching topics entirely, you do some mentoring. And if I were to sign up on your calendar for a time slot for mentoring, what would happen? You'd be asked what you want to chat about as part of the sign-up, and I would get that. And really, I would just be there at that time. We get a 30-minute time slot on my calendar. I carve out a couple hours every week.

And usually I just ask, like, what do you have questions about? And offer my insights and guidance from my years of experience in the industry. I came into computing and into the companies I worked at through what I guess would be a reasonably straightforward process, but also I come from a very humble background, so my experience of it, I didn't have a lot of mentors along the way. I had to figure a lot of things out, and I ended up working at some very big companies, working on very frontline technology. So just offering a lot of insight on how to work with different managers, how to figure out where to go next in your career, you know, whatever happens to come up. So I've been consulting for a very, very long time. And I used to love consulting. This is the mentoring call now, by the way. It starts now. Yeah, yeah. I mean, we've already done the hour podcast. Now it's just the mentoring call. Wait, but I didn't get a calendar link sorry

uh and so i'm i know a person who's willing to offer me a full-time job and it sounds kind of interesting but i'm not sure i can go back to doing full-time i'm not even sure what would be expected of me anymore wait did you tell me about this no i didn't this is a shock to christopher why do you keep doing this to me? Because I was thinking about it, and now that we have Rick here, I figured now would be a good time to

do the mentoring. I'm your actual business partner who you'd be quitting the business to go work somewhere else. But okay. I feel like I'm being pulled into something. You don't have to answer. Sorry, we are over time. No, it's an interesting question.

Go ahead. I have had this very conversation with a variety of folks that have moved into consulting and then had offers to come back. And it often does come down to a question of what are they offering and kind of where are you at and what you want to come back. And it often does come down to a question of, what are they offering? And kind of where are you at and what you want to look for? Part of consulting is really the freedom to choose the types of problems you want to work on and also who you want to work with. And you give up some of that

when you go back to working full-time. You're usually lined up with a specific project that you're going to be on even well past when it's shipped. And you may not agree with what the next direction is or the next project that you want to work on and you don't get much choice. On the other hand, you get security and stability in your pay and your benefits and all those things. You know, I've personally found for myself that I can't do consulting because I can't do the interfacing with customers. See, that's why I can't do full time either because I can't interface with,

you know, people who tell me what to do. So it's a lose, lose for me. This is my mentoring session. Oh, sorry. Okay, one more question back to what the show is supposed to be about. Do you think the singularity will happen before or after the quantum supremacy event?

Oh, I'll just say they're both more than 20 years away. Oh, good. That's fine. Do you have any thoughts you'd like to leave us with, Rick? Quantum computers are very impressive, but also really just a bunch of classical computers put together. Three classical computers in a trench coat.

With a tiny bit of physics. Our guest has been Rick Alther, also known as MXShift, which is like mischief, which is like M-X-S-H-I-F-T. Rick is also a senior staff software engineer at IonQ. Thanks, Rick. You're quite welcome. Thank you for having me. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listener Slack group for their questions.

And thank you for listening. You can always contact us at show at embedded.fm or at the contact link on the Embedded FM website, where there will be show notes that include a picture of Rick's golden circuit. And now a quote to leave you with. It's just been a Douglas Adam Hitchhiker's Guide to the Galaxy sort of day for me, so let's go with him describing what he's seen. The ships hung in the sky in much the same way that bricks don't.