Quantum Instrumentation Control Kit (QICK)

repository·main·Indexed 43 days ago

https://github.com/openquantumhardware/qick

A toolkit for controlling RFSoC-based quantum hardware, featuring high-speed pulse sequencing, real-time feedback, and waveform generation using tProc cores. It includes tools for pulse synthesis up to 6 GHz, hardware-level conditional logic, and support for ZCU111, ZCU216, and RFSoC4x2 platforms. The project provides firmware generators, readout IPs, and the SideQICK client for cloud-based workload management.

Tokens
41.5K
Snippets
94
Records
186
Agent score
56%

What's inside QICK

  1. Overview of XCOM Multi-Board Synchronization

    main

    XCOM (X - Communication) is a full mesh network designed for precise synchronization and low-latency communication between multiple QICK boards. It allows scaling quantum control systems beyond a single RFSoC board.

    Key Capabilities:

    • Synchronization: Aligns multiple boards with <100 ps skew, preventing drift and loss of lock.
    • Communication: Provides deterministic, all-to-all simultaneous data exchange with latency below 185 ns (projected as low as 62 ns).

    Operational Modes:

    • Python scripts: Accessed via the AXI-lite interface (higher latency due to Linux overhead).
    • tProc programs: Real-time operation at fabric clock speed (lowest latency).

    Hardware Requirements:

    • FMC Transceiver Board: Plugs into the FMC connector of each ZCU216 board to route LVDS signals to RJ45.
    • External Hub: A fanout hub that copies transmitter signals to all receivers for full mesh connectivity.
  2. What is QICK?

    main

    The Quantum Instrumentation Control Kit (QICK) is an AMD RFSoC-based qubit controller designed for the direct synthesis of control and readout pulses in quantum computing experiments. It is a vertically integrated system consisting of:

    • Hardware: AMD RFSoC boards (ZCU111, ZCU216, or RFSoC4x2) often with custom analog front-ends.
    • Firmware: Custom FPGA logic including the tProcessor, DDS generators, and readout systems.
    • Software: A Python library used for pulse programming, data acquisition, and real-time feedback.

    All components (schematics, firmware, and software) are open-source.

  3. Overview of QICK RF frontend hardware

    main
    The QICK RF frontend consists of hardware designed for the ZCU111 platform. The project provides schematics and fabrication files (including Gerbers, BOM, and fab specifications) for two prototype versions of the ZCU111 RF board. Note that a ZCU216 frontend (referred to as the 'QICK box') is currently under development and may not be included in the current hardware documentation.
  4. What is the Signal Generator v6 (SG-v6)?

    main

    The Signal Generator v6 (SG-v6) is the latest QICK on-chip waveform engine. It is designed to replace SG-v5, offering a richer feature set and lower latency while maintaining full compatibility with QICK-compatible boards like ZCU216 and ZCU111.

    In Python, the SG-v6 is accessed via the qick.drivers.generator class. It functions by combining a dual-port memory (BRAM) for envelope samples, a FIFO for 160-bit waveform descriptors, and a central signal generation block that drives N parallel DDS channels.

  5. What is the axis_kidsim_v3 emulator?

    main

    The axis_kidsim_v3 is a per-lane RF resonator simulator used to test KID (Kinetic Inductance Detector) or qubit readout firmware and software. It allows for testing against a physically-realistic resonator response without requiring a real cryostat.

    How it works: Each lane demodulates its input with a DDS (Direct Digital Synthesis) carrier, applies a 1-pole/1-zero IIR filter at baseband (simulating the resonator response), and then remodulates the signal back to RF.

    Key characteristics:

    • It is not a readout itself, but a simulator for the resonator.
    • It wraps L parallel lanes (default L=8) behind a single AXI4-Lite register block.
    • Each lane processes one 32-bit {Q, I} sub-word of the packed AXI-Stream input.
    • It is exposed in Python via the AxisKidsimV3 class.
  6. Choose between accumulated and decimated readout modes

    main

    QICK programs that read data back use one of two mutually exclusive acquisition modes provided by the AcquireMixin (mixed into AveragerProgramV2 and older tProc v1 averager classes). Both modes use the same hardware trigger and window, but they integrate samples differently in the readout IP and return data with different shapes.

    Accumulated Readout (acquire)

    Use this for the vast majority of experiments where you need one (I, Q) point per shot (e.g., qubit state population, resonator response, or S-parameters).

    • Pros: Supports software thresholding (threshold/angle) for single-shot 0/1 classification; returns much less data, making it suitable for large parameter sweeps.
    • Data Access: Use get_raw for pre-averaging data or get_rounds for per-round data.

    Decimated Readout (acquire_decimated)

    Use this to view the time-domain (I, Q) waveform of the readout window. This is primarily for debugging (e.g., verifying window alignment, checking pulse envelopes, or observing resonator ringdown).

    • Pros: Provides the actual waveform shape.
    • Cons: Returns much larger data volumes (one waveform per shot); subject to buffer memory limits (buf_maxlen); does not support thresholding.
    • Tip: Pair this with get_time_axis to obtain a time axis in microseconds (us) for plotting.
  7. Perform math and memory operations in a QICK program

    main

    QICK programs can perform arithmetic and memory management directly on the hardware via tProc. Capabilities include:

    • Memory Access: Writing data to and reading data from tProc memory addresses, which are accessible by tProc registers.
    • Arithmetic Operations: Addition, subtraction, multiplication, and bit shifting.

    For a basic implementation, refer to 04_Reading_Math_Writing.ipynb.

  8. Understand the KID / Qubit Resonator Emulator (axis_kidsim_v3) physical model

    main

    The axis_kidsim_v3 emulator simulates a single-mode resonator in a notch/hanger geometry (reflection measurement). It works by demodulating an incoming stream with a DDS carrier, filtering the complex baseband with a first-order (1-pole/1-zero) IIR, and then remodulating back to RF.

    Core Logic:

    • Demodulation: Multiplies input by $e^{-j ext{phase}}$ using a DDS carrier.
    • Filtering: An IIR (iir_1p1z) runs on the demodulated baseband signal. The pole ($C_1$) sets the linewidth, the zero ($C_0$) sets the coupling, and the gain ($G$) sets the scale.
    • Remodulation: Shifts the passband back up to the carrier frequency $f_c$.

    Key takeaway: The resonant frequency is determined by the carrier (DDS_FREQ_REG), not the IIR pole. The IIR pole sets the linewidth/decay characteristics.

  9. Sweep variables within a QICK program

    main

    Instead of using a slow Python loop to iterate over multiple QICK programs, you can use the update function to modify parameters (such as pulse gain) within a single QICK program. This allows for high-speed parameter sweeping directly on the hardware.

    For a basic implementation, refer to 02_Sweeping_variables.ipynb.

  10. Choose between `acquire` and `acquire_decimated` readout modes

    main

    QICK provides two primary readout modes that differ in what they return and how they process data:

    • Accumulated (acquire): Use this mode when you need the full accumulated signal.
    • Decimated (acquire_decimated): Use this mode for decimated readout.

    Both modes share a common setup process. Consult the readout_modes documentation to determine which mode is appropriate for your specific measurement requirements.

  11. How QICK firmware components work together

    main

    The QICK firmware is organized into several functional families that interact on the FPGA:

    • Readout System: Converts ADC samples into I/Q data. It uses various down-converter and buffer cores. The standard workflow involves using declare_readout() followed by acquire(). Cores vary by whether they are software- or tProc-configured and whether they use on-chip BRAM or DDR4 capture.
    • Signal Generators: Convert pulse definitions into DAC output. This includes single-tone arbitrary-envelope generators (for shaped pulses) and multiplexed fixed-tone generators (for simultaneous tones on one channel).
    • Support & Utility Cores: Smaller IP blocks including constant-IQ tone sources, tProc-output register/trigger helpers, and AXI-Stream buffering cores.
    • tProcessor: The central controller. The tProcessor v2 is the current standard, providing real-time control with < 10 ns timing resolution. tProc v1 is the legacy version and is only relevant for maintaining older code/firmware.