FPGA Beginner question...would an FPGA have enough gates to perform this? - Page 1
Forum section: electronics / general

author: rsridhar
author_rank: Contributor
timestamp: March 26, 2021, 01:41:09 am
content: Hi All,Im new to FPGAs and just barely getting my first one (DE0 Nano) connected to an external ADC (having difficulties)...I guess Im deciding whether this is all worth it in the end.My real goal in exploring fpgas is to run a numerically intense algorithm in as many dimensions as possible.For a 1D case, it boils down to ~10k multiply and and add functions. Im running an ADC at ~10k-200kHz (the higher the better; 200k max). I want to complete these operation in one sample at the ADC frequency; to drive a DAC at the same frequency in realtime.On a DSP this timing can work. On newer C6000 DSPs, >1GHz with 8 logical units. But once I go to a 2D or greater; it gets incredibly complex and probably too much for a DSP. The algorithm increases at O(N^2) if N is the "dimension" - so a 2D case is 4x the computations; 3D case is is 9x the computations, etc.So once I get to 3D, running on a DSP in realtime is out of the question. But, ideally Id like to get to at least 6D; if not more.On the FPGA we arent templorally limited; but we are (eventually) limited by the number of transistors/logic units.N^2 x (~10000 multiply and add) functions?The data can be assumed to be fixed point on the fpga implementation.Is this still in the realm of possibility to be able to run N>=6 on an FPGA? Or is this an unrealistic amount computation to expect an fpga to be able to handle?Please tell me if my question is stupid as well - as I said I am new to hardware.Thanks and cheers

author: rstofer
author_rank: Super Contributor
timestamp: March 26, 2021, 02:40:02 am
content: I guess you have to look at the high end FPGAs and see how many multipliers they have. At the very high end, FPGAs are expensive. VERY expensive!Have you thought about using CUDA units in a graphics card (GPU):https://developer.nvidia.com/cuda-faqThen there is the NVIDIA Jetson family with a max of 512 GPU cores plus 64 Tensor cores (may not be helpful). It can do 32 teraflopshttps://www.nvidia.com/en-us/autonomous-machines/embedded-systems/I have no idea if any of these solutions are helpful. But it seems to me that we made it to the Moon with machines doing 1-3 megaflops and 32 teraflops seems like a lot. But they only go fast when the problem architecture matches the hardware architecture.You can get a 4GB Jetson Nano (472 gigaflops) for $99. That's about 238,000 times faster than a Control Data 6400 back in the '70s. If the architectures match.Here's a family overview for the Xilinx Virtex 7 devices. I don't see anything about multipliers but they do have the rest of the device specs plus links for more information.https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdfI'm pretty sure you have seen this but here is the DSP information:https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdfYou can get up to 3200 DSP slices in a Virtex7

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 02:46:36 am
content: Quote from: blueskull on March 26, 2021, 02:40:24 amQuote from: blueskull on March 26, 2021, 02:44:34 amWhat about VU29P?To OP: It can be done if you can tolerate some latency due to pipelining, but you will need a rather beefy FPGA, which won't be cheap.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 02:54:53 am
content: Quote from: blueskull on March 26, 2021, 02:54:11 amIt's not even close to being equivalent.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 03:10:28 am
content: Quote from: blueskull on March 26, 2021, 03:00:42 amThey won't, and it won't. At least not anytime soon.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 03:11:44 am
content: Quote from: blueskull on March 26, 2021, 02:54:11 amIt depends on the nature of algorithm. It might very well be much longer than that.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 03:30:08 am
content: Quote from: blueskull on March 26, 2021, 03:22:06 amIt will lead to massive stalls if there are data dependencies. Hence my statement that it depends on algorithm.Quote from: blueskull on March 26, 2021, 03:22:06 amAnd OP has clearly stated that he is not an FPGA designer.This thread is becoming a good test for reading comprehension...

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 03:32:18 am
content: You need DSP blocks for multiplications, not for addition. If ADC is 200k then a single 400 MHz multiplier can do 2k multiplications every cycle. So, for 10k case you only need 5 DSP blocks (provided you can organize them). Artix-200 has 740 DSP slices, which will be good for sqrt(740/5) = 12D. It's around $100 in China.<edit>If you need longer numbers, it'll be slower.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 03:37:57 am
content: Dsp tiles can do both multiplication and addition (hence the name). Also 7 series dsp tile can only do 18x25 macc/madd, so if you need higher precision (or, God forbid, a floating point operation), you will need more than one dsp per multiplication.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 04:04:47 am
content: As I understood the OP, the point here is as much to gain some practical experience with FPGAs as it is to actually complete the project.Also doing Dsp on general purpose CPUs has it's own challenges and pitfalls.

