We present \Qibosoq, an open-source server-side software package designed for radio frequency system on chip (RFSoC) for executing arbitrary pulse sequences and algorithms on self-hosted quantum processing units using only open-source software. \Qibosoqconnects the RFSoC firmware provided by Qick, a Quantum Instrumentation Control Kit, with Qibo, a quantum computing middleware framework that enables both experimental and gate-based applications. It simplifies the work of experimentalists and developers by managing client-server communication protocols, implementing tests, and validation procedures, thereby reducing the complexity of experimental setups. The client-side integration is achieved with dedicated drivers implemented in Qibolab, the specialized software module of Qibo for quantum hardware control. Therefore, this setup provides a seamless mechanism to deploy circuit-based algorithms on custom self-hosted quantum hardware platforms controlled by RFSoC electronics.
If you are looking for more details, kindly visit our website.
††preprint: TIF-UNIMI--18, CERN-TH--180Controlling superconducting qubits and other quantum technologies necessitates instruments and software drivers capable of generating and modulating arbitrary pulses in the microwave radio frequency range [1]. With qubits being extremely delicate systems, reliable and efficient control electronics are mandatory for the successful operation of quantum hardware [2].
Nowadays, one of the challenges of research institutions is to identify the proper set of instruments with the desired specifications for quantum technologies. An important figure of merit, other than performances, is price. In the last decade, new proprietary commercial products dedicated to quantum computing have been released, some examples include Qblox [3], Quantum Machines [4], Zurich Instruments [5] among others. Despite the interest from manufacturers in commercializing expensive ready-to-run solutions, experimental laboratories still have to face the issue of acquiring instruments which are in continuous improvement in terms of firmware and software, therefore customers might participate indirectly as co-developer by providing feedback, testing and waiting for improvements. This situation is not ideal as it increases the manpower and time required by research teams in order to define the experimental protocols. \Qibosoqaddresses this by providing an open-source alternative that is intigrated in a full-stack framework.
Radio Frequency System on Chip [6, 7, 8, 9] (RFSoC) FPGA (Field Programmable Gate Arrays) is a low-cost hardware alternative which provides flexible development of firmware and software related to quantum technologies. The research community has already achieved open-firmware for quantum applications through the Qick (Quantum Instrument Control Kit) project [10], that enables the use of RFSoCs to generate the sequences of pulses required for controlling and reading out qubits. Moreover, Qick also provides a higher-level Python library that eases the execution of pulses.
In this manuscript, we present for the first time \Qibosoq [11], an open-source software package which unlocks Qick’s potential to execute quantum algorithms on self-hosted quantum hardware platforms through Qibo, a quantum computing framework [12, 13, 14, 15] and its hardware module Qibolab [16]. \Qibosoqprovides a dedicated application programming interface (API) for sending arbitrary pulses sequences to the Qick firmware. It is composed both of a server component, running on the RFSoC along with Qick, and of a remote client that can be attached to Qibolab or potentially other higher-level softwares. In Figure 1 we show a schematic view of the software stack from the quantum processing unit (QPU) to Qibo. The full pipeline is required for the execution of quantum circuit algorithms, but the user can also use directly Qibolab for setting up experiments related to pulse generation. The stack is designed in a modular way, therefore \Qibosoqcan also be used as a standalone server application which runs on RFSoC FPGA boards opening the possibility to interface Qick with multiple experimental configurations.
Having the Qick firmware integrared into the Qibo framework also unlocks the possibility of writing automated calibration and recalibration experiment without the need to define every protocol from scratch (leveraging Qibocal [17]). Moreover, various algorithms are already defined in Qibo (for example variational quantum algorithms for chemistry applications and error mitigation schemes for arbitrary circuits), so the integration provided by \Qibosoqallows any laboratory with superconducting qubits and a supported RFSoc, to control the full Quantum-computing stack with the same integrated framework.
The paper’s structure is as follows. In Section II we describe a detailed overview of the \Qibosoqlibrary for version 0.1.3. In Section III we show performance benchmark results and example results of calibration experiments. Concluding our study, we provide a summary and outline future development directions in Section IV.
In this section, we will provide a brief overview of the current status of the Qick project. We will then delve into the specifics of \Qibosoq, including its internal layout and the comprehensive set of supported features.
Introduced in , the Qick project offers an open-source qubit controller based on the Zynq UltraScale+ Xilinx ZCU111 [18] evaluation board, supporting direct radio frequency (RF) synthesis up to approximately GHz via the XCZU28DR RFSoC.
It consists of a custom FPGA firmware and a Python library for coding experiments.
The firmware leverages the RFSoC’s digital-to-analog converters (DACs) as arbitrary waveform generators for RF pulses and enables fast, precise acquisitions through the analog-to-digital converters (ADCs). Additionally, it features a custom timed-processor (tProcessor) that allows users to program sequences of timed pulses and loops using an assembly-like language.
Since its initial presentation, the Qick firmware has undergone several updates and now supports the evaluation boards RFSoC4x2 [19] and ZCU216 [20] as well, mounting respectively the XCZU48DR and XCZU49DR chip. New firmware versions have been developed with support for multiplexing, enabling readouts on different qubits coupled to the same line using the same DAC and ADC. Moreover, the team is still exploring new functionalities, including resonator simulators on the FPGA, constant outputs and more specific DAC configurations.
The role of the software side of Qick is to eliminate the need for writing experiments directly in the tProcessor language. Instead, it allows users to write experiments in the Python programming language. It accomplishes this by offering helper functions and program templates that streamline the coding experience for users, while still leveraging the capabilities of the tProcessor.
Qick is currently used in different labs around the world, with application in different technologies such as superconducting qubit control, entangled photon pair generation, and SNSPD (Superconducting Nanowire Single-Photon Detectors) readout. Several experiments have been already published using the Qick to control superconducting quantum hardware [21, 22, 23, 24, 16, 25].
The introduction of Qick has already proven to be beneficial for researchers in developing custom solutions for qubit control. However, from a usability perspective, there are still some limitations. For example, to fully utilize the tProcessor’s functionalities, users are required to write more advanced code, even when using the Python API. This entails managing memory, registers, delays related to the processor latency and not only to the experiment itself, as well as other low-level aspects which can be cumbersome and error-prone for average users. Moreover, Qick operates exclusively at a pulse-level abstraction, and while this makes it a powerful tool for controlling quantum systems and executing pulse-based experiments, it is not directly suitable for quantum computing applications that rely on gate-based circuits.
In this context, \Qibosoqplays an important role by leveraging the existing Qick software and firmware to simplify the coding of quantum computing experiments in the tProcessor language. It offers a more user-friendly interface, allowing researchers to focus on their experiments, abstracting away the low-level details of the tProcessor. The experiments defined are still just based on pulses, but since \Qibosoqis natively integrated with the Qibo framework, performing circuit-based experiments become straightforward through Qibolab. Moreover, with this integration Qick becomes also connected with Qibocal [17] that enables simplified and automated qubit calibration. Lastly, it is possible to use directly Qibo to execute algorithms, that are first converted into pulses by Qibolab and then executed on the RFSoC using \Qibosoq. Overall, the connection between \Qibosoqand Qibo extends the capabilities of Qick, enabling users to work at both the pulse-level with additional tools and gate-level abstractions. We believe that researchers involved with studying and calibrating qubits (or in general superconducting devices) could be interested in using \Qibosoqin connection with Qibolab and Qibocal in order to focus on writing new experiments, without the need to re-write already existing ones. On the other hand, even researchers only interested in executing gate-based algorithms, without any specific knowledge on the control and readout of a superconducting qubit, could leverage the integration between \Qibosoqand Qibo in order to perform experiments on self-hosted qubits, while completely ignoring the gates implementation.
The boards supported by Qick share a common architecture, that includes an on-board CPU, beyond the actual FPGA device. This design makes them independent, not requiring a further processor to execute applications. Qick itself is organized to run on this embedded processors, based on Pynq [26] structure.
However, the typical QPU user will not have direct access to the board, writing or loading its software there, but the access will be granted through a network. For this reason, since \Qibosoqis already operating at a higher level than Qick, it is worth to take into account the networking part, controlling the communication between the board and the end user, making it as simple as possible, while flexible enough to support many different kinds of applications.
The communication layer can happen at different levels, e.g. it could transfer entire executables and run them on-board or transmit just minimal set of instructions. This might be advantageous to allow lower level access to the user, thus being free to access primitives from the programming language and Qick library. But this is not the typical use case, since most of the QPU operations share a common layout.
Recognizing the common elements allows us to factorize them out from the multiple applications into a single library, reducing duplication and simplifying the applications development. Furthermore, restricting the applications’ degrees of freedom reduces the amount of information that has to be transferred on the network, eventually providing a higher communication efficiency. These considerations led the design of \Qibosoqand its own internal language for experiments description.
In this matter, there are other two considerations that is worth taking into account. One is related to the available on-board CPUs, the other to a partial current Qick limitation.
When taking into account where to run the application bulk, the nature of the application itself has to be examined. Some applications require to run just QPU experiments and collect their data, for further elaboration later on. This kind of application is QPU-bound, and it has very limited requirements in terms of classical processing. However, more hybrid applications are also possible: a typical example being a Quantum Machine Learning (QML) with classical optimization, where the QPU usage is interleaved with classical computation. When coming to hybrid applications there are two competing factors: latency and performances. Limiting possible applications to run on the on-board CPUs it would not scale, i.e. it would not allow to keep good performances for increasingly larger problems (as compared to the time required for execution on other commonly available hardware), becoming soon the main bottleneck. On the other hand, off-loading the computation to a separate machine introduces communication latency during the application execution. The chosen trade-off in \Qibosoqvalues more the potential application scaling, giving it the flexibility to support arbitrary kinds of hybrid applications, at the expense of time performances. This takes into account the current limited performances of the on-board CPUs. For instance, the Xilinx [27] boards feature ARM Cortex-A53 processors, which are considerably slower even than processors found in most modern laptops. In future, different type of boards might become available, and they could be developed having in mind quantum hybrid applications. Or the communication with an external processors might improve, not relying on a LAN but making use of local buses, like Peripheral Component Interconnect (PCI). \Qibosoqapproach is easily extendable to this improved scenarios, in which the same (or similar) internal language could be maintained, just acting on the communication layer implementation.
Instead, the second consideration is purely technical: each experiment in Qick requires a certain common initialization. Repeating this initialization has two main drawbacks, since on the one side it requires to pay every time the performance cost, and on the other it resets the ADCs and DACs clocks, thereby introducing a random phase between them, and consequently loosing phase coherence between experiments. This phase coherence is critical in quantum computing applications as it allows for qubit calibration to be maintained between executions, eliminating the need of a partial recalibrating every run. Because of this, it is necessary to keep a Qick instance alive between multiple user connections. This limitation requires to have at least a minimal server running on board. While Qick already provides a way of solving this problem, leveraging the Pyro4 library that is used to send the required objects through a network, it is still designed as an on-board software and the integration is not straightforward. \Qibosoqis built as an alternative to this solution to make it easier to control Qick remotely, while also simplifying its control and integrating it with Qibo. In this sense, \Qibosoqis just an extension of Qick, offering a higher level interface, preferable for the end user applications development.
It is relevant to note that, despite having discussed of user applications until here, a \Qibosoquser might also be a higher level library, dealing with some kind of task involving QPU execution. Qibolab and Qibocal are two examples of this layout, and they showcase the flexibility of \Qibosoq, to support arbitrary execution through an RFSoC controller. In particular, Qibolab also allows the execution of arbitrary circuits, described in the Qibo language, and shows how it is possible to deal with the transpilation and experiment preparation on the \Qibosoqclient side, making use of arbitrary classical resources.
Instead, Qibocal is a perfect example of how multiple clients can share the same server, since its calibration routines are all potentially independent, and being executed as fully separate programs. The only requirement to interface with the \Qibosoqserver is to describe the final QPU execution using \Qibosoqprimitives, and finally establish a connection to the server.
is composed of multiple submodules: the programs, representing Qick programs, and eventually taking care of the experiment compilation into the tProcessor language, the components, high-level structures used in the programs construction, the server implementation, and client utilities, to manage the communication.
The programs bridge the gap between the high-level interfaces (components) and the low-level execution on quantum hardware. Eventually, only two distinct programs are directly used, but the full hierarchy (presented in Figure 2) also includes intermediate abstractions. Considering all layers, the defined programs are:
the abstract base program, that contains functions shared among all possible experiments and executions. It serves as the foundation for all the other \Qibosoqprograms;
the abstract flux program, that collects the additional elements required for controlling flux-tunable qubits. In addition to the functionalities defined in base, it includes support for bias voltages and fast DC (direct current) pulses;
the sequences and sweepers programs that contain the different elements used, respectively, in the execution of fixed parameters pulse sequences and real-time sweeps. They inherit all the functionalities defined in base and flux, while also being specific implementations of Qick classes: the AveragerProgram and the NDAveragerProgram.
With this set of programs it is possible to define a large variety of experiments. Indeed, the number of drive pulses, of readouts and flux pulses, is only limited by the on-board available memory. And various acquisition modes are available for all the combinations of pulses. Moreover, using sweepers it is possible to speed up real experiments, taking the best out of the tProcessor speed.
There is no requirement for the final user to have direct knowledge of which program subclass is used, since \Qibosoqtakes care of it automatically.
The components play the crucial role of establishing a common language for communication, easing the implementation of a \Qibosoqclient in Qibolab or by other parties. The main elements defined within the components submodule include:
the Config object that contains essential general information required for executions. This includes the number of software and hardware repetitions, delay between repetitions (to ensure qubit relaxation), and whether to average the results among repetitions or not;
the Pulse base object that serves as the foundation for different implemented pulse shapes. Rectangular, Gaussian and DRAG [28] pulses are natively supported, as well as custom waveform shapes defined by their ”in-phase“ and ”quadrature“ (IQ) [29, 30] values;
the Qubit object that holds information about any necessary bias required for operating it;
the Sweeper and Parameter objects that are used to describe real-time on-hardware scans.
Using these components, the typical \Qibosoqprogram will start with something similar to
fromqibosoq.components.baseimport( Qubit, Config ) fromqibosoq.components.pulsesimportRectangular pulse=Rectangular( frequency=, amplitude=1, relative_phase=0, start_delay=1, duration=1, name="mypulse", type="drive", dac=1, ) sequence=[pulse,pulse,pulse] config=Config( relaxation_time=50, reps=, average=False ) qubit=Qubit(bias=0.1,dac=2)Note that almost every line of this snippet was related to experiment parameters.
Pulse, Sequence, Config and Qubit are all mandatory objects that are used in any experiment, while Sweeper objects need to be defined only when used.
The last two fundamental elements in \Qibosoq, are the client and the server. The client is composed of a set of tools used to connect to the server, convert components into a serialized form, and send them following the \Qibosoqcommunication protocol. The server implements the on-board server, continuously listening for connections, and executing received instructions by initializing and running the required programs on the quantum hardware.
Albeit these are fundamental parts of \Qibosoq, the user usually will not directly care about them, interacting only with the more user-friendly interface. Only on startup of the board it is required to start the server with the command-line:
python-mqibosoqA full description of the API and all Qibosoq capabilities can be found in the online documentation [31], alongside extended tutorials teaching how to use it to implement various experiments.
To run an experiment, users in the client need to define instructions using \Qibosoqcomponents, describing the experiment to be executed. These instructions are then sent to the server using the Transmission Control Protocol (TCP) for communication. TCP was chosen for its reliability [32], since it ensures data integrity, preventing any loss during transmission. Additionally, its session-based protocol suits \Qibosoq’s requirements by disallowing multiple concurrent executions, ensuring smooth and well-controlled communication between the server and potentially multiple clients.
While the server is composed only of \Qibosoqcode, the client can be part of very different frameworks or even be just a standalone script, as long as it sends to the server the expected commands in the expected format, \Qibosoqwill work properly. Through the client module, \Qibosoqoffers some helpers to make following the communication protocol easier.
The \Qibosoqcommunication protocol is schematically presented in Figure 3.
The first step in the process is defining the experiment to be executed, utilizing the \Qibosoqcomponents:
supports different execution modes that can be selected through a specific component. These modes enable the execution of different type of experiments:
fixed-parameters experiments defined as a sequence of pulses.
varying-parameters experiments defined using a combination of sequence of pulses and sweepers.
raw acquisition experiments, where the raw signal (after demodulation) is acquired without integration.
a Config object with general experiment parameters;
a list of pulses that describe the experiment, including control, flux, and readout pulses for performing measurements. Each pulse contains information about its shape, frequency, and start time.
a list of qubit objects.
a list of sweepers, only required for real-time parameter scans on the FPGA logic. The sweepers can act on multiple parameters simultaneously or update them sequentially, enabling exploration of all combinations of chosen parameters during the experiment.
This set of instruction provides a comprehensive description of the experiment to be executed and offer a flexibility that can accommodate various qubit-related experiments.
The first step ends with the serialization, where the instructions are first dumped in the JSON format and then encoded into bytes using UTF-8.
Then, a connection is established between the client and server. Following the TCP three way handshake, a first packet containing a 32-bit integer (four bytes) is sent. This integer represents the byte-size of the instructions to be transmitted immediately afterward.
Upon receiving and de-serializing the commands, the server initializes the required program based on the specified operation parameter. After executing the experiment, the server sends back the results, comprising acquired “i” and “q” values, through the same TCP connection to the client.
Once the client receives all the data, the connection is closed, and the server returns to waiting for new commands.
These operations are all executed automatically by the \Qibosoqpackage, so that the user does not have to take care of almost anything that is not related to the experiment itself. After definition of the sequence and required objects, the user is only required to write the commands in a dictionary for execution:
fromqibosoq.clientimportexecute server_commands={ "operation_code":OperationCode.EXECUTE_PULSE_SEQUENCE, "cfg":config, "sequence":sequence, "qubits":[qubit], } HOST="192.168.0.0" PORT= i,q=execute(server_commands,HOST,PORT)Note that, while \Qibosoqalready provides a client that takes care of implementing this communication protocol, it does not strictly require its use, and potentially other clients could implement the same protocol and interact with the \Qibosoqserver part.
abstracts a higher-level interface over the Qick primitives, and its current main purpose has been to serve Qibolab, despite not being restricted to it. Therefore, it is relevant to be aware of the present limitations of these related libraries when approaching \Qibosoq, and how \Qibosoqitself is affected by them.
In Table 1 a small comparison of the main features supported by Qick, \Qibosoqand Qibolab are presented.
Here, ”RTS“ refers to the term ”Real Time Sweeper“, denoting the ability to conduct parameter scans directly on FPGA logic. For a comprehensive explanation of the mentioned features, please consult [16, Section III.B].
This selection of features, commonly used in standard qubit experiments, are all supported by \Qibosoq, with the notable exception of the feedback feature.
interwiser supply professional and honest service.
Using Qibolab, is also possible to access all of these features with the sole exception of sweepers on multiple different parameters with concurrent updates, that is also currently under development.
Some more limitations come directly from the hardware. \Qibosoqis compatible with all the boards supported by Qick, namely the RFSoC4x2, the ZCU216 and the ZCU111. In Table 2, the three RFSoCs are presented along with some details.
Note that, to control flux-tunable qubits, the companion boards included in the standard Xilinx kits are not sufficient, since they usually include also baluns on the single-ended outputs/inputs connected to the DACs and ADCs that filter the DC currents required for controlling the qubits. This problem can be solved by using the available differential outputs along with some differential amplifiers (as Texas Instruments THS [33]) to convert the signal from double to single-ended or with the use of custom companion boards [10, 8].
All the experiments presented in this section were performed using Qibocal, the runcards required to reproduce them are openly available at [34].
We tested \Qibosoqusing the Qibolab API, benchmarking its speed on different RFSoCs and against commercial instruments (Quantum Machines, QBlox and Zurich Instruments). The tested boards were the three Xilinx boards supported by Qick, better detailed in Table 2. For better significance, in the plots only the results of Quantum Machines are shown to represent commercial instruments, as QM was the fastest among the three in the majority of cases [16].
It is complex to do a proper and fair comparison between the software of different instruments, while avoiding to compare the hardware. For this reason we decided to compare only speed of execution, considering the deployment of experiment through the same interface, namely Qibocal.
The results are presented in Figure 4. The black bar in this plot provides the idealideal\mathrm{ideal}roman_ideal time required for each routine, calculated as
ideal=nshots∑i(Tsequence,i+Trelaxation)idealsubscript????shotssubscript????subscript????sequence????subscript????relaxation\mathrm{ideal}=n_{\mathrm{shots}}\sum_{i}(T_{\mathrm{sequence},i}+T_{\mathrm{% relaxation}})roman_ideal = italic_n start_POSTSUBSCRIPT roman_shots end_POSTSUBSCRIPT ∑ start_POSTSUBSCRIPT italic_i end_POSTSUBSCRIPT ( italic_T start_POSTSUBSCRIPT roman_sequence , italic_i end_POSTSUBSCRIPT + italic_T start_POSTSUBSCRIPT roman_relaxation end_POSTSUBSCRIPT ) (1)where Tsequence,isubscript????sequence????T_{\mathrm{sequence},i}italic_T start_POSTSUBSCRIPT roman_sequence , italic_i end_POSTSUBSCRIPT is the duration of the whole pulse sequence in the i????iitalic_i-th point of the sweep, Trelaxationsubscript????relaxationT_{\mathrm{relaxation}}italic_T start_POSTSUBSCRIPT roman_relaxation end_POSTSUBSCRIPT the time we wait for the qubit to relax to its ground state between experiments, nshotssubscript????shotsn_{\mathrm{shots}}italic_n start_POSTSUBSCRIPT roman_shots end_POSTSUBSCRIPT the number of shots in each experiment and the sum runs over all points in the sweep. The idealideal\mathrm{ideal}roman_ideal time denotes how long the qubit is really used during an experiment and provides the baseline for our benchmark.
The experiments were repeated for shots. Between shots, we waited a certain amount of time: 5μ5????5\,\mu5 italic_μs for spectroscopies, 300μ300????300\,\mu300 italic_μs for the others. A complete description of the experiments performed is given in [16, Appendix B]. Note also that the code required to reproduce these experiments is available at [34].
Among the RFSoCs, we can see that the RFSoC4x2 consistently outperforms the ZCU111 and the ZCU216 in speed. On the other hand, comparing it also with Quantum Machines, we can see that the \Qibosoq-controlled devices are faster in six out of the eight performed experiments.
The key to explain the difference in speed between the \Qibosoq-controlled boards and the commercial instruments can be found in the Ramsey detuned experiment timings. This routine involves sweeping the relative phase and the start time of a pulse, a feature not supported by Qibolab. Therefore, the experiment is performed via the execution of various pulse sequences that get generated once at a time from the client. This translates itself in a high number of communications between the client and the device. In this regard, it is possible to note that the RFSoCs present a much smaller overhead in the communication in respect to commercial instruments, partially being explained with being composed of a single device and not with multiple synchronized modules. The communication overhead, including also any time required by the instrument to set up, approximately corresponds to the first point of the plot presented in Figure 5, where the sequence execution time is negligible with respect to the overhead itself.
The only experiment (among the one analyzed) where the RFSoCs are sensibly slower than the commercial systems is the resonator spectroscopy experiment that can be conducted with a real-time sweeper, on hardware, for all the other considered devices, while it’s currently not supported by \Qibosoqand by the standard Qick firmware as shown in Table 1
In Figure 5, the results of a benchmark on the scaling capability of sweepers (increasing the number of points swept) and of circuits (increasing the number of circuits executed) are presented. For the readout and drive frequency, the experiment-template of resonator and qubit spectroscopy was used, while for pulse amplitude and length a Rabi-like experiment was performed. For the pulse start, a standard T1 experiment was used and for the circuits a standard Randomized Benchmarking (RB) [35]. The focus of this plot is, however, the parameter swept (or the number of circuits executed) and not the experiments themselves.
We can clearly see which sweepers are not implemented with real-time sweepers (on the readout frequency and on the pulse length), not considering the “Circuits” plot that cannot logically being implemented with sweepers.
For the majority of these plots we can see that, initially, where the effective duration of the experiment is given almost completely by the overhead, the RFSoCs perform much better than the commercial systems. Increasing the number of swept values, however, decreases the difference of duration between instruments, with the commercial ones that even becomes slightly better than the RFSoCs for many-points scans.
Alongside the presented speed benchmarks, we conducted tests of \Qibosoqon quantum hardware, connecting the available boards to various single qubits, without flux dependency, manufactured by TII (Technology Innovation Institute) and a flux-tunable multi-qubit chip, by QuantWare [36].
While performing a comprehensive quality benchmark is challenging due to the numerous variables in calibration, the RFSoC-based system demonstrated competitiveness with commercial instruments, reaching values compatible between instruments and in accord with design parameters, considering multiple calibrations executed from scratch, both for the assignment fidelity and the single-gate fidelity (computed with RB).
More generally speaking, there is evidence beyond this paper suggesting that RFSoC hardware should perform at least on-par to standard hardware and that there is no performance reason to prefer the latter in respect to the former [37, 7, 38, 39, 40, 41]. The differences therefore lie in speed and, in particular, software features and frameworks integration.
Some examples of the obtained results are shown in Figure 6.
The initial two plots feature the Xilinx RFSoC4x2 connected to a single qubit within a 3D cavity. In the first plot, we show the result of the T1subscript????1T_{1}italic_T start_POSTSUBSCRIPT 1 end_POSTSUBSCRIPT and T2subscript????2T_{2}italic_T start_POSTSUBSCRIPT 2 end_POSTSUBSCRIPT experiments. For T1subscript????1T_{1}italic_T start_POSTSUBSCRIPT 1 end_POSTSUBSCRIPT, the relaxation time, we start each shot with the qubit prepared in the excited state and then measure its value at different times. We expect to see an exponential decay of which T1subscript????1T_{1}italic_T start_POSTSUBSCRIPT 1 end_POSTSUBSCRIPT is the time factor. For the T2subscript????2T_{2}italic_T start_POSTSUBSCRIPT 2 end_POSTSUBSCRIPT, we implemented the Ramsey experiment in the Echo version [42]. We first prepare the qubit in an equal superposition of the two states via a π/2????2\pi/2italic_π / 2 pulse, wait for a variable period of time t????titalic_t, apply a π????\piitalic_π-pulse and than again a π/2????2\pi/2italic_π / 2 pulse after t????titalic_t. If the pulses are on resonance with the qubit frequency, we again expect to see just an exponential curve, with T2subscript????2T_{2}italic_T start_POSTSUBSCRIPT 2 end_POSTSUBSCRIPT as time constant. The measured value are in alignment with design parameters: T1=19μsubscript????119????T_{1}=19\muitalic_T start_POSTSUBSCRIPT 1 end_POSTSUBSCRIPT = 19 italic_μs and T2=11μsubscript????211????T_{2}=11\muitalic_T start_POSTSUBSCRIPT 2 end_POSTSUBSCRIPT = 11 italic_μs.
As an example, we write here also a sketch of the \Qibosoqscript to execute the T1subscript????1T_{1}italic_T start_POSTSUBSCRIPT 1 end_POSTSUBSCRIPT experiment (see the documentation for complete calibration scripts [31]):
fromqibosoq.components.pulsesimport( Gaussian, Rectangular ) fromqibosoq.components.baseimport( Config, Parameter, Sweeper ) pulse_1=Gaussian( frequency=1_000_000_000, amplitude=0.5, duration=500, type="drive", dac=0 ) pulse_2=Rectangular( frequency=1_500_000_000,amplitude=0.5, duration=,name="readout_pulse", type="readout",dac=1, delay_start=500, adc=0 ) sequence=[pulse_1,pulse_2] sweeper=Sweeper( parameters=[Parameter.DELAY], indexes=[1], starts=[0.0], stops=[8.5], expts= ) server_commands={ "operation_code":OperationCode.EXECUTE_SWEEPS, "cfg":Config(), "sequence":sequence, "sweepers":[sweeper], "qubits":[qubit], } HOST="192.168.0.0" PORT= i,q=execute(server_commands,HOST,PORTIf we wanted to leverage the already-written experiments in Qibocal, then we would just need (after an initial configuration) to define a yaml runcard file (see [17] for better reference):
-id:t1 priority:0 operation:t1 parameters: delay_before_readout_start:0 delay_before_readout_end: delay_before_readout_step:10This second method (leveraging Qibocal) should be the preferred way of executing already present since it enables the experimenter to avoid any code-writing, while focusing only on physical parameters. Anyway, even the bare \Qibosoqcode has just information on control pulses and take care automatically of communication and of any processor-level instructions.
The second plot shows the result of an assignment fidelity experiment, where the qubit is first prepared in a state (|0⟩ket0\ket{0}| start_ARG 0 end_ARG ⟩ or |1⟩ket1\ket{1}| start_ARG 1 end_ARG ⟩ by applying a π????\piitalic_π-pulse to excite the qubit) and then a dispersive measurement is performed, retrieving a single IQ value. When plotting the result of multiple preparations and measurements for the two states, we expect to see two well-discriminated areas. In this case, we then discriminate the two states just by finding the straight line that better divides the two groups. As per standard, we then use this method to assign every IQ value to one of the two states. The number of states prepared as |0⟩ket0\ket{0}| start_ARG 0 end_ARG ⟩ (|1⟩ket1\ket{1}| start_ARG 1 end_ARG ⟩) and then assigned to the same state, divided by the total count of prepared states, renders the assignment fidelity. In the plot presented, the resulting assignment fidelity observed was 0.950.950.950.95.
The third plot involves a multi-flux-tunable-qubit setup controlled by the Xilinx ZCU216 RFSoC. A two-tone spectroscopy was carried out as a function of a DC voltage produced by the RFSoC, which is linearly related to the applied flux bias to the qubit SQUID that is used for tuning. From this plot we can study the correlation between the 0-1 transition frequency and a bias current for the sample under test.
These three experiments are just examples of the various possibilities in which \Qibosoqcan be of use. These are standard characterization experiments that need to be executed for every (eventually flux tunable) qubit calibration. Through Qibocal, the user would not need to write them from scratch, just focusing on experimental parameters. Moreover, they showcase different types of experiments: from left to right we have parameter one-dimensional sweeps experiments, single-shot experiments and lastly an example of a two-dimensional sweep experiment.
First of all we note that any circuit-based experiment require an initial calibration, the output of which in this case has to be stored in a specific configuration file employed by Qibo in order to transcript a gate to a pulse. In the following case, the calibration values (eventually produced with Qibocal), are used to generate a gate-based application:
fromqiboimportCircuit,gates NSHOTS= circuit=Circuit(1) circuit.add(gates.GPI2(0,phi=np.pi/2)) circuit.add(gates.M(0)) qibo.set_backend("qibolab",platform="rfsoc") hardware_result=circuit(nshots=NSHOTS) freq=hardware_result.frequencies() p0=freq.get("0",default=0)/NSHOTS p1=freq.get("1",default=0)/NSHOTSWe want to emphasise that although this application in itself is trivial, we are showcasing an example of how a self-hosted (maybe even self-manufactured) qubit can be used for algorithms without the need of any commercial instrument or software.
\Qibosoqhas already be used in more interesting algorithmic application as presented in [16].
In this paper we have presented \Qibosoq, an open-source server-side software for controlling RFSoC electronics via Qick. This setup simplifies operation of self-host quantum hardware platforms through Qibo, a full-stack quantum computing middleware framework.
We have outlined the present state of the project’s structure, emphasizing the significant features integrated into release 0.1.3. The software is at the stage of allowing applications related to performance benchmarks through arbitrary pulse control and physics experiments based on the quantum circuit representation respectively with the APIs of Qibolab and Qibo. Thanks to this integrations, \Qibosoqcan be used to speed up characterization experiments as well as deployment of arbitrary gate-based algorithms. Therefore, it is an optimal solution for laboratories interested in developing the full stack of quantum computing (from the qubits to the algorithms).
As far as we are aware of, right now \Qibosoqis the only solution that allows experimenters to control a superconducting qubit using exclusively open-source software, while simultaneously enabling both low-level applications (like characterization experiments) and high-level ones, with algorithms deployment. Historically open-source and community-driven projects have been essential to the development of standard computation, and because of this we believe that is quite important to have a high-standard, open-source and full-stack quantum computing framework.
In the future releases of \Qibosoq, we plan to extend its capabilities to support multiple synchronized RFSoC boards and test the framework on other quantum technologies such as trapped ions, neutral atoms and photonics among others.
The \Qibosoqmodule and all results can be reproduced using the code at:
https://github.com/qiboteam/qibosoq.
while the complete package documentation, along with several examples, can be found at:
https://qibo.science/qibosoq/stable.
Modern Electronic Warfare (EW) systems must handle an avalanche of RF signals across wide frequency ranges. Whether it’s detecting agile radar pulses or intercepting bursty communications, the ability to capture and process high-bandwidth data in real time is critical. One of the toughest challenges in EW today is capturing high-frequency, wideband signals with fast analog-to-digital converters (ADCs) and processing them quickly. Missing a fleeting frequency hop or a short radar pulse could mean missing a threat.
Recent advancements – like integrating fast RF-sampling converters and FPGAs into a single Radio Frequency System-on-Chip (RFSoC) – enable EW receivers to directly sample wide swaths of spectrum. However, these RFSoC devices can produce data streams on the order of hundreds of gigabits per second, pushing the limits of traditional recording and storage methods. This is where high-speed Ethernet-based recorders come in: they provide a way to stream and store huge volumes of digitized RF data in real time, without packet loss, for immediate or post-mission analysis.
In summary, fast data capture and processing are no longer luxuries in modern EW – they’re necessities to keep up with advanced threats.
To illustrate the need for a high-speed recorder, consider a radar threat analysis application. In this scenario, an EW system is tasked with intercepting and analyzing enemy radar signals (for example, an airborne early warning radar or a fire-control radar on an adversary’s platform). Modern radars often employ wideband, agile waveforms – a pulse might be frequency-hopping across hundreds of MHz or using a wide chirp bandwidth.
The EW receiver must capture these pulses across a broad spectrum in real time to identify the radar’s characteristics. This demands a wide instantaneous bandwidth and high dynamic range from the receiver. Generating and capturing pulsed RF signals in real time across a very wide frequency range is inherently difficult and requires high-bandwidth equipment.
A 100 GbE recorder in this application allows continuous recording of the incoming wideband signal stream. Instead of just observing snapshots, engineers can record minutes or hours of raw IQ data covering the full radar bandwidth. This is invaluable for post-mission analysis: one can extract pulse timing, modulation patterns, frequency hops, and other fingerprints of the threat radar.
In short, wideband signal capture with an Ethernet recorder ensures that no critical signal is missed, enabling thorough radar threat analysis and robust Electronic Support Measures (ESM).
The RFSoC board is the front-end that directly interfaces with the signals from the RF Frontend and antennas. For example, the RFSoC 4×2 board (built around the Zynq UltraScale+ RFSoC) integrates four 5 GS/s ADCs (up to 2.5 GHz bandwidth) and two 9.85 GS/s DACs on the same chip, alongside a large FPGA fabric and multi-core ARM processor.
This monolithic design eliminates the need for separate ADC cards and FPGA boards – the RFSoC handles both digitization and initial processing.
Notably, the RFSoC 4×2 includes a QSFP28 high-speed networking port, which can be configured as 4×25 Gbps, 2×50 Gbps, or 1×100 Gbps Ethernet. In our system, this port is used to stream digitized data off the board.
The FPGA on the RFSoC is programmed to packetize the ADC samples (for example, into Raw IQ UDP packets or a standard like VITA-49) and send them out over this 100 GbE link in real time. The RFSoC can also perform some real-time DSP – e.g. digital down-conversion, filtering, or channelization – to reduce data volume or isolate signals of interest before streaming, but it will still output a very high data rate.
The second major component is the Ethernet recorder, essentially a high-speed streaming storage system. This is typically a rackmount server or specialized recorder appliance equipped with a 100 GbE network interface (often a QSFP28 port to match the RFSoC) and an array of fast storage drives.
The recorder connects to the RFSoC board via a 100 GbE fiber or copper cable (e.g. an MPO optical cable if using optical transceivers). It is designed to ingest the 100 Gbps data stream in real time and write it to disk at full line rate.
Modern recording systems can sustain about 12.5 GB/s write speeds (100 Gigabits per second) to disk, often using RAID0 sets of NVMe SSDs. For instance, Daqscribe MDR Carbon100 recorder uses six NVMe drives in parallel and an AMD CPU to achieve 100 Gbps recording with up to 75TB of storage. That capacity equates to several hours of multi-channel wideband recording in a small form-factor. If higher bandwidths are required, the DDR Hyperion400 can support up to 400 Gbps with up to 720TB storage.
In our architecture, the recorder is configured to listen for the RFSoC’s UDP streams on the 100GbE interface. It can capture multiple channels simultaneously – for example, up to four independent ADC streams over a single 100GbE link – and saves each stream to its own file in real time. The data recorded is typically the “payload” of the Ethernet packets (the IQ samples), often stored in a standard format that can be later parsed for analysis. Meanwhile, the recorder’s software, nStudio, provides feedback on the data flow (packet counters, throughput, etc.) to ensure no data is lost.
The overall data flow pipeline thus looks like:
If we were to record IQ instead of Raw RF, we must double our bandwidth since we need two channels I and Q.
However, the 100GbE interface on the RFSoC4x2 can only handle 12.5 GB/s, meaning we cannot stream all four channels at full rate without dropping data. To fit within this limit, we have a few options:
By implementing decimation or selective streaming, the system stays within 100GbE limits while still capturing high-quality wideband RF data for analysis.
*The Xilinx RFDC (RF Data Converter) ADC block streams out data at 16bit, however, only the 14 MSB bits are relevant.
Begin by connecting the RFSoC board’s QSFP28 100 GbE port to the recorder’s 100 GbE network port. Depending on the hardware, this may involve inserting a 100G optical transceiver module into the QSFP28 cage on each end and running an MPO fiber cable between them. (Some setups use direct-attach copper cables if the distances are short.) Ensure both the RFSoC board and the recorder are powered on and properly configured for 100G link operation (the link status LEDs on the QSFP28 ports should indicate an active link). The RFSoC 4×2’s networking must be configured to match the recorder’s settings – typically, you’ll assign an IP address to the RFSoC’s 100GbE interface or use a raw Ethernet mode as required by the recorder. No special external trigger connections are needed; all data will flow through the 100G link.
On the RFSoC side, load the FPGA design that implements the high-speed data source. For an actual EW capture, this design would take samples from the RFSoC’s ADCs, perhaps apply some signal processing, and then format the data into Ethernet packets. In a demo or lab test, you might use a simple pattern generator or loopback: for instance, have the RFSoC transmit a known test waveform or even a PRBS (pseudo-random bit sequence) over 100GbE. The key is that the RFSoC is now streaming data at a very high rate. Many RFSoC reference designs provide example 100GbE UDP streaming logic. Make sure to set the destination IP/port to what the recorder expects (or use a predetermined protocol if the recorder is protocol-agnostic). At this stage, the RFSoC’s processor (ARM cores) can be used to control the streaming—starting and stopping the flow, adjusting parameters, etc., via software.
On the recorder system, launch the recording software and prepare it to capture the incoming stream. Typically, you would define a recording session specifying which interface to capture from (the 100GbE port) and any filtering or channel setup (for example, capture all UDP packets on a certain port, or capture multiple streams separately). In our case, since we expect up to four independent streams from the RFSoC, the recorder can be set to listen for up to 4 UDP ports and save each to a separate file simultaneously. Ensure the storage array on the recorder has enough space and the system is optimized for the high write rate (these recorders usually have large RAM buffers to handle bursts). Once everything is ready, arm the recorder (essentially “press record”). The system should now be waiting and ready to write incoming data to disk.
With both sides set up, start the data flow. This might be as simple as initiating the transmit function on the RFSoC application or toggling a GPIO that tells the FPGA to begin sending ADC data. Immediately, you should see the recorder registering the incoming stream – e.g. the software will show a rising throughput meter, ideally near 100 Gbps utilization. In real EW use, this is the moment the RFSoC is digitizing live RF signals (from an antenna or a signal generator) and streaming them out. Let the capture run for a short period for the demo (say, capture a few seconds of data which at 12.5 GB/s will already be tens of gigabytes). Then stop the RFSoC stream and stop the recorder. The recorder should now have saved data files, each containing the raw digitized samples from one channel (or whatever format was transmitted).
Now for the payoff – evaluating the captured data. High-speed recorders typically come with built-in tools to review the data. For example, the Mercury SystemFlow software includes a Signal Viewer utility for basic analysis. An engineer can open the recorded file and immediately view the waveform or spectrum to ensure the signal was captured correctly. If we transmitted a known test pattern, we can verify it bit-for-bit. In a real scenario (say we recorded live radar pulses), we could zoom in on the timeline to measure pulse widths and intervals, or perform an FFT to examine the spectrum. The captured files can also be loaded into standard analysis programs. Many recorders save in standard formats (like PCAP or binary IQ), so tools like MATLAB, Python scripts, or even Wireshark (for packet-level inspection) can be used to further analyze the data. The main point is that engineers now have a permanent recording of the RF signal which can be scrutinized in detail. They might discover, for instance, a faint low-power emitter in the background of the recordings or verify that a radar’s frequency hop pattern matches expectations. This ability to capture and then post-analyze wideband data gives EW engineers tremendous insight that real-time processing alone might miss.
Throughout this demonstration, the performance benefits of using a 100GbE link become clear. The RFSoC4x2 board is able to stream all four ADC channels to our ethernet recorder without dropping any packets.
The recorder, for its part, captures everything cleanly with no packet loss, something impossible on slower interfaces. In our next blog series, we’ll go into detail how to capture all four channels without decimation, using the DDR Hyperion400.
By evaluating the recorded data, engineers can confirm that their system meets its requirements (e.g., it can handle the intended bandwidth) and they gain confidence that in a real deployment, the system will not miss critical signals.
Are you interested in learning more about Open Source RFSOC Algorithm Verification Evaluation Board? Contact us today to secure an expert consultation!