Instruments#

One the key features of Qibolab is its support for multiple different electronics. A list of all the supported electronics follows:

Controllers (subclasses of qibolab._core.instruments.abstract.Controller):
Other Instruments (subclasses of qibolab._core.instruments.abstract.Instrument):

All instruments inherit the qibolab._core.instruments.abstract.Instrument and implement methods for connecting and disconnecting. qibolab._core.instruments.abstract.Controller is a special case of instruments that provides the qibolab._core.instruments.abstract.execute method that deploys sequences on hardware.

Some more detail on the interal functionalities of instruments is given in How to add a new instrument in Qibolab?

The following is a table of the currently supported or not supported features (dev stands for under development):

Supported features#

Feature

RFSoC

Qblox

QM

Arbitrary pulse sequence

yes

yes

yes

yes

Arbitrary waveforms

yes

yes

yes

yes

Multiplexed readout

yes

yes

yes

yes

Hardware classification

no

yes

yes

yes

Fast reset

dev

dev

dev

dev

Device simulation

no

no

yes

dev

RTS frequency

yes

yes

yes

yes

RTS amplitude

yes

yes

yes

yes

RTS duration

yes

yes

yes

yes

RTS relative phase

yes

yes

yes

yes

RTS 2D any combination

yes

yes

yes

yes

Sequence unrolling

dev

dev

dev

dev

Hardware averaging

yes

yes

yes

yes

Singleshot (no averaging)

yes

yes

yes

yes

Integrated acquisition

yes

yes

yes

yes

Classified acquisition

yes

yes

yes

yes

Raw waveform acquisition

yes

yes

yes

yes

Quantum Machines#

Tested with a cluster of nine OPX+ controllers, using QOP213 and QOP220.

Qibolab is communicating with the instruments using the QUA language, via the qm-qua and qualang-tools Python libraries.

Quantum Random Number Generator#

In addition to the above instruments used for QPU control, Qibolab provides a driver for sampling numbers from a quantum random number generator device (QRNG) in qibolab.instruments.qrng.QRNG. This assumes that the device is connected to the host computer via a serial port.

The following script can be used to sample 1000 floats uniformly distributed in [0, 1]:

from qibolab.instruments.qrng import QRNG

qrng = QRNG(address="/dev/ttyACM0")

qrng.connect()

samples = qrng.random(1000)

qrng.disconnect()

The QRNG produces raw entropy which is converted to uniform distribution using an exctraction algorithm. Two such algorithms are implemented

  • qibolab.instruments.qrng.ShaExtrator: default, based on SHA-256 hash algorithm,

  • qibolab.instruments.qrng.ToeplitzExtractor.

It is possible to switch extractor when instantiating the qibolab.instruments.qrng.QRNG object:

from qibolab.instruments.qrng import QRNG, ToeplitzExtractor

qrng = QRNG(address="/dev/ttyACM0", extractor=ToeplitzExtractor())

Simulation of QPU platforms#

Although Qibolab is mostly dedicated to providing hardware drivers for self-hosted quantum computing setups, it is also possible to simulate the outcome of a pulse sequence with an emulator. The emulator currently available is based on QuTiP, the simulation is performed by solving the master equation for a given Hamiltonian including dissipation using mesolve.

Qibolab currently support a model consisting of a single transmon with a drive term whose Hamiltonian is the following

\[\frac{H}{\hbar} = a^\dagger a \omega_q + \frac{\alpha}{2} a^\dagger a^\dagger a a - i \Omega(t) (a - a^\dagger)\]

where \(a (a^\dagger)\) are the destruction (creation) operators for the transmon, \(\omega_q\) is the transmon frequency, \(\alpha / 2 \pi\) is the anharmonicity of the transmon and \(\Omega(t)\) is a time-dependent term for driving the transmon.

The readout pulses parameters are ignored, given that the Hamiltonian doesn’t include a resonator. The only information used when the readout pulse is placed in the sequence which is necessary to determine for how long the system should be evolved. The results retrieved by the emulator correspond to the time when the readout pulse is played.

Measurements are performed by measuring the probability of each transmon state available. In the case of two levels we return the probability of finding the transmon in either \(\ket{0}\) or \(\ket{1}\). When AveragingMode.SINGLESHOT is used samples are generated from the probabilities computed previously. If AveragingMode.CYCLIC the following weighted average is returned

\[\mu = \sum_{i=0}^{N} i p_i\]

where \(p_i\) is the probability corresponding to state \(\ket{i}\), and \(N\) are the transmon levels available.

The emulator supports AcquisitionType.DISCRIMINATION. We also provide a way of retrieving information with AcquisitionType.INTEGRATION by encoding into the \(I\) component the probabilities and while the \(Q\) component is set at 0. We add a Gaussian noise both on \(I\) and \(Q\). This should be enough to get some meaningful results by computing the magnitude of the signal \(\sqrt{I^2 + Q^2}\).

Example of platforms using the emulator are available here.