author: rsridhar
author_rank: Contributor
timestamp: March 26, 2021, 06:01:06 am
content: Wow this thread blew up! Well, a lot of greek to me, but Im trying to learn.Regarding what Im doingIm a mechanical/electrical engineer, the algorithm in question is essentially a filter for vibration analysis/control.Im also a bit of a geek, and am eager to learn to use FPGAs which I feel are my next foray into electrical engineering. So my goals are two fold here, to learn to use FPGAs and to actually get this algorithm working. The algorithm is something Ive been conceptualizing for a few years; simple signal processing theory but very computationally intense.Im used to embedded systems; hence my natural gravitation towards DSPs and FPGAs. My first goal is to do a proof of concept - for a 1D or 2D case (As long as I know it can expand to 6+!).Regarding the algorithm, delays, and data dependencies:The algorithm is simple multiply and sum. Just a lot of them. The foundation of signal processing.For the multiplies - there is no data dependency. As soon as we get a sample (@200kHz) from the ADC, we have all the coefficients we need to multiply.There is a data dependency on the summation - it is the results of all the multiplications that need to be summed together.A few cycles of delay in the MHz range - no problem. But once you get a few cycles of delay in the kHz range can lead to mechanical instability.I knows delays are inevitable in a digital system; and the more pipeline delay I have, the lower the frequency the algorithm will be stable at. Ive already got some delays from the Sig/Del ADCs Im planning on using. If in the end the algorithm is only good to 50Hz, then so be it. But I would like it to be useful to a few kHz at least; ideally.Regarding Using a GPU/CPU/Other Hardware:Ill admit first, that this is probably waay beyond my area of comfort here.Admittedly, I think me getting a proof-of-concept here would be impossible for me if working on anything other than a DSP or FPGA. Using multiple DSPs would be...tough; coding the algorithm would be simple; but data routing would be a nightmare and the #DSPs required wouldnt scale well with the algorithm's O(N^2)If it is only possible (or a lot easier for an actual hardware engineer) to implement on another device - be it a GPU, CPU, or anything else - that advice is also welcome. If that is the case, I probably wouldn't take that on. But, I would love to hear it if you think its the case.The other reason I would strongly prefer a hardware solution is that it must keep up realtime. Keeping up realtime and eliminating pipeline delays are the name of the game here - which is why I instantly thought FPGA - I can interface with the ADC/DAC and perform the computaions on the same chip.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 01:21:05 pm
content: Quote from: asmi on March 26, 2021, 03:37:57 amYes, but you can do addition in the fabric just as fast, so if the number of DSPs is a limiting factor, you don't need DSPs for addition.Or, as in OP's case, if you need to do MAC, you do not need extra DSPs for addition as the same DSP does both.Therefore, when calculating the DSP resources needed, you only count the multiplications.

author: SMB784
author_rank: Frequent Contributor
timestamp: March 26, 2021, 01:23:46 pm
content: Quote from: NorthGuy on March 26, 2021, 01:21:05 pmAre you sure that's true? I recognize that you can indeed to addition with fabric or DSPs, but I'm not convinced that the fabric is as fast as the DSPs are. Isn't the whole point of DSPs to offload MACC operations from the fabric so they can be done at extremely high speed & throughput? What evidence is there to demonstrate that the fabric is just as fast as the DSPs are?

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 01:34:38 pm
content: Quote from: NorthGuy on March 26, 2021, 01:21:05 pmIn 7 series DSP tiles addition and multiplication are performed by a separate parts of DSP tile, so you can do both at the same time as a single macc/madd operation.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 01:41:23 pm
content: Quote from: rsridhar on March 26, 2021, 06:01:06 amThe delay depends on how much calculations you need to do which depends on the last ADC reading. In case of a FIR filter, this is only one MAC you need to get from the last ADC reading to the final result. Otherwise, the MAC operations are easily distributed, so you can get decent latency.Quote from: rsridhar on March 26, 2021, 06:01:06 amI wouldn't expect routing problems in this application. You typically get routing problems when you use a big portion (70% or more) of all FPGA resources.Once you use all the cycles of all the DSPs, the only way to increase N is to slow the ADC down. What values of N in "O(N^2)" do you need?

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 01:48:59 pm
content: Quote from: SMB784 on March 26, 2021, 01:23:46 pmIf you do MAC, the DSP block will do both addition and multiplication for you. So, you don't save anything by moving addition to the fabric for MAC.However, if you have some other pattern, you can do addition in the fabric. DSP roughly works at 400 MHz. Create a project which does addition in the fabric. See if it can run at 400 MHz. This will be the evidence you're seeking.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 01:57:38 pm
content: Quote from: rsridhar on March 26, 2021, 06:01:06 amThis is not how it works - in FPGAs everything is happening in parallel. Please don't confuse latency with throughput. In fully pipelined system you will get a result every cycle, and it will consume an input value every cycle. Think of it as a conveyor belt-driven assembly line - on every tact(tick, clock cycle) it accepts an input and "returns" an end product - this is throughput (1 item per tick), but it takes a certain amount of time for the specific input item to reach output - this is latency.So you can have both high latency and high throughput at the same time, in fact in most cases if you want higher throughput, you will have to live with increased latency. A nice thing about FPGA designs is that these factors - latency, throughput, resource utilization can be adjusted with (relatively) little effort to find the optimal solution for each specific use case.It's hard to wrap your head around this coming from writing code for CPUs, where everything tends to happen sequentially, but you will need to understand this concept intuitively to be successful with FPGA designs.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 02:00:48 pm
content: Quote from: NorthGuy on March 26, 2021, 01:48:59 pmIf you use all pipeline registers of the DSP tile (and you really should), you can run it at full 550 Mhz for 7 series speed grade 2 without much trouble.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 02:04:38 pm
content: Quote from: rsridhar on March 26, 2021, 06:01:06 amYou might want to try out HLS, like Vitis HLS. It can "convert" an algorithm written on C/C++ into a logic core that you can integrate into FPGA design. Take a look at these videos:https://www.youtube.com/playlist?list=PLo7bVbJhQ6qzK6ELKCm8H_WEzzcr5YXHCThey are a bit dated, but I think he explains all concepts you need to know very well.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 02:20:28 pm
content: Quote from: asmi on March 26, 2021, 02:00:48 pmEven at 550 MHz, you can pipeline additons in the fabric to match the DSP speed.If you want to save DSPs, it is insane to use DSPs to do addition only. If you want to figure out how many DSPs you need to do a given calculation, you only count multiplications. All the additions can be either consumed by the MACs or pushed to the fabric.When the OP says 10k multiplications and additions. If it's 1k multiplications and 9k additions, the design may be done with far fewer DSPs than if there were 9k multiplications and 1k of additions.OP is doing MACs, most likely a simple FIR filter, so I would take it's 5k multiplications and 5k additions, that is 5k MACs. Thus, to evaluate how many DSPs he needs, we need to consider 5k multiplications.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 02:46:43 pm
content: Quote from: NorthGuy on March 26, 2021, 02:20:28 pmHe mentioned that algorithm is using macc, so no need for any fabric additions.At these frequencies the typical problem is feeding DSP tiles with enough data, as general purpose fabric can not run that fast. This often requires creative solutions, like utilizing BRAM as FSM to drive control signals for time-multiplexed use cases, or sacrificing a single DSP tile for a super-fast counter to drive the sequencing, etc.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 03:52:11 pm
content: Quote from: asmi on March 26, 2021, 02:46:43 pmSure, but he mentioned this after the discussion about additions started.Quote from: asmi on March 26, 2021, 02:46:43 pmBRAM will probably not run at 550 MHz anyway. So, if you're using BRAM for FSM or if you're doing FIR and want to draw the coefficients from BRAM, you will have to slow it down to the BRAM speed.

author: rsridhar
author_rank: Contributor
timestamp: March 26, 2021, 06:18:06 pm
content: Yes, this is esentially an NxN matrix of FIR filters; with filter length ~10k.@asmi, yes, Im familiar with fpga functionality vs processors - thats what has drawn me to them for this application; that all the computations are done in parallel.So getting back to the quesiton at hand...Assuming all the data is fixed point; and all the math is fixed point; it sounds like an fpga could handle this number of computations? 6x6x10000 MAC's?Is 10x10x10000 MACCs out of the question?Am I not even close to reaching the limits of the FPGA?Regarding the memory...Would I need external memory for this many operations?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 26, 2021, 06:57:33 pm
content: Although I'm not sure what the OP is really trying to achieve, I suspect this may be a case of XY problem.

