3 ms·

Caveat on 3): The only real benefit of an FPGA for algorithms is when you're algorithm benefits from parallelization. There is nothing intrinsically faster in

Caveat on 3): The only real benefit of an FPGA for algorithms is when you're algorithm benefits from parallelization. There is nothing intrinsically faster in programmable logic. The point is that execution is truly concurrent, as long as you have space in the FPGA fabric, you can _almost_ do everything at the same time. I say this as someone who has done a fair share of FPGA projects, it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU. Regardless of whatever you read, FPGA's do have a purpose but will most likely continue to only be used in niche/custom applications.

balefrost 5y ago
There is nothing intrinsically faster in programmable logic. It probably depends what you're comparing to. Yeah, since FPGAs essentially implement combinatorial logic, and hard CPUs are also implemented in combinatorial logic, you gain no benefit from directly "porting" the hard CPU to the FPGA. But, if your hard CPU is a microcontroller that can only process say 8 bits at a time, but you really want to process say 256 bits at a time, it might be more efficient to use an FPGA to build a soft CPU whose architecture better matches your problem. In that case, you should be able to do more work per clock cycle with the FPGA. That's arguably "increased parallelization", but what I'm talking about applies to sequential algorithms. Of course, in that case, maybe you chose the wrong microcontroller. Maybe a full CPU would be a better choice, or maybe there's a DSP that can be adapted to the specific use case. it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU Sure, that makes a lot of sense at the high end. I'm thinking of problems more in the embedded space, where FPGAs might be a bit more attractive.

balefrost 5y ago

There is nothing intrinsically faster in programmable logic. It probably depends what you're comparing to. Yeah, since FPGAs essentially implement combinatorial logic, and hard CPUs are also implemented in combinatorial logic, you gain no benefit from directly "porting" the hard CPU to the FPGA. But, if your hard CPU is a microcontroller that can only process say 8 bits at a time, but you really want to process say 256 bits at a time, it might be more efficient to use an FPGA to build a soft CPU whose architecture better matches your problem. In that case, you should be able to do more work per clock cycle with the FPGA. That's arguably "increased parallelization", but what I'm talking about applies to sequential algorithms. Of course, in that case, maybe you chose the wrong microcontroller. Maybe a full CPU would be a better choice, or maybe there's a DSP that can be adapted to the specific use case. it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU Sure, that makes a lot of sense at the high end. I'm thinking of problems more in the embedded space, where FPGAs might be a bit more attractive.