QUANTUM
ORCHESTRATION PLATFORM

The Quantum Orchestration Platform is a whole new paradigm for quantum control and is fundamentally different from general-purpose test equipment like AWGs, lock-ins, digitizers, etc. The main differences are:

1. The span of quantum experiments & algorithms which can be run out-of-the-box
2. The pace of the research and development
3. The level of adequacy of the specific specs & capabilities required for quantum research & development (e.g like latency, run-time, etc)

1) The span of quantum experiments & algorithms which can be run out-of-the-box

We like to think of the span of experiments & algorithms which a system can run as the subspace of the experimental phase-space that it covers. While AWGs, Lock-ins, digitizers cover specific points or small regions in this phase space, the quantum orchestration platform covers it entirely. In other words, each general-purpose test tool, even if it is re-branded as a quantum controller, has a fixed set of allowable functions. The Quantum Orchestration Platform (QOP)  however, is a full-stack system allowing you to easily and quickly run even your dream experiments and real-time sequences out-of-the-box, from a high-level programming language, QUA. In most cases, each test and measure tool can be expressed and implemented as a single QUA program that can run on the QOP. Alternatively, each such instrument can be described by omitting a different subspace of the full QOP’s phase-space.

2) The pace of the research and development

Every once in a while you have a new brilliant idea for an experiment. While these ideas are more groundbreaking, they are also more challenging and end up being outside the scope of your general-purpose test equipment (its subspace). Once this happens, you have 3 choices:

1. Repurpose your general-purpose. It appears that in all labs such repurposing draws an incredible amount of time and resources, which comes at the expense of the physics and science to be explored. Whether it’s FPGA programming, coding libraries, dealing with drivers, or synchronizing different modules, labs spend years of work on repurposing general-purpose AWGs, Lock-ins, and digitizers for quantum control. It’s often required even for the simplest Ramsey and spectroscopy, and it’s always a must when it comes to multi-axes tomography, the 2-qubit RB sequence, and all the way to multi-qubit quantum-error-correction. We’ve met students who themselves spent months and years doing so. We actually did it ourselves!
2. Give up your brilliant idea and introduce a new constraint for your ideas’ phase-space. It must comply with the experimental phase-space covered by your existing control system.
3. Get an OPX! We firmly believe that scientific progress relies on ideas, but also on the capabilities of the tools we use. Even our ideas in many cases stem from what we define as technically possible. Our goal at QM is to let you imagine any experiment, the most groundbreaking research, and the most sought-for flagship papers, and always know: yes, of course, it can run. Right out of the box!

In experimental physics, there are many bottlenecks. Long fabrication processes, mirrors alignment (and re-alignment!), helium leakages, vacuum-chamber baking, lead times of crucial equipment, and last but not least: in-house development of quantum control capabilities. Specifically, in quantum computing, the control layer can either be an enabler to progress rapidly and run even the most complex experiments seamlessly or be one of the leading bottlenecks in the lab. Our mission is to allow all teams to run even the wildest experiments of their dreams seamlessly and push the boundaries of the physics they can explore to a whole new level. 

3) The level of adequacy for the specific specs & capabilities required for quantum research & development

The general-purpose equipment available today was not built for quantum. In the best-case scenario, it was rebranded. AWGs, lock-ins, and digitizers are used for communication systems, lidars, medical device research, and the list goes on. Of course, we don’t mind non-quantum-experimentalists using the same machines, but this has several consequences. First,  these machines are limited in the feature-set they provide. They are also misaligned with the requirements of quantum computing by not supplying you with the critical features you require. And finally, they equip you with quite a few features you simply don’t need (that you’re still paying for). The QOP full-stack quantum control hardware and software and all of its features was created by quantum physicists for quantum physicists, with your experimental needs in mind. 

The Quantum Orchestration Platform is a whole new paradigm for quantum control and is fundamentally different from general-purpose test equipment like AWGs, lock-ins, digitizers, etc. The main differences are:

1. The span of quantum experiments & algorithms which can be run out-of-the-box
2. The pace of the research and development
3. The level of adequacy of the specific specs & capabilities required for quantum research & development (e.g like latency, run-time, etc)

1) The span of quantum experiments & algorithms which can be run out-of-the-box

We like to think of the span of experiments & algorithms which a system can run as the subspace of the experimental phase-space that it covers. While AWGs, Lock-ins, digitizers cover specific points or small regions in this phase space, the quantum orchestration platform covers it entirely. In other words, each general-purpose test tool, even if it is re-branded as a quantum controller, has a fixed set of allowable functions. The Quantum Orchestration Platform (QOP)  however, is a full-stack system allowing you to easily and quickly run even your dream experiments and real-time sequences out-of-the-box, from a high-level programming language, QUA. In most cases, each test and measure tool can be expressed and implemented as a single QUA program that can run on the QOP. Alternatively, each such instrument can be described by omitting a different subspace of the full QOP’s phase-space.

