How to post various register updates from FPGA to CPU?

Question

I hope this is not too broad a question, I try to be as specific as I can. I am using a Zynq SoC with FPGA and CPU. I am using the FPGA for a lot of DSP, that depends on many register values. In most of the operation, the CPU code issues register changes, which works in a (I think) usual way:

• Various parts of the CPU code issue variable length instructions which are sent in packed form through a DMA FIFO to the FPGA.
• The FPGA has an operation decoder, which dispatches the CPU instructions to the respective registers as they come in
• The FPGA decoder needs no buffering (other than the FIFO itself), no arbitration and can run at a fixed clock rate, making it rather simple

^{simulate this circuit – Schematic created using CircuitLab}

Now my question is about the other way:

Various parts of the DSP can cause irregular register value changes in the FPGA registers. Such updates could occur maximum 1000 times per second under regular operation conditions, usually much more rarely. Now I am not very experienced with such things, but I would like to set up some efficient and scalable method inside the FPGA to push these updates to the CPU. What I have at the moment is described below.

• The FPGA constantly monitors all interesting register value and detects value changes. There are ~100 such interesting registers.
• These value changes are flagged and issued for transmission to the CPU. I.e. several changes might be detected in a single clock cycle.
• Only one update is sent out each clock cycle via a FIFO. To realize (or rather avoid) arbitration, they are explicitly ordered by priority.
• If many updates occur simultaneously, the most important ones will be transmitted first. If important updates arrive extremely frequently, unimportant ones may be significantly delayed (which is acceptable).
• Another issue is a long decision chain (N-1 steps for N registers), to decide which register update to transmit

My feeling is that this is clunky and not very scalable, especially when there will be very many monitored registers. So I am wondering what the "professional" approach was to such a task

Answer 1

There are many approaches, the best to be determined by your requirements (for example, total throughput and allowable latency).

With low throughput and relaxed latency requirements, it may be enough for the CPU to poll the "interesting" FPGA registers at a specified interval. For lower latency, the FPGA can generate an interrupt signal to notify the CPU that something interesting happened so it can re-read the interesting registers. If only some values change, a status register can indicate which parts have changed, so the CPU only needs to read those.

For higher throughput, DMA is used to transfer data in bulk from the FPGA into main memory where it can be read and processed by the CPU. The usual workflow here is...

1. CPU driver allocates DMA buffers and fills out descriptors containing the memory addresses and sizes, and makes these available to the FPGA.

2. When something interesting happens, a DMA transfer is initiated to copy the new data into memory. Descriptors are updated to indicate which DMA buffer(s) have new data.

3. The CPU is then notified that new DMA data is available.

4. The CPU then reads and processes this data, and updates the descriptors to indicate the buffers are available again for the FPGA.

Depending on the architecture, the DMA can be done by the FPGA itself, or by a DMA controller in the SoC.

This is the most scalable approach, but is overkill for very low data rates: the overhead of the DMA interactions can be higher than simply polling registers. This is why you need to carefully analyze your requirements to pick the best solution.