XCOM: Full Mesh Network Synchronization and Low-Latency Communication for QICK (Quantum Instrumentation Control Kit)

Abstract

Quantum computing experiments and testbeds with large qubit counts have until recently been a privilege afforded only to large companies or quantum technologies where scaling to hundreds or thousands of qubits does not require a substantial increase in quantum control hardware (neutral atoms, trapped ions, or spin defects). Superconducting and spin qubit testbeds critically depend on scaling their control systems beyond what a single electronics board can provide. Multi-board control systems combining RF, fast DC control, bias, and readout require precise synchronization and communication across many hardware and firmware components. To address this, we present XCOM, a network that synchronizes QICK boards and the absolute clocks governing quantum program execution to within 100 ps, free of drift and loss of lock. XCOM also provides deterministic, all-to-all simultaneous data communication with latency below 185 ns. Like QICK itself, XCOM is compatible with a broad range of qubit technologies and is designed to scale to large systems.

Figures (5)

• Figure 1: XCOM block diagram. Each QICK board connects a Tx$_{\texttt{data/clk}}$ output to a pair of LVDS lines. Three Tx$_{\texttt{data/clk}}$ channels are shown in purple, blue, and red. All boards have Rx$_{\texttt{data/clk}}$ inputs to listen to all Tx$_{\texttt{data/clk}}$ channels. A shared GPS/SYNC reference (bottom) provides the external clock common to all boards.
• Figure 2: XCOM hardware. (a) Transceiver board mounted on the RFSoC FMC connector, providing one Tx$_{\texttt{data/clk}}$ driver and five Rx$_{\texttt{data/clk}}$ receivers via three RJ45 connectors. One such board is required per QICK board in the network. (b) Standalone fanout hub, which distributes each incoming Tx$_{\texttt{data/clk}}$ pair to five Rx$_{\texttt{data/clk}}$ output pairs, one per board in the network.
• Figure 3: Block diagram of the XCOM fanout hub. Each Tx$_{\texttt{i}}$ ($\texttt{i} = 0, \ldots, 4$) originates from a different RFSoC board and is copied five times by fanout buffer FO$_{\texttt{i}}$. Each output is routed to one Rx$_{\texttt{i}}$ on a board in the network. Tx$_{\texttt{i}}$ and Rx$_{\texttt{i}}$ blocks sharing the same color reside on the same RFSoC FMC transceiver board (Figure \ref{['fig:XCOMhw']}a).
• Figure 4: QICK firmware block diagram. Two QICK firmware FPGA blocks (light green) are shown, each connected to a shared external stable reference and to the XCOM parallel bus. Each firmware block contains up to 16 Signal Generators (SG, with up to 16$\times$ frequency multiplexing), up to 8 Readouts (RD, with up to 8$\times$ frequency multiplexing), 16 digital I/O channels, and peripherals including the XCOM. Each block has a dedicated tProc and absolute time clock. The DACs and ADCs are internal to the RFSoC FPGA and communicate with the logic blocks at up to 10 GS/s and 2.5 GS/s, respectively. All blocks operate in the experiment clock domain. The QICK firmware communicates with the FPGA's built-in quad-core ARM processor (PS) and through it to the client PC.
• Figure 5: Oscilloscope traces of three RF waveforms from three different QICK boards and one PMOD digital I/O signal, all triggered simultaneously via matched-length cables. The PMOD drivers are bandwidth-limited, showing a 1.5 ns rise time. The inset shows a timing skew of only 20 ps between the three RF channels, demonstrating sub-100 ps cross-board synchronization. Achieving this level of synchronization requires PLL nested zero-delay mode lock on each board, multi-tile synchronization (MTS) across DAC and ADC tiles within each board, and absolute clock alignment across all boards via XCOM.