Brute-force convolution reverb in FPGA

I'm completely new to the world of FPGAs, and would like to get a sense of what is possible to achieve, and since I happen to have an interest in convolution reverb algorithms, I will use that example.

So given a room response of 10 seconds (i.e ~500000 samples at 44.1kHz), is it realistic to expect that the FPGA could handle the brute-force algorithm (which is basically a FIR filter with 500000 coefficients, running at 44.1kHz, in double precision floating point)?

An fft-based implementation would need less multiplications / additions, but since it's more complex, I'd like to begin with a simple example first!

It would be nice if in your answers you could describe the FIR-filter implementation, and produce a back of the envelope calculation, with the numbers for a specific FPGA so that I can follow your reasonning.

Thank you very much!

• A FIR implementation is only noisier if you keep rounding when you shouldn't - something you can avoid in an FPGA if you wish.
– pipe
Nov 12 '18 at 9:33
• @pipe Thanks for pointing that out, do you mean that FPGAs can carry arithmetic operations with an arbitrary large number of bits? Also I edited my question to remove the part on noise. Nov 12 '18 at 9:45

A brute-force implementation of a 500,000-tap FIR filter @ 44.1 ksps requires about 22 G operations per second. Large FPGAs have hundreds of DSP units capable of doing a multiply-add in one clock, so the resulting clock frequency of a few hundred MHz is quite reasonable.

A slightly more interesting problem is managing the data. Let's be conservative and assume that a sample or a coefficient requires a 32-bit word for storage. That would require 32 Mbits of on-chip storage, which is rather a lot, except for the very largest (and most expensive) FPGAs.1

So, if we assume that you'll be using external memory, you'll need to read/write three words (96 bits) of data per DSP clock cycle in order to keep the DSPs busy. This is well within the capability of a DDR memory interface running at a reasonable speed. The larger Spartan 6 or Spartan 7 devices could easily handle this, and they have prices in the range of $100 -$150.

1 Just doing a quick check of the Xilinx Virtex Ultrascale line, the XCVU190 has enough on-chip resources to brute-force a 2 million tap FIR (1800 DSP slices, 132.9 Mb of on-chip memory). Unfortunately, this is a \$32,000 chip!

• Thanks for the detailed answer! I'm trying to guess what the 4 words are : am I right in guessing that in your design, the DSP block has 3 inputs (the filter coefficient, the signal, and an accumulator), and 1 output (the accumulator), so we have 2 reads from memory for feeding inputs (the coefficient and the accumulator) and then 1 write to report the result (the accumulator). So in total we have less than 128 bits read / writes (96 it seems), or do you count the signal as a read from memory? I was thinking that the signal could be read (transiently) from an IO pin instead? Nov 12 '18 at 15:44
• Yes, you're right. Only two reads and one write are required. I updated the answer to reflect this. Nov 12 '18 at 15:58

Let's think a bit about brute-forcing it.

A given sample will require at least 500,000 operations (unless you do some serious parallel unloading). You want to do this 44,100 times per second per channel. Multiplying the two together suggests a clock rate of 22 GHz.

You can draw your own conclusions.

• A largish FPGA can have hundreds of multipliers running in parallel, and this is a highly parallel problem. The resulting clock frequencies of 100s of MHz are quite reasonable. Nov 12 '18 at 13:32
• @WhatRoughBeast in your calculation, you assume that the FPGA will perform a single multiplication at every cycle. So your estimated clock rate is then very very very conservative, I would hope that it's possible to implement an FIR filter taking advantage of parallelizations on the FPGA. Nov 12 '18 at 13:52
• @DaveTweed - "(unless you do some serious parallel unloading)" Nov 12 '18 at 14:31
• I don't understand what you mean by that. See my answer. Nov 12 '18 at 14:40