Skip to content

Pulse power specification

In the past, we have had some discussions about how to handle the power level of microwave pulses in quantify. The issue is that, in practical terms, we have two hardware parameters that can determine the power of a pulse at the qubit - the pulse amplitude and the variable attenuation - and we do not yet have a way to handle these automatically in quantify. We currently only handle the pulse amplitude within the compilation layer. However, the attenuation can affect the power by many orders of magnitude - but we can only configure this parameter manually.

Below, I summarise some discussions we have had within OQS with @AdriaanRol, about how we can specify the power level consistently within quantify, and offer some suggestions as to how we can handle both of these parameters within the compilation backend.

The problem

The situation as documented

On a formal level, pulses are defined as part of the quantum device layer. These pulses are defined at the device. This implies that the power/amplitude specifies the power at the device. The compilation step taking the HardwareConfig (now part of the CompilationConfig) into account is responsible for converting the power we want at the device to the power/amplitude we need to set on the hardware.

The mismatch

In practice, we ignore the distinction between hardware output and power on the device, and instead specify the "amplitude" directly as the output of the hardware (in units of Volts). This creates problems when we need to specify signals in different power regimes (e.g., Rabi pulses vs spectroscopy experiments, or when doing a multiplexed readout).

The current workaround

Currently, we manually configure the different attenuation settings at the Qblox hardware modules. This is problematic as the user (should) not know which hardware modules are connected to which output (not to mention the inconvenience and the fact that we are violating our paradigm). This will cause even more problems if/once we start to introduce more advanced compilation to take into account e.g., attenuation on the lines, or switching modules.

The solution

The solution is to correctly specify powers at the device layer. This can be done in two ways.

Solution A-> Specify the power in absolute terms

It has been suggested in the past that we could specify the absolute power level at the chip, or at the output of the Qblox hardware, perhaps with a single parameter that encapsulates both attenuation and ampltiude. This solution might seem the most straightforward, but there are some issues with this. This solution moves the power scaling completely to the compilation layer. This has some drawbacks.

  • The user loses any intuition on the (correct) use of the dynamic range of the hardware,
  • It requires a (very accurate) exact calibration of attenuation/amplification steps to avoid the effects of discontinuities when changing the reference power.
  • It is a big change from how we currently use things so it will require a different way of working and has huge backwards breaking incompatibilities.

Solution B-> Specify amplitudes with respect to a reference power

In this solution, all pulses have both a "reference_power" (new key to be added), and an amplitude in arbitrary units (scaling from -1 to +1 or similar). This reference power would be used to apply a scaling factor to the pulse powers produced by the device. In practice, this scaling could be done by applying a variable attenuation, for example.

The drawback of this solution is

  • that it requires 2 instead of 1 parameters.

There are however also some advantages to this method.

  • Using amplitude from -1 to +1 (in a.u.) was originally proposed by Jules as it more closely resembles how this works in the hardware. The Volt units are becoming meaningless to some extent.
  • Working with reference powers and scaling amplitudes with respect to that makes it really easy to do power calculations in the future so really helps UX and understanding of what the powers are at which point in the system for users without sacrificing the hardware awareness.
  • It is possible to introduce a semi-automated compilation where multiple operations sharing the same resource should have the same reference power. If they do not, either auto conversion is used (and a warning is given) or an exception is raised. This addresses problems with the discontinuities when changing the attenuation/gain setting.
  • As an initial implementation, the compilation step could support only a select few reference powers for which corresponding attenuation settings exist.

At OQS, we currently prefer option B, but we would be interested to hear what others think about it. These issues will become increasingly important as users start to do automated power calibration experiments and encounter issues such as fixing the attenuation levels for multiplexed readout.