What are the possible strategies to transfer data from an FPGA accelerator to a hard-core CPU?

Question

I am beginning with FPGAs and I am working on an accelerator that acquires data from a microphone (Pulse Density Modulation) and extracts a single frequency from the signal.

My accelerator is basically a digital filter, that multiplies each audio sample with a complex phasor and adds everything together. After n samples it should produce a complex number (representing phase and amplitude of a given frequency) and make it available to a CPU somehow.

My question is: what is the best/simplest strategy to transfer data from the FPGA to the CPU?

---

Note the following:

1. I am using a Zynq UltraScale+ MPSoC from Xilinx (more precisely the zu3eg), and CPU and FPGA are on the same physical chip.
2. My accelerator is an AXI slave that should be programmed and started by the CPU
3. I need to transfer approximately 240 KB/sec from the FPGA to the CPU

---

The possibilities I could think of are:

• Create a sort of FIFO within my accelerator: use some registers to store the last m results and signal the CPU with an interrupt when this output buffer is getting full. The data would be read by the CPU through the AXI interface.
• Use an external FIFO: use one of VIVADO modules to implement a FIFO between my accelerator and the CPU. I guess this forces me to implement an AXI master interface on my accelerator?
• Write the results in the FPGA's BRAM in a circular buffer

Could you explain what are the best design patterns for this type of problem? As I said I am rather new to FPGAs and it would be great to have some advice from someone with more experience. Any pointer to good references would also be greatly appreciated

Thanks a lot!!

Answer 1

Xilinx offers reference drivers, and I think by now even some of the AXI infrastructure is in the upstream linux kernel. Other companies (ADI for example) have publicly available Linux images for RFSoC devices, that should easily port to MPSoC as well.

Since you're streaming data, a usual approach would be using a DMA controller to write into the DDR Ram that the ARM core also accesses.

You could raise an interrupt whenever a buffer is ready (that's pretty much the way PCI sound cards work) and then handle that in software. But considering audio rates are incredibly low from a modern CPU's point of view, software-polling a status register might work just as well and reduce the interrupt overhead if you have so many channels that you can always be sure that one is done.

Note that I'm assuming this targets a massive-multi-channel thing, or something requiring an impressive convolution length, or is to learn how to build such a system (not necessarily actually build that system); audio-rate convolution is really hard for normal PC-style processors. That's why I recommend "large data volume" techniques instead of "oh yeah, that rate is low enough you can directly MMIO-query that in a software loop".