AXI Zmod ADC 1410 Buffer Size and Latency

[sfallekgt]

hi, I'm new to the forum - thanks in advance for the help. 

I'm curious about the AXI interface for the Zmod ADC 1410. The documentation states that a 16 kSample circular buffer stores data from the ADC and then writes to memory. Is it true that the data cannot be sent to DDR memory until the entire buffer is full? I'm curious if there is then a way to reduce the buffer size to provide smaller chunks of data to the PS at a faster rate.

Also, Im curious about the latency for this process (ADC capture + buffer storage + axi transfer to DDR + DMA access by PS) is known.

[artvvb]

Hi @sfallekgt

2 hours ago, sfallekgt said:

Is it true that the data cannot be sent to DDR memory until the entire buffer is full? I'm curious if there is then a way to reduce the buffer size to provide smaller chunks of data to the PS at a faster rate.

Yeah, the IP as-is (without modifications) can't forward data to DMA until the buffer is full. Alternate hardware designs that can stand in for the AXI IP could handle it though. It's most important to use the full 64 bits of the Zynq PS HP slave interfaces, by increasing the DMA's AXI master interface, and to increase the frequencies of the clocks the DMA runs at. Consider checking out this under-construction demo which dumps data into a DMA configured for scatter-gather at full speed (the sample rate claimed is 40 MS/s default but can be increased to 100 MS/s by changing ADC clock frequencies). For what it's worth, it's marked under construction primarily due to incomplete documentation and some general messiness on the AWG side.

2 hours ago, sfallekgt said:

Also, Im curious about the latency for this process (ADC capture + buffer storage + axi transfer to DDR + DMA access by PS) is known.

We haven't measured this. ADC capture and buffer storage both run very quickly. One sample per channel per clock cycle, the time it takes is effectively the actual time it takes to capture however long of a buffer you want, as it's all happening in PL and BRAMs. The AXI transfers managed by the DMA and the AXI lite transfers the PS uses to configure IPs in the PL all introduce some overhead - the former can be reduced by the aforementioned DMA throughput improvements. Latency through the data path from FPGA I/Os to the DMA is probably just a couple of clock cycles.

Hope this helps,

Arthur

[sfallekgt]

Hi Arthur, 

Thanks for your help here. I'm now digging into the ddr-streaming branch a bit more. 
I'm trying to generate a minimal example of sending multiple ADC captures over the serial comms link. 
For now, large delays are possible between the captures, but ultimately I would like to stream large contiguous samples.

I've been working from the s2mm_transfer software example, which I've re-written to take captures sequentially.
After the first capture, the device fails while waiting for the manual trigger (which I've issued from ManualTriggerIssueTrigger). 

Are there any particular commands/resets that need to executed between captures? 
Before a capture, I enable the trigger (TriggerSetEnable), invalidate the cache (Xil_DCacheInvalidateRange), start the trigger (TriggerStart) and reissue the manual trigger. 

Possibly related - I noticed S2mmCleanup is non-functional.

Thanks again.