Practical Active Qubit Reset

March 5, 2021 by Andrea Corna

When working with qubits, it’s essential to have a reliable state preparation. The easiest method for superconducting qubits is to passively wait for the qubit to decay into its ground state, but it’s slow and has poor fidelity. Active qubit reset decreases considerably the initialization time, while greatly increasing the fidelity of the prepared state.

Differently from many quantum algorithms, active qubit reset requires to perform a measurement of the qubit state and then take an action depending on that. This requires strict coordination between the instrument devoted to the readout and the one that performs the control; this can be easily achieved using the Zurich Instruments Programmable Quantum System Controller (PQSC). Let’s discover how!

Concept

The goal of initialization is to prepare the qubit in a known state, such as that all the subsequent operations are performed from a known starting point. At the beginning, the qubit is in a random state. First, we have to perform a projective measurement of the qubit. After that, the qubit will be in one of its two eigenstates, either |0⟩ or |1⟩. If we measure our target state, we can continue with the algorithm. Otherwise, we will apply a pi pulse to correct it and we can continue like in the first case. The eventual correction should happen as quickly as possible, otherwise the qubit could change its state, decreasing the initialization fidelity. Therefore, the latency is a key parameter in such scheme.

Active qubit reset sequence

Figure 1: A typical sequence of active qubit reset.

Experimental Setup

For the readout, we use the UHFQA. This instrument can generate the probe pulses and acquire the readout signal; it can process the digitized signals and determine the qubit state with very low latency. So, it’s very well suited for such application. You can read more on how to use it in this blog post. The qubit state is sent over a fast digital interface, called DIO.

Alternatively, the SHFQA can be used for the readout. Its main advantages are the large number of qubits that it can readout and the integrated microwave conversion to reach the high frequency of the typical readout resonators of superconducting qubits.

The qubit states (results) are then sent to the PQSC. In this case it will act like a low latency router: the results are dispatched as-is to other instruments for further action.

To perform the eventual required pi-pulse, we send them to one or two HDAWG, coupled to an HDIQ to generate the required signal. Another HDAWG could be used to generate flux pulses when required later in the algorithm.

Experimental setup

Figure 2: The experimental setup for active qubit reset, with low latency links in orange.

The PQSC has two roles:

  1. Synchronize the instruments such as that they work with the same clock and from the same time reference.
  2. Collect the qubit readout states and distribute them to the instruments that need them with minimal latency.

To perform such duties, the PQSC has 18 ZSync ports. ZSync is a proprietary protocol designed to connect the PQSC to the other instruments in the Quantum Computing Control System. ZSync provides a 100 MHz clock and bi-directional full fast digital lines.

Here is a diagram of the internal data processing. Starting from the left we have the results incoming from the UHFQAs or SHFQAs. As first step, they are temporary stored in the Readout Register Bank. This is a memory block that can hold results during the experiment. While for simple active qubit having such memory is not strictly needed, it’s useful for more complex algorithms where the decisions to be taken depend not only on the last results, but also on the previous ones. For such cases, the programmable decoder unit will take the readout register bank as input when a new result arrives. In our case, they will instead travel to the output block. Here, a small subset of the bank is selected by the Register Selection and forwarded to an instrument. This selection is per-ZSync port, so each instrument will receive its register subset.

The PQSC feedback internal flow diagram

Figure 3: The PQSC's feedback internal flow diagram.

The PQSC also generate programmable start triggers, in order to synchronize all the devices ahead of the execution of the algorithms. Such triggers are synchronous to the system clock, so the start time is well aligned with the clock and the phases of the eventual microwave generators in the system. The user can configure the number of triggers and the period between them; the PQSC will take care of generating them in a synchronous way.

Workflow

Let’s now analyze how we can practically implement this experiment.

Synchronization and start triggers

Before execution, the instruments need to be configured to accept the clock and the start triggers from the PQSC. On the HDAWG and the SHFQA this is done by selecting the appropriate clock source and mode. The UHFQA doesn’t have a direct ZSync connection to the PQSC and it uses an HDAWG as bridge over the DIO interface. This interface needs to be configured as well, please refer to the attached script for more details.

