NB688000-21-02120 SOW.pdf

STATEMENT OF WORK

ADVANCED REAL-TIME INFRASTRUCTURE FOR QUANTUM PHYSICS (ARTIQ)

SUBKERNEL AND SHUTTLER SUPPORT

NIST / Ion Storage Group (ISG) at performs a variety of quantum computing, quantum simulation, and optical clock experiments using trapped ions. These experiments are very complex and require advanced real-time classical control. The Advanced Real-Time Infrastructure for Quantum Physics (ARTIQ) experimental control system, developed specifically for the Ion Storage Group, is used to operate our experiments. For the next generation of quantum information and clock experiments, therefore, ISG requires the ability to distribute processing capability among multiple real-time processing nodes and the ability to integrate new high-speed DACs being developed elsewhere into the ARTIQ system. Finally, ISG requires reduced latency between experiments and software and gateware updates to ensure compatibility between the latest versions of ARTIQ and NIST-owned experimental hardware.

ITEM 1: This software and gateware entail subkernel support, kernel precompilation, and Shuttler DAC support as following:

Terminology note – ARTIQ-related acronyms are defined in the online ARTIQ documentation accessible at https://m-labs.hk/artiq/manual-master/ or in the online repositories referenced in the text below:

1. Precompilation of kernels in prepare phase

a. ISG requires a function to be added to ARTIQ that allows pre-compilation of an arbitrary experimental kernel (including a kernel that makes RPC calls when running on the core device) during the prepare() stage of the experimental pipeline. The pre-compiled kernel would then be sent to the core device for execution as normal once the run() stage is reached.

b. It is acceptable if the pre-compiled kernel is not allowed to be the main run() method of the Experiment, but that the main run() method is a regular Python method that calls the pre-compiled kernel.

c. The description of an “experimental kernel” above shall encompass a kernel that may consist of multiple kernel methods called by a single top-level kernel method called by the run() method.

d. If the pre-compiled kernel makes RPC calls, those shall not be executed before the kernel is running on the core device.

2. Distributed DMA

a. ISG requires the ability for DMA buffers recorded on the DRTIO master to be played back in a distributed and synchronized manner by DRTIO (distributed real-time input/output) satellites using their local memory. This will enable DMA playback without requiring the data to be streamed live over DRTIO.

b. This functionality must include the ability to automatically split a DMA buffer recorded on the DRTIO master into sub-buffers to be played back in parallel by the satellites, splitting according to the DRTIO channels used in the buffer DRTIO satellite owns those channels.

c. Distributed DMA buffers shall persist across kernels in the same manner that non-distributed DMA buffers currently persist across kernels.

d. ISG requires distributed DMA buffers to support both soft-processor and Zynq DRTIO masters and satellites and on DRTIO trees mixing both types of devices. Support for Zynq devices is conditional on completing support for DRTIO on Zynq devices, which is not a part of this contract.

https://m-labs.hk/artiq/manual-master/

3. Distributed processing on DRTIO (sub-kernels)

a. ISG requires the ability to start ARTIQ kernels (called sub-kernels) on remote processors down a DRTIO tree to increase the processing power of a DRTIO system. This is because the kernel running on the core device at the root of the DRTIO tree (root kernel) and all sub-kernels are executed in parallel.

b. Sub-kernels shall be written and compiled as separate kernel methods. There shall be no provision for automatic splitting of kernels into sub-kernels by the compiler.

c. A root kernel or sub-kernel takes exclusive control of the full DRTIO device subtree below it. Multiple layers of sub-kernels shall be allowed. Its DRTIO destination number shall designate the device executing a sub-kernel.

d. ISG requires the functionality to send and receive messages explicitly defined by the user between DRTIO nodes running kernels (including root kernel and sub-kernels). The ability to send and receive these messages shall be exposed to the user as an appropriate set of kernel methods. The messages shall be automatically routed across the DRTIO tree according to their specific destinations. The acceptable types of message data for these methods must include all the supported data types in artiq.language.types as of May 31, 2021. The user, and not the Contractor, shall be responsible for implementing any desired higher-level communication protocol.

e. ISG requires kernels (both root kernels and sub-kernels) to be able to wait for the termination of sub-kernels that they have started (“joining”). When a sub-kernel is joined, the objects from the upper-level kernel that the sub-kernel has used are copied back to the upper-level kernel. It is acceptable for this functionality to be provided with any other forms of synchronization or safety to guard against potential data corruption caused by multiple kernels modifying the same object of the upper-level kernel.

f. ISG requires sub-kernels to be able to record and playback DMA sequences, including distributed DMA sequences.

g. ISG requires RTIO monitoring and injection, as well as RTIO analyzer functionality for DRTIO devices running sub-kernels.

h. ISG requires the described sub-kernel functionalities in this section to support both soft-processor and Zynq DRTIO masters and satellites and on DRTIO trees mixing both types of devices. Support for Zynq devices is conditional on completing support for DRTIO on Zynq devices, which is not a part of this contract.

4. Shuttler gateware

a. ISG requires the implementation of ARTIQ integration as described below for Shuttler hardware, consisting of a Shuttler FMC card and a remote Shuttler analog front end (AFE) card, described at https://github.com/sinara-hw/Shuttler, and a suitable DRTIO-connectable (DRTIO satellite/master or via EEM from a DRTIO satellite/master) ARTIQ-integrated FMC carrier card such as the EEM-based FMC carrier described at https://github.com/sinara-hw/meta/issues/66. This work is conditional on the availability of suitable hardware, which is being developed separately from this contract.

b. The Contractor shall be responsible for purchasing such hardware for 4(a) as is required for implementation and testing of the capabilities in this section. The hardware must be available for public purchase and must be open-source for ISG to acquire (in a separate purchase or contract) identical hardware to the Contractor.

c. ISG requires software and gateware such that the Shuttler hardware can be used as a DRTIO-connected 16-channel DAC controllable from ARTIQ kernels.

d. The software and gateware shall enable waveforms to be output from all 16 Shuttler channels simultaneously at a sample rate equal to the RTIO clock frequency.

e. The waveform parameterization, possible durations of spline knots, and synthesis of sinusoids shall be as described in the code and documentation in the PDQ repository at https://github.com/m-labs/pdq/ as of May 31, 2021.

f. All digital calculations of final output waveform values shall be done as 16-bit numbers or larger, then rounded as appropriate for transmission to the DACs. Internal intermediate values in digital waveform calculations shall be https://github.com/sinara-hw/Shuttler https://github.com/sinara-hw/meta/issues/66 https://github.com/m-labs/pdq/

g. ARTIQ kernel methods must be provided to program desired waveforms in the wavesynth format used in the PDQ code to be output by Shuttler.

h. If sufficient FPGA resources are available on the FMC carrier card, the Contractor shall increase the number of DDS output tones available from the one in the PDQ design. The total output waveform shall be parameterized as a(t) + sum_i [b_i(t)*sin(c_i(t))], where a(t) and the b_i(t) are cubic splines and c_i(t) is a quadratic spline, and where i is maximized given the available FPGA resources.

i. Suppose sufficient FPGA resources are available on the GMC carrier card. In that case, the Contractor shall implement on-FPGA digital sigma-delta modulation for the digital output waveform to increase the effective bit depth at low frequency (below 10 kHz).

The sigma-delta modulation must not cause increased noise on the Shuttler output at frequencies below 15 MHz.

j. ISG requires digital gain and offset correction for the calculated waveform values immediately prior to being output to the DACs, on a per-channel basis, based on gain/offset register values stored on the FMC carrier FPGA. The default values of these shall be gain=1, offset=0 upon power-up, with suitable user kernel methods available to read and set the register values.

k. ISG also requires the following functionalities related to the Shuttler AFE card:

i. Readback of the output voltages at the AFE card using the onboard ADC. This functionality should be exposed to the user as an appropriate RTIO input kernel method, for example, as used for Sampler.

ii. Opening and closing of the relays/opto-isolators on the AFE card to isolate the AFE card analog output voltage connectors from the output amplifier stages and ADC. This functionality should be exposed as an RTIO digital output kernel method on a per-channel or bitwise per-AFE-card basis.

iii. Calibration routines use the AFE ADC to calibrate Shuttler output slope and offset errors by setting the DACs at zero, mid-scale, full-scale, or a user-defined list of digital values and measuring the voltage at the AFE ADC. This functionality is to be exposed as a suitable kernel method for DAC calibration.

This method must allow the option of opening or closing the relays/opto-isolators during the measurement.

iv. General kernel methods for full read/write access to all ADC registers for the

AFE ADC.

v. Explicit methods for placing the ADC in standby mode (with the clock turned off) or power-down mode and for returning the ADC from these modes.

5. Shuttler RAM mode with local SDRAM

a. ISG requires functionality so that pre-recorded waveform parameters (spline knots in the form of PDQ as described above) can be recorded in the Shuttler FMC carrier card’s local SDRAM memory, analogously to how they are currently recorded in block RAM for the PDQ gateware design, for later playback directly from local SDRAM on the Shuttler FMC. The mechanism may be similar to distributed DMA, or similar to the PDQ code’s frame triggering/switching design.

b. The waveforms parameterized and recorded in this manner shall have the option of being either single-channel waveforms or multi-channel waveforms. In the latter case, playback shall be enabled with a single method call rather than simultaneous (ARTIQ ‘with parallel’) calls for playback of single-channel waveforms.

c. The playback of a specific waveform at a specific time shall be exposed as appropriate user kernel methods.

d. Waveforms recorded in this manner shall persist until erased or until the FMC carrier card is power-cycled.

e. User kernel methods shall be provided to enable erasing of specific waveforms, as well as erasing of all stored pre-recorded waveforms.

ITEM 2 OPTION

1. ARTIQ maintenance on KC705 and ZC706

a. The Contractor shall maintain the KC705 and ZC706 ports, including support for the NIST “Clock and “QC2” hardware adapters, in the current version of ARTIQ for the duration of the contract.

b. To ensure the quality of the port, the Contractor shall run hardware-in-the-loop continuous integration tests on their own KC705, using the “Clock” hardware adapter, and on their own ZC706, using the “QC2” hardware adapter (or vice-versa, by mutual agreement between NIST and Contractor), at every modification of the ARTIQ code base, for the duration of the contract.

c. When any unit test fails on the KC705 or ZC706 within the contract period, the Contractor shall investigate the root cause and address the problem within a reasonable time.

d. No feature and no unit test that is supported on the KC705 board or the ZC706 board at the beginning of the contract shall be removed without prior approval from a NIST Contracting Officer for the duration of the contract.

e. Those features explicitly include conda packages for every ARTIQ release, for both 64-bit Linux and 64-bit Windows, and targeting both the “Clock” and “QC2” hardware adapters.

f. New features introduced into ARTIQ within the contract period shall also be supported on the KC705 and ZC706 whenever reasonable. This explicitly includes DRTIO support at whatever level of development is current, targeting both the “Clock” and “QC2” hardware adapters for both satellite and master modes and both KC705 and ZC706.

However, the aggregate working time that the Contractor spends porting such new features to the KC705 and ZC706 shall not exceed 40 hours per year.

SHIPPING AND DELIVERY

ITEMS 1 -5 shall not exceed September 30, 2022.

PERIOD OF PERFORMANCE

ITEM 2

Base 08/01/2021 07/31/2022 Option Year I 08/01/2022 07/31/2023 Option Year II 08/01/2023 07/31/2024 Option Year III 08/01/2024 07/31/2025 Option Year IV 08/01/2025 07/31/2026

ELECTRONIC MEDIA

Software to be open source and accessible on Github and as part of ARTIQ Conda packages.

WARRANTY

Base Manufacturer Warranty is acceptable.

INSPECTION AND ACCEPTANCE

Operation and testing of updated ARTIQ software with contracted DRTIO functionality to be carried out by NIST personnel on NIST hardware to verify satisfactory performance. The Government acceptance is expected up to 3 WEEKS. NIST personnel is subject to COVID-19 guidance and restrictions as applicable.