Backend: Zurich Instruments
Introduction
quantify-scheduler provides a stateless module: zhinst_backend,
that abstracts the complexity of setting up experiments using Zurich Instruments hardware.
quantify-scheduler uses information on the quantum device
and instrument properties to compile a quantify_scheduler.schedules.schedule.Schedule into waveforms and sequencing instructions suitable for execution on Zurich Instruments hardware.
More information about compilation can be found in the User Guide.
Using existing programming interfaces provided via zhinst-qcodes and zhinst-toolkit, quantify-scheduler prepares the instruments that are present in the sec-hardware-description.
Finally, after configuring and running compile_backend()
successfully the instruments are prepared for execution.
The Zurich Instruments backend provides:
Synchronized execution of a program in a UHFQA and an HDAWG through the use of Triggers and Markers.
Automatic generation of the SeqC Sequencer instructions.
Waveform generation and modulation.
Memory-efficient Sequencing with the CommandTable.
Configuration of the relevant settings on all instruments.
Configuration for Triggers and Markers.
Supported Instruments
The Zurich Instruments backend currently supports the HDAWG and the UHFQA instruments. In addition to the Zurich Instruments devices, the hardware backend supports using microwave sources such as the R&S SGS100A.
Basic paradigm and inner workings
The Zurich Instruments back end threats a Schedule as a linear timeline of operations executed on the quantum device and translates this into pulses and acquisitions to be executed on the different input and output channels of an HDAWG and a UHFQA.
In this context a single HDAWG is treated as the master device that sends out a single marker pulse for synchronization at the start of each iteration of the schedule that is used to trigger all other devices.
After the synchronization trigger is given, all devices execute a compiled program for which the timings of all instructions have been calculated.
The compilation from operations at the quantum-device layer to instructions that the hardware can execute is done in several steps.
The zhinst compile_backend() starts from the ScheduleBase.timing_table and maps the operations to channels on the hardware using the information specified in the
sec-connectivity.
Corrections for channel latency, as well as moving operations around to ensure all measurements start at the first sample (0) of a clock cycle are also done at this stage.
Once the starting time and sample of each operation are known, the numerical waveforms that have to be uploaded to the hardware can be generated. The numerical waveforms differ from the idealized waveforms of the device description in that they include corrections for effects such as mixer-skewness and linear-dynamical distortions (not implemented yet), and intermediate frequency modulation if required.
Both the CompiledSchedule.hardware_timing_table and CompiledSchedule.hardware_waveform_dict are available as properties of the CompiledSchedule.
In the next step, the clock-accurate Seqc instructions for each awg of each device are determined, as well as the settings (nodes) to be configured including the linking of the numerical waveforms to these nodes.
All of this information is combined in ZISettingsBuilders and added to the compiled instructions of the CompiledSchedule.
Limitations
There are several limitations to the paradigm and to the current implementation. Some of these are relatively easy to address while others are more fundamental to the paradigm. Here we give an overview of the known limitations. Note that some of these can be quite specific.
Inherent limitations
There are some inherent limitations to the paradigm of describing the program as a single linear timeline that is started using a single synchronization trigger. These limitations cannot easily be addressed so should be taken into account when thinking about experiments.
Because the synchronization of the HDAWG and the UFHQA relies on a trigger on two devices operating at different clock frequencies one cannot guarantee at what sample within the clock domain the slave device gets triggered. The consequence is that although the triggering is stable within an experiment, the exact time difference (in the number of samples) between the different devices varies between different experiments. This problem is inherent to the triggering scheme and cannot be easily resolved.
The paradigm of a single fixed timeline with a single synchronizing trigger is not compatible with a control loop affecting feedback.
Limitations with the current implementation
There are also some practical limitations to the implementation. Keep these in mind when operating the hardware.
Real-time modulation is currently not supported, relying on pre-modulated waveforms, it is important to start waveforms at a multiple of the modulation frequency. Sticking to a 10 ns grid, it is recommended to use a modulation frequency of 100 MHz.
All operations need to start at an integer number of samples. Because of the choice of sampling rates of 2.4 GSps (~0.416 ns) and 1.8 GSps (~0.555 ns) it is useful to stick to a 10 ns grid for HDAWG (microwave and flux) pulses and a 40 ns grid for UHFQA (readout) pulses.
Different instructions on the same “awg” cannot start in the same clock cycle. This implies that the readout acquisition delay cannot be 0 (but it can be 40 ns or - 40ns).
All measurements are triggered simultaneously using the
StartQA(QA_INT_ALL, true)instruction. This implies it is not possible to read out only a specific qubit/channel.All measurements have to start at the same sample within a clock cycle because one can only define a single integration weight per channel. To guarantee this, all operations are shifted around a bit (the measurement fixpoint correction). As a consequence, the reset/initialization operation can sometimes be a bit longer than specified in the schedule.
Because the timing between two devices needs to align over longer schedules, it is important that the clock-rates are accurate. To ensure phase stability, use a 10 MHz shared reference and operate the hardware in external reference mode.
Only a single HDAWG supported as the primary device, other HDAWGs need to be configured as secondary devices.
Multiplexed readout is currently not supported. One can only read out a single channel. (#191)
Hardware compilation configuration
The zhinst_backend allows Zurich Instruments to be
configured individually or collectively by enabling master/slave configurations via
Triggers and Markers.
The compilation onto Zurich Instruments hardware is configured by the Hardware Compilation Config.
The configuration file contains parameters about the Instruments, their connectivity to the quantum device, and options used in mapping quantify_scheduler.operations.operation.Operations, which act on qubits, onto physical properties of the instruments.
To use the Zurich Instruments backend in compilation, one should pass a valid hardware compilation configuration to the quantum_device.hardware_config parameter, such that it can be used to generate a full CompilationConfig using quantum_device.generate_compilation_config(), which can finally be used to compile a Schedule using compile(). The entry "backend": "quantify_scheduler.backends.zhinst_backend.compile_backend" specifies to the scheduler that we are using the Zurich Instruments backend (specifically the compile_backend() function).
See the hardware verification tutorial for an example.
Example Zurich Instruments hardware compilation configuration file
{
"backend": "quantify_scheduler.backends.zhinst_backend.compile_backend",
"hardware_description": {
"ic_hdawg0": {
"hardware_type": "Zurich Instruments",
"instrument_type": "HDAWG8",
"ref": "int",
"clock_select": 0,
"channelgrouping": 0,
"channels": {
"0": {
"mode": "complex",
"markers": [
"AWG_MARKER1",
"AWG_MARKER2"
]
},
"1": {
"mode": "complex",
"markers": [
"AWG_MARKER1",
"AWG_MARKER2"
]
},
"2": {
"mode": "complex",
"markers": [
"AWG_MARKER1",
"AWG_MARKER2"
]
},
"3": {
"mode": "complex",
"markers": [
"AWG_MARKER1",
"AWG_MARKER2"
]
}
}
},
"ic_uhfqa0": {
"hardware_type": "Zurich Instruments",
"instrument_type": "UHFQA",
"ref": "ext",
"channels": {
"0": {
"mode": "real",
"trigger": 2
}
}
},
"mw_qubit_ch1": {
"hardware_type": "LocalOscillator",
"instrument_name": "mw_qubit",
"frequency_param": "ch1.frequency",
"power": 13
},
"mw_qubit_ch2": {
"hardware_type": "LocalOscillator",
"instrument_name": "mw_qubit",
"frequency_param": "ch2.frequency",
"power_param": "ch2.power",
"power": 10
},
"mw_readout": {
"hardware_type": "LocalOscillator",
"instrument_name": "mw_readout",
"frequency_param": "frequency",
"power": 16
}
},
"hardware_options": {
"latency_corrections": {
"q0:mw-q0.01": 95e-9,
"q1:mw-q1.01": 95e-9,
"q0:res-q0.ro": -95e-9,
"q1:res-q1.ro": -95e-9
},
"distortion_corrections": {
"q0:fl-cl0.baseband": {
"filter_func": "scipy.signal.lfilter",
"input_var_name": "x",
"kwargs": {
"b": [
0,
0.25,
0.5
],
"a": [
1
]
},
"clipping_values": [
-2.5,
2.5
]
}
},
"modulation_frequencies": {
"q0:mw-q0.01": {
"interm_freq": -1e8,
"lo_freq": null
},
"q0:res-q0.ro": {
"interm_freq": 2e8,
"lo_freq": null
},
"q1:mw-q1.01": {
"interm_freq": -1e8,
"lo_freq": null
},
"q2:mw-q2.01": {
"interm_freq": -1e8,
"lo_freq": null
},
"q3:mw-q3.01": {
"interm_freq": -1e8,
"lo_freq": null
}
},
"mixer_corrections": {
"q0:mw-q0.01": {
"amp_ratio": 0.95,
"phase_error": 0.07,
"dc_offset_i": -0.0542,
"dc_offset_q": -0.0328
},
"q1:mw-q1.01": {
"amp_ratio": 0.95,
"phase_error": 0.07,
"dc_offset_i": 0.042,
"dc_offset_q": 0.028
},
"q2:mw-q2.01": {
"amp_ratio": 0.95,
"phase_error": 0.07,
"dc_offset_i": 0.042,
"dc_offset_q": 0.028
},
"q3:mw-q3.01": {
"amp_ratio": 0.95,
"phase_error": 0.07,
"dc_offset_i": 0.042,
"dc_offset_q": 0.028
}
},
"power_scaling": {
"q0:mw-q0.01": {
"output_gain": [
1,
1
]
},
"q1:mw-q1.01": {
"output_gain": [
1,
1
]
},
"q2:mw-q2.01": {
"output_gain": [
1,
1
]
},
"q3:mw-q3.01": {
"output_gain": [
1,
1
]
}
}
},
"connectivity": {
"devices": [
{
"name": "ic_hdawg0",
"channel_0": {
"port": "q0:mw",
"clock": "q0.01",
"mode": "complex",
"local_oscillator": "mw_qubit_ch1"
},
"channel_1": {
"port": "q1:mw",
"clock": "q1.01",
"local_oscillator": "mw_qubit_ch2"
},
"channel_2": {
"port": "q2:mw",
"clock": "q2.01",
"local_oscillator": "mw_qubit_ch2"
},
"channel_3": {
"port": "q3:mw",
"clock": "q3.01",
"local_oscillator": "mw_qubit_ch2"
}
},
{
"name": "ic_uhfqa0",
"channel_0": {
"port": "q0:res",
"clock": "q0.ro",
"local_oscillator": "mw_readout"
}
}
]
}
}
Hardware Description
The Hardware Description describes the instruments that are used in the setup, along with some instrument-specific settings. The currently supported instruments are:
- class ZIHDAWG4Description(**data)[source]
Information needed to specify a HDAWG4 in the
CompilationConfig.- __init__(**data)
Create a new model by parsing and validating input data from keyword arguments.
Raises ValidationError if the input data cannot be parsed to form a valid model.
-
channelgrouping:
int[source] The HDAWG channelgrouping property impacting the amount of HDAWG channels per AWG that must be used.. (default = 0) corresponding to a single sequencer controlling a pair (2) awg outputs.
-
channels:
Dict[int,ZIChannelDescription][source] Description of the channels of this instrument.
-
clock_select:
int[source] The clock rate divisor which will be used to get the instruments clock rate from the lookup dictionary in quantify_scheduler.backends.zhinst_backend.DEVICE_CLOCK_RATES.
For information see zhinst User manuals, section /DEV…./AWGS/n/TIME Examples: base sampling rate (1.8 GHz) divided by 2^clock_select. (default = 0)
-
hardware_type:
Literal['Zurich Instruments'][source] The hardware type, used to select this datastructure when parsing a
CompilationConfig.
-
instrument_type:
Literal['HDAWG4'][source] The instrument type, used to select this datastructure when parsing a
CompilationConfig.
- class ZIHDAWG8Description(**data)[source]
Information needed to specify a HDAWG8 in the
CompilationConfig.- __init__(**data)
Create a new model by parsing and validating input data from keyword arguments.
Raises ValidationError if the input data cannot be parsed to form a valid model.
-
channelgrouping:
int[source] The HDAWG channelgrouping property impacting the amount of HDAWG channels per AWG that must be used.. (default = 0) corresponding to a single sequencer controlling a pair (2) awg outputs.
-
channels:
Dict[int,ZIChannelDescription][source] Description of the channels of this instrument.
-
clock_select:
int[source] The clock rate divisor which will be used to get the instruments clock rate from the lookup dictionary in quantify_scheduler.backends.zhinst_backend.DEVICE_CLOCK_RATES.
For information see zhinst User manuals, section /DEV…./AWGS/n/TIME Examples: base sampling rate (1.8 GHz) divided by 2^clock_select. (default = 0)
-
hardware_type:
Literal['Zurich Instruments'][source] The hardware type, used to select this datastructure when parsing a
CompilationConfig.
-
instrument_type:
Literal['HDAWG8'][source] The instrument type, used to select this datastructure when parsing a
CompilationConfig.
- class ZIUHFQADescription(**data)[source]
Information needed to specify a UHFQA in the
CompilationConfig.- __init__(**data)
Create a new model by parsing and validating input data from keyword arguments.
Raises ValidationError if the input data cannot be parsed to form a valid model.
-
channels:
Dict[int,ZIChannelDescription][source] Description of the channels of this instrument.
-
hardware_type:
Literal['Zurich Instruments'][source] The hardware type, used to select this datastructure when parsing a
CompilationConfig.
-
instrument_type:
Literal['UHFQA'][source] The instrument type, used to select this datastructure when parsing a
CompilationConfig.
Warning
In order for the backend to find the QCodes Instrument it is required that the keys of the
HardwareDescription map 1-to-1 to the names given to the QCodes Instrument during instantiation, with an ic prepend.
Example: If the hdawg QCodes Instrument name is “hdawg_dev8831” then the
Device’snameis “ic_hdawg_dev8831”
The channels of these instruments are described by
- class ZIChannelDescription(**data)[source]
Information needed to specify a ZI Channel in the
CompilationConfig.A single ‘channel’ represents a complex output, consisting of two physical I/O channels on the Instrument.
- __init__(**data)
Create a new model by parsing and validating input data from keyword arguments.
Raises ValidationError if the input data cannot be parsed to form a valid model.
Local oscillators can also be included by using the following generic datastructure.
- class LocalOscillatorDescription(**data)[source]
Information needed to specify a Local Oscillator in the
CompilationConfig.-
generic_icc_name:
Optional[str][source] The name of the
GenericInstrumentCoordinatorComponentcorresponding to this Local Oscillator.
-
hardware_type:
Literal['LocalOscillator'][source] The field discriminator for this HardwareDescription datastructure.
-
generic_icc_name:
Connectivity
The Connectivity describes how the inputs/outputs of the Zurich Instruments devices are connected to ports on the QuantumDevice.
Note
The Connectivity datastructure is currently under development. Information on the connectivity between port-clock combinations on the quantum device and ports on the control hardware is currently included in the old-style hardware configuration file, which should be included in the "connectivity" field of the HardwareCompilationConfig.
Hardware Options
The Hardware Options provide a way of specifying some specific settings used in compiling instructions for the Zurich Instruments hardware.
Note
In the Zurich Instruments backend, a LatencyCorrection is implemented by incrementing the abs_time of all operations applied to the port-clock combination.