Estimating FPGA size from number of constants stored - Page 1
Forum section: electronics / general

author: zigunov
author_rank: Contributor
timestamp: April 16, 2025, 09:12:24 pm
content: Hello, all,I'm looking into an application (I'm honestly not even sure if I want an FPGA but here we are...) where I want to perform a series of large matrix multiplications on a data stream from multiple sensors for closed-loop control. Say, for example, I have 20 sensors in the input of the FPGA, each with its own ADC, operating at rates of, say, 100kSps. I pick a sample from each ADC in parallel, store it in a register in the FPGA, and then perform a calculation. The calculation then is outputted to a series of DAC's also wired in parallel in the output pins of the FPGA and operating at the same rate. Let's say I don't want to introduce a latency much more than 1 or 2 samples from this calculation.At this point I'm trying to figure out whether FPGA's are even advantageous for this type of real time matrix multiplication. Say I need to multiply a 512x20 matrix by the 20x1 input vector to get a 512x1 result. Then I apply some lookup table function to this result vector; and compress it again by multiplying it again by a 20x512 matrix to get an output vector that I can output to the DAC. This operation will require 512x20x2=20480 constants in the FPGA in order to do this operation as parallelized as possible. The constants would likely need to be 16-bit or more in size to ensure the calculation is not too inaccurate.How many LUTs would that really require? How can I estimate that? I estimated the time required to download the data from the SDRAM in the FPGA I have and it is too slow to perform this computation by downloading the constants one by one; so I am figuring I will need to store all constants right on the FPGA.Is that even feasible? Will this many constants create a massive routing issue (potentially)? Maybe you can share your experience on whether this is even something reasonable to do?Thanks!

author: hamster_nz
author_rank: Super Contributor
timestamp: April 16, 2025, 10:55:07 pm
content: Data arrives at 100kSps - A reasonable FPGA can run at 200MHz, so that gives up to 2000 cycles to do work between samplesTo multiple a 512x20 by a 20x1 matrix. Easiest implementation would be to take 512 cycles, and multiply 20 terms per cycle (e.g. use 20 or 40 DSP blocks depending on the data widths involved). An adder tree and the output function a few cycles - say 550 cycles (2.2us @ 200Mhz, 5.5us @ 100MHz) of latency. It would require each DSP block to be coupled with a memory block to hold the 512 values - 36x512 is a pretty standard size for a block RAM (even if you are not using all bits), and 20 of these will be needed - so 368,640 bits of memoryAny current FPGA will have plenty of resources for this.e.g. Artix 7 50T has 90 DSP slices and 1800,000 bits of block RAM - this would be around 40% utilization.Edit: I missed the output side of the calculation. You will most likely be able to use the same DSP slices, with a small state machine to control operations - either that or multiple resources usage by 2.

author: zigunov
author_rank: Contributor
timestamp: April 17, 2025, 02:35:55 pm
content: Thanks for your answer but maybe I didn't get what is the actual calculation you did. I have a Cyclone V and they specify their FPGAs in LUTs, not DSP blocks or block RAMs. What is the conversion rate?What is the calculation you did? Is it 36x512x20 = 368,640? But why 36? I mentioned the constants would be 16 bits, not 36 bits? Why is it 40% utilization when 368,640/1,800,000 = 0.2048?Explain like I'm 5!

author: BrianHG
author_rank: Super Contributor
timestamp: April 17, 2025, 03:41:14 pm
content: Quote from: zigunov on April 17, 2025, 02:35:55 pmWhich Cyclone V?Yes, in both the Cyclone V data brief and data sheet, they do specify the number and type of DSP blocks and memory blocks and memory block size in bits.Read up here:https://www.intel.com/content/www/us/en/content-details/714207/cyclone-v-fpga-and-soc-fpga-product-table.htmlEach DSP block, depending on fpga type, can do either 18x18 bit multiply, or, 36x36 bit multiply. This means if you hardwire/code a 16bit by 16it multiply, it will consume one complete DSP module 18x18bit, ignoring the extra 4 bits. If your were to hardwire a 24x24 bit multiply, it would consume a 36x36 bit DSP.Each DSP can continuously multiply your 2 source numbers at ~200Mhz assuming you can continuously feed them nonstop.Each DSP module in order to achieve that 200MHz speed may have a pipeline delay on the output to help achieve that maximum clock. This may mean when you configure one to multiply 2x18 bit integers, the actual result comes out 2 clocks later. i.e. Feed a stream of 200 million multiplies a second going in, the answer going out is delayed by 2 clocks. Or, if you were doing floating-point, this pipeline delay might be something like 5 or 6 clock delay. You need to take this into account if you need to re-multiply a result coming out with another number coming in immediately without any clock delay. (This also means running that 18x18 bit integer DSP at ~80MHz could shrink that 2 clock pipeline delay down to 1 clock...)As for the blockram, these are usually organized as 10kbit for the Cyclone V series. Some limitations exist in their bit-width and size. What this usually means is if you allocate an odd size block smaller than the divisible 10kbit, additional memory blocks may be used as wasted space.Logic elements are called 'LE'. They are specified in K because it is easier to read in the thousands than listing a huge number down to a point..DSP blocks are called 18x18 bit multiply. (If you were to do a 36x36 bit multiply, it would just consume multiple 18x18 cells.)Floating point DSP blocks are called 'Variable-precision DSP blocks'. (These may also be used as integer 36x36 multipliers.)'M10K memory (Kb)' is the number of dual-port ram memory bits available to you, but, I would play it safe and use the 'M10K memory blocks' and count that as available Kilobytes of ram.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 17, 2025, 04:11:36 pm
content: Sounds like something you could maybe do on one or more DSPs.Unless there is a need to combine data from multiple channels then multiple DSPs may be a simple option

author: BrianHG
author_rank: Super Contributor
timestamp: April 17, 2025, 04:17:16 pm
content: 512x20x2=2048020480 * 16 = 327680 bits of ram, or, 40960 bytes or ram, or rounded to 48kbytes or ram.Each M10k block is 1 kilobyte, ie 8 bit ram, so, you need 48 M10k blocks for your project.The smallest Cyclone V already has 176 M10k blocks, so, you are good.Even Altera's/Intel's smallest Max10 will do it, though I would go up one size.And the Max10 can run from a single 3.3v supply and does not need a boot prom as it is internal.Also, if your data is only 100k/sample per second, then you can run a single 18x18 multiplier at 100MHz, allowing 1000x the multiplies per sample. i.e., real-time 1000 channels of 100khz ADCs/DACs using one multiplier at 100mhz. Of, use multiple multipliers for multiple computations of 1000 channels.You only have 20 sensors, I think the smallest Cyclone V will run circles around what you need.Also, write a test-bench and simulate your IO and code. This will prove your functionality and allow you to test compile your design in multiple FPGAs before even building a PCB or ordering a single part. This is the way. Code in an open standard language like System Verilog and you will be able to test compile your design into other manufacturers FPGA as well such as Xilinx.

author: BrianHG
author_rank: Super Contributor
timestamp: April 17, 2025, 04:57:53 pm
content: Also, serial loading 20 channels of 16 bit data will cost you 320 LEs. Again another 20 outputs means another 320 LEs. If you have 16bit stage of math results inbetween look up tabled multiply to perform an add or subtract, it may only be 16LEs since you are using 1 table to compute multiple multiple sensors in series.So, we are at 656 logic elements, not even 1K LE. But, there will be more to it than that, so I would at least triple this figure to something like 3k LE.The smallest CycloneV has 25k LE, so, you are safe, especially since the Cyclone V also has dedicated additional dedicated logic-less registers for serial/parallel shifting data meaning your first 656 required logic elements wont even use any logic elements at all, it would be pushed into the 37k-25kLE = 12k data only registers available to you in the smallest Cyclone V. (Each LE is also considered / contains a register bit, so when the data sheet says 37k, they are also counting the normal LEs which contain the LUTs in this figure. The Max10 doesn't contain these extra non-LUT register bits, so, your 656 bits which hold the incoming and outgoing samples would consume the register bits in the Max10's LEs.)

author: laugensalm
author_rank: Regular Contributor
timestamp: April 19, 2025, 02:40:05 pm
content: Sounds like a classic Kalman filter scenario to me that is certainly doable in smaller size FPGAs with some pipelining.However, your latency requirements sound very optimistic. On the FPGA, system clock latencies won't matter much, so you can reduce multiplier costs by pipelines, but you will need a very fast ADC, you might want to look into matching SAR or delta-sigma low latency technologies. An FPGA will make it easier to start processing early, i.e. when the first say four bits have arrived at the serial interface, you can start the pipeline, whereas a classical DSP will at least buffer a word before being able to process, let aside all kinds of polling/DMA issues that may introduce jitter.All resource versus system clock related stuff you can try out in a 'dry dock' using free FPGA tools and then extrapolate from that.Or give it a first try with a RedPitaya, I believe their ADCs should be good enough.

author: BrianHG
author_rank: Super Contributor
timestamp: April 19, 2025, 06:23:09 pm
content: Quote from: laugensalm on April 19, 2025, 02:40:05 pmA little advanced for the OP, but yes, you are correct. Also, parallel ADCs and DACs exist, but usually the good serial ones will allow higher than sample rate serial load and unload mimicking a parallel interface.I would 100% simulate everything in Modelsim (available integration for almost all FPGA vendors) before doing anything on any device at all.