author: asmi
author_rank: Super Contributor
timestamp: March 26, 2021, 07:08:35 pm
content: Quote from: rsridhar on March 26, 2021, 06:18:06 pmNothing is out of the question, but as was mentioned above, you will require progressively more beefier FPGAs, and it will get more and more expensive. There are FPGAs out there which cost over US$100K for a single chip.Quote from: rsridhar on March 26, 2021, 06:18:06 pmIt depends on what you want to do. All FPGAs have some amount of internal memory, which is good enough for stuff like FIFO buffers to smooth out data flow in case your source is not constant flow, or as a scratch memory. In your case, if you take samples directly from ADC and then output them directly into DAC (and their sampling rate is the same), you probably won't need any external memory. Some DSP effects (like delay and feedback in case of audio effects) might require more memory than what's available on-chip, and it might be required if your FPGA is going to have some auxiliary functions - like small CPU softcore which will orchestrate the entire design - stuff like configuring ADC/DAC at startup, responding to user input, etc. Again, it all depends on your design.--------One cool thing about FPGAs is that they can be simulated and their behavior can be verified without having actual hardware. So what I would recommend you to do is to get IDE from the vendor of your choice, and try actually implementing a design and verifying it in simulation. It will answer a lot of your questions, and you will get a better idea as to which FPGAs you will actually require.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 07:53:15 pm
content: Quote from: rsridhar on March 26, 2021, 06:18:06 pm10k is an awfully long FIR filter.You can easily calculate this, but you need to know how many bits you need per a single coefficient and how many bits you need for an accumulator.For each FIR filter, you need to maintain 10k of accumulators. If an accumulator is 20 bits its 200k bits - 6 BRAM blocks. Every ADC clock you need to fetch every one of these, multiply the most recent ADC reading by an appropriate coefficient, add it to the value you have read and store it back into the next slot. If you don't have enough BRAM you will need to organize a pipeline which will read from the external RAM then write it back, but if you have 5 DSPs working on this, it's 100 bits read and 100 bits write every DSP cycle, which you probably won't be able to achieve with external RAM.You will also need space for the coefficients. For example, 10bit x 10k = 100k bits another 3 BRAM blocks.What is easy about the FPGA, once you build one FIR filter, all of the others will be the same. So, N x N matrix is just N^2 identical filters which use N^2 identical sets of resources.If one FIR filter takes 5 DSPs and 9 BRAM blocks, then for 10 x 10 = 100 FIR filters you'll need 500 DSP and 900 BRAM blocks. These are very aproximate estimates though.As FPGAs are built, BRAM will be more of a problem than DSP.Using a big FPGA to fit all filters may net be a good idea. Say if you want 100 FIR filters, XC7K480T has 955 BRAM blocks and 1920 DSPs and costs few $k.It may be more beneficial to use a number of smaller FPGAs. Say, XC7A200T has 365 BRAM blocks and 740 DSPs, which might be enough for 40 FIR filters.

author: NorthGuy
author_rank: Super Contributor
timestamp: March 26, 2021, 08:14:46 pm
content: Perhaps you can make better use of external memory if you process your filter multiple taps at a time. Say you can accumulate 200 taps then adjust data in your external memory. Such approach uses less internal memory and requires less external memory bandwidth.

author: hamster_nz
author_rank: Super Contributor
timestamp: March 26, 2021, 10:58:56 pm
content: I quickly sketched a design on paper. The big problem will be the storage for the FIR filter's kernel - As I have to assume that each filter uses a unique set of coefficients.Most FPGAs have a block memory that is tightly coupled to the DSP block, that is somewhere about 1k entries in size. This makes filters of up to this length very fast and efficient, but longer ones much less so.A DSP operations at about 200MHz or so without extra-careful design. That will allow a single DSP block to 200kS/s, with 1000 length filter kernel. To make longer filters you need to use 'n' partial filters, each with 1/nth of the kernel in parallel, then total the output outside of the DSP block.For thirty six 10k-long FIR filters, you will need 360 DSP blocks to process 200k samples per second. And of course, because you can only process the data after it has been acquired you will have latency a little over 5000 samples (1/40th of a second) - this is assuming you are using FIR filters with '5000 values in the past, and 5000 values in the future'.In Xilinx world, an XC7A100T with 240 DSP slices is too small, and a XC7A200T with 740 DSP slices is about twice what you need. However, if you could halve the length of your filter length to 5k then XC7A100T would be plenty, and you would halve the overall latency too.I would want to write the core of the design and work out the achievable timing before selection of part or even thinking of the board design. It is far cheaper to change a dropdown in the EDA tools than get a new FPGA board.

author: rstofer
author_rank: Super Contributor
timestamp: March 27, 2021, 12:34:16 am
content: Quote from: hamster_nz on March 26, 2021, 10:58:56 pmRight! Pick a large device and start writing code. Once the code is complete, reduce the device size until it no longer fits.I haven't played with the DSP tiles but I checked with Google and apparently the simulator works. So the project can be tested up through working simulation before selecting the final chip.Search: "xilinx vivado simulate dsp devices"

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: March 27, 2021, 06:12:25 am
content: QuoteI love gray marketwhat part numbers of Ultrascales are popular there?

author: ebclr
author_rank: Super Contributor
timestamp: March 27, 2021, 06:43:39 am
content: Like this one ?https://item.taobao.com/item.htm?spm=a230r.1.14.8.41bf223esJwTBm&id=608706046387&ns=1&abbucket=5#detail

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: March 28, 2021, 05:25:05 am
content: QuoteThanks for sharing

author: gnuarm
author_rank: Super Contributor
timestamp: March 28, 2021, 06:43:53 pm
content: Quote from: NorthGuy on March 26, 2021, 01:48:59 pmFlexibility. Using the adders in the MAC limit you to the configuration provided. Using the adders from the fabric remove restrictions and make porting to other architectures much easier.