The start triggers are configured by the repetitions and the holdoff time. Once the triggers are generated, they reach all the connected instruments at the same time. Each sequence, on every instrument to synchronize, need to have a waitZSyncTrigger command at the beginning. After that, all the subsequent instructions are executed in sync on the clock cycle.

Triggering the readout

On the SHFQA, after catching the start trigger, the readout can be initiated by the startQA command:

//Play probe signal for Channel0, Trigger the readout on Channel0,
//activate the monitor and send results to register 1
startQA(QA_GEN_0, QA_INT_0, true, 1);

This command will generate the probe signal for the first integration channel and will acquire the result. The qubit state is then immediately sent to the PQSC and stored in the result register number 1 in the first bit position. Only this bit gets updated and the eventual other result are kept intact.

The UHFQA is very similar, except that the waveform generation and trigger of data acquisition are done separately:

playWave(1,w_I, 2, w_Q)           //Play probe signal
startQA(QA_INT_0, true, 1);       //Trigger the readout on Channel0,
                                  //activate the monitor and send
                                  //results to register 1

The waveforms, the integration coefficients need to be configured before execution as shown in the script.

Feedback forwarding

After the startQA command, the results will reach the PQSC, which automatically will send them to the configured HDAWG for the feedback action.

Feedback action

The feedback data will be signalled by another ZSync trigger, which the HDAWG needs to listen to, in the same way as the start trigger. Then it can retrieve the feedback data and play a waveform depending on it. The sequence will look like this:

waitZSyncTrigger();                         //Wait for feedback data
playWaveZSync(ZSYNC_DATA_PQSC_REGISTER);    //Play a waveform depending on feedback data

The instruction playWaveZSync does all the data processing and conditional waveform playback. The ZSYNC_DATA_PQSC_REGISTER argument specify that we are interested to the data coming from the register forwarding of the last received ZSync message. The data is then shifted and masked, according to parameters specified ahead of execution, to extract the interesting bit(s). Finally, such value is passed to the command table for waveform playback. In our case, we are interested in the first bit from the register forwarding, so the shift will be 0 and the mask 1.

The command table is a list of commands that can be executed depending on the value of a variable, in this case feedback. It can be programmed as a JSON table. For this case, it will look like this:

EntryWaveformAmplitude0Amplitude1Phase0Phase1
indexzeros?lengthvalueincrement?valueincrement?valueincrement?valueincrement?
0 True1024        
10False10241.0False1.0False90.0False0.0False

In the case the qubit is zero, a waveform of zeros is played. Otherwise, for a qubit state of one, a specific waveform that represent a pi pulse is played. The pulse can be modulated, and its parameters can be parametrized in real-time.

As alternative to playWaveZSync, we can instead acquire the processed ZSync message in the sequencer and pass it to command table, as follow

var feedback = getZSyncData(ZSYNC_DATA_PQSC_REGISTER);   //Get feedback data
executeTableEntry(feedback);                             //Play a waveform depending on feedback data

However, the latency will be slightly higher, due to the additional passage in the sequencer.

Results

This scheme as shown here is only for one qubit, but it can be replicated as-is to reset several qubits at the same time. As example, in the attached example, we implemented frequency multiplexed readout for two qubits. The two bits of results are sent to the PQSC, which will dispatch each bit to two HDAWG, each one controlling one of these qubits. The simulated readout sequence (similar to the demonstration shown here) cycles over all the possible combinations. The HDAWGs quickly generated the feedback pulses, in this case either a pulse or a pulse at half amplitude for clarity. The feedback latency last-sample-in to first-sample-out is around 700 ns.

Simulated readout signals with feedback

Figure 4: Simulated feedback for all the combinations of two qubits state. In blue and orange, the simulated resonator response. In green and red, the feedback pulses. For clarity, a pulse at full and half amplitude are generated instead of a pi-pulse or absence of it. In yellow the feedback latency. The red signal is slightly distorted due to a high-pass filter.

Conclusion

The PQSC offers a practical way to perform low-latency feedback. Active qubit reset is possible on a large system, not limited to the boundaries of the single instrument. To test this yourself, take a look at the script and get in touch if you have questions.

Update in March 2022: The post and associated code were updated to support the changes in LabOne 22.02.