Understanding Underflow Errors in Record DMA calls

Guest

I was reading https://m-labs.hk/artiq/manual-legacy/getting_started_core.html and saw this: Pulse sequences that are too fast for the CPU (i.e. would cause RTIO underflows) can still be generated using DMA, which made me question my understanding of underflow errors and the process flow of ARTIQ programs.

I am trying to make sure I understand how underflow errors occur. My understanding is that without dma recording a really fast pulse sequence, we can get underflow because the ARTIQ microprocessor takes a while to load a given pulse sequence to be ready to be put on the FPGA. If the pulse sequence is too fast, the microprocessor could at some point run a command to prepare an FPGA voltage value at some timestep that has already been passed by the FPGA clock.

For DMA sequences which are cached pulse sequences, meaning the sequence is preloaded onto the FPGA, my guess is that when calling self.core_dma.playback_handle(pulses_handle), the cached pulse sequence may not be loaded all on one step to the FPGA. So if the pulse sequence is too fast, this would mean that the FPGA clock could reach the unloaded timesteps before the microprocessor finishes writing the rest of the cached sequence to the FPGA. And especially if you do playback many times, the FPGA clock could eventually surpass the microprocessor clock.

It could be that I have some misconception about how ARTIQ works as well?

occheung

Guest If the pulse sequence is too fast, the microprocessor could at some point run a command to prepare an FPGA voltage value at some timestep that has already been passed by the FPGA clock.

Yes. Slack goes negative, and you get RTIOUnderflow, with or without DMA.

Guest the cached pulse sequence may not be loaded all on one step to the FPGA

This is the time cost for loading the sequence to the RTIO engine.
It always take some time to submit RTIO events to the engine. In general:

It scales with the length of your sequence;
DMA makes this process faster.

There are some hardware-in-the-loop tests estimating these numbers

test_pulse_rate for non-DMA sequence
test_dma_playback_rate for DMA sequence

So RTIOUnderflow tends to happen when the RTIO event submission rate < RTIO event consumption rate (slack eventually goes negative). All DMA does is to lower the RTIO event submission rate by caching the sequence in advance.

To relate to your terminologies:

RTIO event consumption rate is proportional to pulse sequence rate.
RTIO event submission rate is the time needed to load a fraction of your pulse sequence.

Guest And especially if you do playback many times, the FPGA clock could eventually surpass the microprocessor clock.

In addition, when you perform a DMA playback, there is an overhead cost before/after playing a sequence.
It is for the CPU to ask the DMA engine to fetch the desired sequence, instruct the DMA engine to start/stop, restoring RTIO event submission via DMA/non-DMA means, etc.

test_dma_playback_overhead measures this number.