2) The pace of the research and development

Every once in a while you have a new brilliant idea for an experiment. While these ideas are more groundbreaking, they are also more challenging and end up being outside the scope of your general-purpose test equipment (its subspace). Once this happens, you have 3 choices:

1. Repurpose your general-purpose. It appears that in all labs such repurposing draws an incredible amount of time and resources, which comes at the expense of the physics and science to be explored. Whether it’s FPGA programming, coding libraries, dealing with drivers, or synchronizing different modules, labs spend years of work on repurposing general-purpose AWGs, Lock-ins, and digitizers for quantum control. It’s often required even for the simplest Ramsey and spectroscopy, and it’s always a must when it comes to multi-axes tomography, the 2-qubit RB sequence, and all the way to multi-qubit quantum-error-correction. We’ve met students who themselves spent months and years doing so. We actually did it ourselves!
2. Give up your brilliant idea and introduce a new constraint for your ideas’ phase-space. It must comply with the experimental phase-space covered by your existing control system.
3. Get an OPX! We firmly believe that scientific progress relies on ideas, but also on the capabilities of the tools we use. Even our ideas in many cases stem from what we define as technically possible. Our goal at QM is to let you imagine any experiment, the most groundbreaking research, and the most sought-for flagship papers, and always know: yes, of course, it can run. Right out of the box!

In experimental physics, there are many bottlenecks. Long fabrication processes, mirrors alignment (and re-alignment!), helium leakages, vacuum-chamber baking, lead times of crucial equipment, and last but not least: in-house development of quantum control capabilities. Specifically, in quantum computing, the control layer can either be an enabler to progress rapidly and run even the most complex experiments seamlessly or be one of the leading bottlenecks in the lab. Our mission is to allow all teams to run even the wildest experiments of their dreams seamlessly and push the boundaries of the physics they can explore to a whole new level. 

3) The level of adequacy for the specific specs & capabilities required for quantum research & development

The general-purpose equipment available today was not built for quantum. In the best-case scenario, it was rebranded. AWGs, lock-ins, and digitizers are used for communication systems, lidars, medical device research, and the list goes on. Of course, we don’t mind non-quantum-experimentalists using the same machines, but this has several consequences. First,  these machines are limited in the feature-set they provide. They are also misaligned with the requirements of quantum computing by not supplying you with the critical features you require. And finally, they equip you with quite a few features you simply don’t need (that you’re still paying for). The QOP full-stack quantum control hardware and software and all of its features was created by quantum physicists for quantum physicists, with your experimental needs in mind. 

Well, there’s the long and the short of it. So let’s start with the short:

Why: Because we’ve built it to operate as quickly, efficiently, and easily with the Pulse Processor, giving you an adaptive, intuitive, and fully controllable way to probe your qubits. 

How: Honestly, very easily!

Now, let’s get into the heart of the matter:

As physicists, we understand the pain of having to learn yet another programming language, but writing FPGA and low-level code every time you want to run a Ramsey measurement? That’s a worse kind of pain. How many lines of code do you need to painstakingly write in order to run the experiments of your dreams? Probably more than you care to admit. This is where QUA comes in. QUA is a pulse-level quantum coding language that allows quantum researchers to run any experiment, on any type of qubits, quickly and easily. That Ramsey pulse, for instance, can be written, sent, and measured in just 10 lines of QUA code. But more on that in a minute.

When designing QUA, we set out to find the easiest way to program our pulses and send them to the qubit. We wanted to create a direct line of communication with our FPGA-based Pulse Processor in the OPX, allowing us to have complete control of everything we might want. This quantum language was built by quantum physicists for quantum physicists, all with the purpose of making your quantum experiments as seamless as can be.

You write QUA the way you would explain it to other physicists in your group. You play this pulse to that element, listen on this measurement channel, demodulate that result. 

As for how the language actually works, there are three main steps: define a pulse sequence, play that pulse sequence, and measure the readout of that pulse sequence.  

The piece-de-resistance is that the compiler does all of the hard work: translating the pulses to FPGA commands. In other words, you need to program only on the high-level pulse programming language QUA, which is translated into the low-level FPGA. Programming in such a way is very useful; imagine you want to generate parametric Gaussian wavefunctions. With an AWG, you would need to upload a bunch of Gaussian profiles and figure out the timing in between. With QUA, you can set a for loop, which loops over various Gaussian amplitudes, sequentially. Turning your experiment into instructions that the FPGA can understand and run is already taken care of.

