I've got AD9081+ZCU102 booting a fresh Kuiper Linux. I was experiencing random gaps of zeros with "DAC Buffer Output" in IIO Oscilloscope because of memory bandwidth (which I think I've fixed). I also am having several other confusing issues when using pyadi-iio.
I've mostly focused on:
1. The slow, 4 complex-channel BOOT/zynqmp-zcu102-rev10-ad9081/m8_l4 and
2. The fast, 2 complex-channel BOOT/zynqmp-zcu102-rev10-ad9081/m4_l8 examples.
It looks like I can make "DAC Buffer Output" work without gaps in IIO Oscilloscope by doing one of the following three, presumably equivalent things:
1. Running the command `iio_attr -u ip:analog.local -D axi-ad9081-tx-hpc pl_ddr_fifo_enable 1`
2. In IIO Oscilloscope, going to the Debug tab for Device axi-ad9081-tx-hpc, in the IIO Device Attributes, setting debugfs property pl_ddr_fifo_enable to 1.
3. Running the following python code, either before I run IIO Oscilloscope or off to the side while it's running:
import adi
dev = adi.ad9081("ip:analog.local")
dev.tx_ddr_offload = 1 # Enable BRAM offload in FPGA (Necessary for high rates)This code was inspired by the example github.com/.../ad9081_dma_example.py
Now for my barrage of related questions:
Is there a more obvious way to do this from within IIO Oscilloscope or to tell that a buffer was being under-run? The default behavior with gaps caused confusion and lost time at bring-up.
Is there a way to use pyadi-iio to query whether there are DAC gaps due to buffers being under full without looking at a loop-back cable?
Is there a way to determine the BRAM size from witin IIO Oscilloscope or pyadi-iio? If not, what is the size? From another answer, it look like dac_fifo_samples_per_converter=64*1024 from
github.com/.../system_bd.tcl
But can I choose to use the entire BRAM for one channel? Can I then choose to use half for two channels? Or is there a fixed size allocated for each channel, and it's 64k complex samples?
When I load a file through IIO Oscilloscope's "DAC Buffer Output", is there feedback as to whether it "fit"? Same with dev.tx()?
When I query pyadi-iio's dev.tx_cyclic_buffer while IIO Oscilloscope is doing its "DAC Buffer Output" thing, I get False. Shouldn't this be true while it's running? Does tx_cyclic_buffer correspond to some iio_attr? In general, it's not at all obvious which pieces of state are kept in the python object, which are kept in the kernel's debugfs, and which are queried each time from the underlying hardware.
Finally, I get some buggy pyadi-iio behavior from the fast 2-channel m4_l8 example. For half of the items that I can query and set, it acts like there is only one tx channel:
tx_dac_en==[1] # versus [1, 1, 1, 1] for m8_l4
tx_main_nco_frequencies==[100000000] # versus [1000000000, 1100000000, 1200000000, 1300000000] for m8_l4
I don't know if this is a device tree issue, a pyadi-iio issue, or some other configuration issue. This means that within pyadi-iio for the m4_l8 example, I can not turn on and off channel 2, nor can I set its tx_main_nco_frequencies.
I'm using a fresh 2021_r2 image_2023-04-02-ADI-Kuiper-full.img. I had many of the same issues with 2021_r1, though I didn't investigate it as systematically before I upgraded to a fresh install.
I'm using pyadi-iio 0.0.15 on my laptop. I use 0.0.14 on the ZCU102, which comes with Kuiper Linux 2021_r2.
I've attached a screenshot of loading the sinewave_0.3.mat example with loopback SMA cables.
Thanks,
Jason