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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.