Feel free to check out this link to a blog about QUA and the OPX. Additionally, feel free to reach out to us if you would like any more insight or information on how we can help you perform your experiments.

Easily! Analog feedback is a powerful tool for quantum experiments. Potential applications include correcting a drifting magnetic flux bias in real-time to stabilize a qubit frequency, tuning a pulse’s frequency in real-time to stay resonant with (or detuned by a constant amount from) a dynamically changing transition, or reversing partial wavefunction collapse induced by a weak quantum measurement.

Implementing analog feedback with the OPX is straightforward, and is accomplished with the following code snippet inserted in a QUA program:

for n in range(0, 20):
        measure(“Readout”, ”Qubit”, None, demod.full(“cos”, I), demod.full(“sin”, Q))
        a = FeedbackAmplitude(I,Q)
        play(“Pulse”*amp(a), “Qubit”)

The program outputs a measurement pulse “Readout” to the “Qubit” element and demodulates the transmitted signal to produce the I and Q quadratures. A variable a is calculated from these quantities through an arbitrary user-defined function FeedbackAmplitude(I,Q), which then sets the amplitude of the feedback signal. This control sequence runs continuously, as we can see with the following figure produced by our hardware simulator:

The upper plot shows the quadratures output by the OPX for the continuous measurement signal, which after transmission through the sample is demodulated for measurement at 100 ns slices (a parameter set by the user). A real-time calculation then produces a correction to the pulse amplitude.

Correcting the pulse frequency is just as easy with the update_frequency() command:

for n in range(0, 20):
        measure(“Readout”, ”Qubit”, None, demod.full(“cos”, I), demod.full(“sin”, Q))
        f = FeedbackFrequency(I,Q)
       update_frequency(f, “Qubit”)

With this program the OPX outputs the following:

The OPX uses memory in a completely different way from your garden-variety AWG, and we should first understand how so as not to compare apples to oranges.

Consider how you would play a Ramsey sequence from an AWG with a 1 GSPS sampling rate. This involves uploading a waveform long enough to contain the two excitation pulses as well as the delay in between. If each pulse is 20 ns long, and the delay between them is 1000 ns, then at a sampling rate of 1 GSPS this waveform would consist of 1040 samples.

The OPX pulse processor operates in a completely different manner. Firstly, only the pulse amplitude is stored in the memory; upconversion to the intermediate frequency happens in real time. A pulse of constant amplitude and arbitrary length is thus generated from a single sample!

For the Ramsey sequence we might want the 20 ns pulse to have a Gaussian envelope, and accordingly use 20 samples of waveform memory. The QUA program to run a Ramsey sequence would look like this:

play(“Gaussian”,”Qubit”)
wait(t_delay)
play(“Gaussian”,”Qubit”)

The OPX uses the same waveform memory to play the Gaussian twice, and can just as easily play it a thousand times — with the same 20 samples! In fact, it can dynamically change the Gaussian amplitude, or stretch the Gaussian for a pulse duration longer than 20 ns — whether pre-programmed or in a real-time response to measurement — without using additional memory.

What about the wait(t_delay) command? An AWG requires a long sequence of zeros to space the pulses, and since characterization of high-coherence devices require long delay times, memory limitations can be prohibitive. But in the OPX the wait() command does not use any waveform memory!

A full Ramsey experiment, including a measurement operation followed by a wait() command to allow the qubit to return to the ground state, would look like this:

with for_each_(t_delay, t_values):
        play(“Gaussian”,”Qubit”)
        wait(t_delay)
        play(“Gaussian”,”Qubit”)
        measure(“Readout”,”Qubit”,...)
        wait(reset)

The array t_values over which we are looping for t_delay can contain a million values, and the variables t_delay and reset can have values of seconds — and the entire experiment will still exploit the same 20 samples of waveform memory.

Now that we understand how powerfully and intelligently the OPX utilizes its memory, we can give a short answer: Each OPX channel has a waveform memory of 2^16 = 65,536 samples. This sounds small for an AWG, but is huge for a pulse processor!

As physicists, we always like to ask the more fundamental questions, even when at first glance they seem trivial. In order to answer “what is the pulse processor,” it is useful to first answer the trivial question “what is a quantum experiment?”This is because the pulse processor was architected from the ground-up to run even the most complex quantum experiments one could think of. Now, let’s break-down a quantum experiment to four main components:

1. Gates – The different terms in the Hamiltonian which cause the sought time-evolution. These gates are usually performed by directing well-crafted pulses (laser, microwave) to the qubits.
2. Measurements – Since you’re a classical being, at some point, you will have to collapse the system so you can “see it for yourself”. The measurements are performed in various ways – ADCs, SPCMs, PDs, cameras, etc.
3. Classical processing – There is no quantum processing without classical processing. Whether it’s demodulation, integration, time-tagging, TTL, counting, state estimations, error-estimations, Bayesian estimations, or even arithmetics as simple as \tau=\tau+5 when looping over the time difference in a Ramsey sequence. There is not a single quantum protocol that does not require classical processing.
4. Control flow – the good-old if/else, while, for, cases, etc. From the simplest averaging loop and parameter-sweep loop, through active-reset and to multi-qubit error correction employing a multitude of nested if/else’s. Control-flow is indispensable for quantum protocols.
   

Every quantum experiment (or protocol) is a combination of these four elements. Every quantum protocol is an entangled sequence of gates, measurements, and classical processing, all combined in various ways and wrapped with various control-flow statements. And someone has to orchestrate all that!

The Pulse Processor is a processor architected to run sequences that combine all the above in real-time, in a perfectly synchronized and orchestrated way. That includes:

1. Waveform generation in a fully parametric manner. Namely, the pulse processor does not need you to load all the pulses in advance, but rather it generates them in real-time as defined by the program. In other words, the pulse processor directly processes pulses as opposed to simply shoving them into memory.
2. Waveform acquisition including the acquisition of both analog data (through ADCs) and digital data (from SPCMs, PDs, camera, etc). Including continuous acquisition for CW measurements or qubit-tracking (and weak measurements) as well as pulsed acquisition in synchronization with the waveform generation and real-time processing. 
3. Real-time processing including real-time processing of acquired data (e.g weighted demodulators and integrations, image-processing, TTL counting, time-tagging, etc), state-estimations, and even neural networks.
4. Control flow including everything you typically do in MATLAB/python, now running in real-time, at time scales that are faster than your qubits (10s of nanoseconds)! Nested loops, complex branching trees with countless if/else’s, to form the most complex protocol you may have in mind.

And above all, these four elements are NOT to be regarded as independent. Quantum protocols are an interacting system, where waveform generation leads to waveform acquisition, followed by classical processing which then affects the following generated pulses. And many such threads running in parallel, and affecting each other as well.

To enable such performance, the pulse processor is built in a multi-core architecture containing several pulsers. Each pulser is an independent real-time core capable of driving one or more quantum elements (qubits, collective modes, two-/multi-level transitions, resonators, etc.). Every pulser is essentially a specialized processing unit that may simultaneously handle both waveform generation, waveform acquisition, and all the real-time calculations (classical processing) required (it is Turing complete!) in a deterministic manner and with ultra-low latency.

The pulse-processor orchestrates all the waveform generation, waveform acquisition, classical processing, and control flow in real-time. But what is its API? 

The API for the pulse processor is QUA: a powerful yet intuitive quantum programming language. In QUA you can formulate any protocol/experiment – from spectroscopy to quantum-error-correction. Once the program is formulated it is compiled by the XQP compiler to the assembly language of the pulse processor. Next, the program, now formulated in the pulse processor’s assembly language, is sent to the pulse processor which runs it in real-time.

Using the intuitive QUA language and our compiler, you can now directly and intuitively code complex sequences from a high-level programming language, including real-time feedback, classical calculations (Turing-complete), comprehensive control flow, etc. 

Not at all! The QOP calculates the waveform on the fly, only the minimum necessary part of it is kept in the memory but most of it is calculated on the fly by the pulse processor. This greatly reduces memory needs. Memory is used exclusively for the definition of the baseband.

The Quantum Orchestration Platform is not an Arbitrary Waveform Generator+digitizers combo, but a whole new paradigm for the control of quantum processors. The OPX is a custom pulse processor with a real-time programming language that allows describing those pulses. There is nothing arbitrary about quantum protocols. If you think of a Ramsey measurement or a power-rabi, for example, it would take you no more than 2-5 sentences to describe them to a physicist. Therefore, you require a processor that can run quantum sequences (from the simple Ramsey to Quantum Error Correction), and not an arbitrary-waveform-generator.

The Quantum Orchestration Platform allows you to formulate even the most complex quantum experiments in a natural and compact manner, proportional to the amount of information in the sequence, not the number of points in the total played waveforms. QM’s quantum control hardware was tailor-made to be able to run such complex protocols.

The Quantum Orchestration Platform (QOP) normally replaces most AWGs and acquisition systems in the lab, but can still interface with other instruments via the use of external triggers that can be sent and received to and from other equipment in the lab. In the future, it will also be possible to interface via USB and other interfaces.