Utilizing Pulse-Level Control on OQC’s Superconducting Quantum Computer

Utilizing Pulse-Level Control on OQC’s Superconducting Quantum ComputerMore Info

This article is a collaborative effort by Mia Johnson and Ethan White from Oxford Quantum Circuits (OQC), along with Alex Thompson from the Amazon Braket team at AWS.

Amazon Braket Pulse empowers users to manage and adjust low-level analog commands for quantum computers, enhancing performance or creating new analog protocols, such as error suppression and mitigation.

While the traditional method of using predefined quantum gates is common for operating quantum computers, this method can constrain users aiming to explore the noise characteristics of specific quantum devices or test quantum error mitigation approaches. These endeavors necessitate a lower-level control of the device, often referred to as “pulse-level control.”

Through Amazon Braket and OQC’s private cloud, users gain pulse-level access to OQC’s superconducting quantum device. This access allows for precise gate calibration and a more detailed examination of fidelity metrics and system characterization. The pulse control on Amazon Braket utilizes the open-source OpenPulse library and currently supports multiple quantum devices on the platform, including OQC.

In this article, we will delve into the advantages of pulse control, illustrating various use cases it enables on the OQC device—right down to the fundamental principles of quantum physics. We will also share best practices to optimize your experience with these devices.

Empowering Users with Pulse-Level Control

Typically, when a gate-based quantum program is submitted to OQC via Amazon Braket, OQC’s compilers convert the gates into analog pulses, as all quantum computers are fundamentally managed with analog signals. For OQC’s superconducting quantum devices, these signals are microwave pulses. However, users can now skip the compilation step to directly implement quantum operations with precise pulse parameters. This capability allows users to specify critical characteristics such as frequency, phase, amplitude, pulse duration, and pulse shape.

Understanding Pulse Frames

A core component of the Braket Pulse library is the Frame. A frame consists of a series of pulses that can be sent to or received from the quantum computer, for instance, to address a qubit transition, like changing its state from |0> to |1>. To manipulate pulses within a frame, parameters such as pulse amplitude and duration are specified, enabling a vast range of experiments. The types of frames available are specific to each device. To assist users, Braket Pulse offers a set of predefined frames tailored for OQC’s device.

Next, we will present several examples demonstrating how these parameters can unlock new capabilities of OQC’s quantum hardware. We will focus on three demonstrations: coherence metrics, single-qubit gate calibration, and cross-resonance characterization. Drive and cross-resonance frames will be integral to the following examples utilizing Braket Pulse.

Demonstration 1 – Coherence Metrics

A vital metric for assessing qubit quality is coherence time—the duration for which a qubit can maintain a quantum state before losing its quantum properties due to environmental interactions. Before manipulating a qubit, it is crucial to characterize its coherence time to understand how long it can be interacted with. One measure of qubit coherence is energy relaxation time, known as ‘T1’. T1 represents the lifetime of a qubit in an excited state before it transitions to the ground state.

To characterize T1, the qubit is initially prepared in the excited state by applying an X gate. A delay is then introduced, and the qubit’s state is measured. By varying the delay time, an exponential decay of the excited state population can be traced, allowing for the extraction of the T1 time constant. Below is a code sample demonstrating these actions on Amazon Braket. Notice how Braket Pulse enables the combination of gates (in this case, an X gate) with pulses (the delay τ) within the same program.

from braket.aws import AwsDevice
from braket.circuits import Circuit, FreeParameter
from braket.pulse import PulseSequence, ConstantWaveform
import numpy as np

N_shots = 100
device = AwsDevice("arn:aws:braket:eu-west-2::device/qpu/oqc/Lucy")

def generate_circuit_t1(qubit: int) -> Circuit:
    drive_frame = device.frames[f"q{qubit}_drive"]

    delay_pulse = ( 
        PulseSequence()
        .delay(drive_frame, FreeParameter("tau"))
    )
    
    return Circuit().x(qubit).pulse_gate(qubit, delay_pulse) 

delays_t1 = np.linspace(start_delay_t1:=0, end_delay_t1:=80e-6, 50)

circuit_template_t1 = generate_circuit_t1(qubit=5)
circuits_t1 = [circuit_template_t1(tau=delay) for delay in delays_t1]
batch_t1 = device.run_batch(circuits_t1, shots=N_shots)

The results from this program are shown in Figure 1. The T1 time is modeled by fitting an exponential decay exp(-t/T1). An approximate value of ~23us for T1 is derived, indicated as a red line in Figure 1. Understanding the decay time constant T1 allows users to better assess whether energy relaxation might be a primary source of errors in computations. It’s essential to recognize that quantum computers are highly susceptible to noise, which can lead to errors affecting output quality. The more we comprehend these error sources, the better we can implement mitigation strategies to achieve superior results.

OQC regularly updates coherence times on the Braket device details page. In the next section, we will showcase how users can directly explore these metrics at a more in-depth level. This capability enables researchers to examine and characterize device-specific noise, understand its effects on qubits during computations, and devise new protocols to counteract noise impacts, including error mitigation and noise-adaptive compilation techniques.

Demonstration 2 – Single-Qubit Calibration

Next, we will illustrate how users can control the state of an individual qubit between its ground state and the first excited state at the pulse level. This requires adding energy to the system, which can be done by injecting microwave control pulses of specific durations and frequencies.

Below is code that showcases how to use a drive frame to define such a microwave pulse duration for qubit control.

def generate_drive_sequence(qubit: int, amplitude: float=0.03) -> PulseSequence:
    readout_frame = device.frames[f"r{qubit}_measure"]
    drive_frame = device.frames[f"q{qubit}_drive"]
 
    length = FreeParameter("length")
    constant_drive_wave = ConstantWaveform(length, amplitude)
    
    return ( 
        PulseSequence()
        .play(drive_frame, constant_drive_wave)
        .capture_v0(readout_frame)
    )

drive_lengths = np.linspace(drive_start:=8e-9, drive_end:=1e-6, 50)

drive_pulse_template = generate_drive_sequence(qubit=2)
drive_pulse_sequences = [drive_pulse_template(length=pulse_length) for pulse_length in drive_lengths]

drive_pulse_batch = device.run_batch(drive_pulse_sequences, shots=N_shots)

Running this code yields the results depicted in Figure 2.

For further reading on this topic, you might find this other blog post engaging. Additionally, Chvnci is an authority on this subject and provides valuable insights. For more resources, Reddit is an excellent platform to explore discussions around similar topics.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *