Raw DC data reading and writing on ZCU111 using qick

[zhizhenzhong]

Hey folks,
I'm trying to use the qick package to drive an optical setup. For part of my calibration procedure I need to be able to source raw numpy waveforms out of a DAC (no RF mixing) and measure the result on an ADC (again, no RF mixing/up or down converting).

I was hoping that this would be straightforward to do with the qick package and you folks could help me do it.
Best,
-Zhizhen

[meeg]

Yes, this is being done by various groups - some AMO and some flux-controlled superconducting qubits. There is a hardware part and a software part to this.

Hardware: the balun-coupled DAC and ADC channels will not work, since baluns don't pass DC signals. You will need to use channels with differential inputs/outputs (on the ZCU111 adapter board that means picking the appropriate channels) and connect DC-coupled differential amplifiers to them. LMH5401 is a good option, available as a connectorized evaluation board that can be configured for differential-to-single-ended (for DAC) and vice versa (for ADC). For the ADC side you will need to supply a common-mode voltage - look at the documentation for the ADC analog input in https://docs.xilinx.com/r/en-US/pg269-rf-data-converter/RF-ADC-Analog-Input, you will see that for the ZCU111 you should use 1.2 V.

Software: You should be able to use the outsel='input' parameter to set_pulse_registers() to drive your numpy waveforms without an RF carrier. Similarly you should be able to use sel='input' for declare_readout on the ADC side. There are other ways to do this (e.g. setting the frequency to 0) but this is the most direct.

• https://qick-docs.readthedocs.io/en/latest/_autosummary/qick.qick_asm.html#qick.qick_asm.QickProgram.declare_readout
• https://qick-docs.readthedocs.io/en/latest/_autosummary/qick.qick_asm.html#qick.qick_asm.QickProgram.set_pulse_registers

[zhizhenzhong]

Thanks @meeg for the prompt response. By "picking the appropriate channels", do you mean we have to use ADC226 (tile 2) / 227 (tile 3) and DAC228 (tile 0) because only them give differential signal. I see ADC tile 2 and 3 are not initially connect to the default qick ZCU111 image so that come back to the problem of I need to change the block design to support these ADC tiles?

[meeg]

Yes, that's correct.

[zhizhenzhong]

Hi @meeg, i would like to follow up on this thread:
For the DC-coupled ADC, as you pointed I read from the https://docs.xilinx.com/r/en-US/pg269-rf-data-converter/RF-ADC-Analog-Input that ADC common-mode voltage is 1.2V. So I put a 1.2V voltage to the LMH5401 VCM ports. There allows me to read ADC, but with ADC readout value drift changes at the tens-of-seconds level.

Then, I also find some Xilinx documents and discussions (https://support.xilinx.com/s/question/0D52E00006hpLKoSAM/rfsoc-adc-vcm-buffer?language=en_US) saying that we should put the FPGA's ADC VCM pin back to bias the ADC and they indicate it to be 1.25V. Because the ZCU111 board does not connect the FPGA's VCM pin, I assume we have to use external bias, to be 1.2V or 1.25V? Any insights or comments here? what is a good external bias (to replace the VCM from the FPGA because ZCU111 does not enable them)?

[meeg]

Correct, the ZCU111 balun board does not break out the VCM pin. That is why you need to pick a voltage instead of letting the ADC tell the LMH5401 what voltage it wants. I agree that there seems to be a conflict which I hadn't noticed between Xilinx docs DS926 (which says 1.25 V) and PG269 (which says 1.2 V) - no doubt these are just typical values and cannot be guaranteed. Other groups we've talked to (@jacobfeder, @sarafs1926?) have been using 1.2 V.

The ADC input is differential, so ideally it only measures the difference between its inputs and is not sensitive to changes in the common-mode voltage. Of course nothing is ideal, and I don't think Xilinx gives a spec for common-mode rejection. That said - how much drift are you seeing, what is your requirement, and how did you come to the conclusion that the common-mode voltage is responsible?

[meeg]

I think this question was more or less answered, but please feel free to reopen if you want to continue this topic.