6 ms·

Do FPGAs have a future beyond "prototyping non-memory intensive algorithms for eventual ASIC implementation"? It seems to me that the scale out + scale up meth

Do FPGAs have a future beyond "prototyping non-memory intensive algorithms for eventual ASIC implementation"? It seems to me that the scale out + scale up method of x86 and GPUs are the most promising and profitable arenas still, besides some very niche and very particular applications? I could and would like to be wrong. I'd go learn FPGA dev then if there were things that needed accelerating and were personally lucrative to me :)

syntheticnature 10y ago
Sometimes they're good for "need ASIC-like results in a low-volume design" but that's more a special case of what you give, and of course the 'upgradable glue logic' case also is in play. I think the killer application would be to have programatically reconfigurable FPGAs that reconfigure on the fly to fit the needs, which has been discussed in various overhyped ways in the past, but I don't think the tooling is there. This effort might or might not make that possible -- imagine a chip where, say, the regex you're going to use to scan 1GB of data could be turned into an FPGA and then it just shovels the whole thing through a "HW" FIFO that detects matches much faster than a processor could. Nifty... but is it worth the effort to do?
- pdelbarba 10y ago
  You can kind of do this now if you want. The SOCs like the Cyclone V or Zinq have an arm core or two surrounded by FPGA fabric. The only barrier right now would be the dynamic reloading of the FPGA which I haven't seen done, but would be simple in principle (as opposed to having a soft core that would likely have it's state interrupted if you re-flashed everything)
  - aseipp 10y ago
    Most newer Intel (Cyclone and beyond) and Xilinx (-7 series) support various levels of partial logic reconfiguration. If you plan your device layout right, you can simply reprogram a region of fabric that is hardwired wired to the 'shell' of your system (which is connected to the peripherials). If you have setups like Vivado's SDSoC/high-level synthesis, you can do things like dynamically reconfigure OpenCL kernels, etc. Of course, the problem is synthesis, verification, testing etc is all rather difficult in practice and takes a long time. The boards themselves also can't do synthesis/compilation, obviously, since they're fairly limited and it's a time-consuming process. You'd have to make it act more like an OTA update system, but that comes with a lot of its own problems...
- gibrown 10y ago
  This is what I've used them for. Low volume design as in thousands of chips a year rather than millions. Or cases where reprogrammability greatly improves the ability to provide fixes and improvements in the field as a part of very expensive support contracts.
- ne9xt 10y ago
  this is possible today. check out the digilent pynq ( www.pynq.io ). i just bought a dev board, i'm pumped to try a few things out.
  - trapperkeeper79 10y ago
    I really wanted to get that board - but the price difference between academic and regular users was a bit too much given this was coming out of my own pocket (I ended up buying used FPGA dev boards from ebay, etc.). I recall there was a lot of excitement around the Pynq. Has anything notable been done with it yet?
PhaseLockk 10y ago
FPGAs are a useful means of accelerating any algorithm where you want more performance than you would get from executing it on a CPU, but can't afford to create your own ASIC because the volume is relatively low. For example, it may be used in DSP applications for things like radar. This use as a reprogrammable accelerator is also why Amazon has introduced instances with on-board FPGAs to AWS.
- pdelbarba 10y ago
  Also worth noting that for real time control you can't beat the speed. Essentially, everything you do on an FPGA happens at the same time. You could see a 1000 line Verilog file that completes a huge operation in a handful of cycles.
  - 0xcde4c3db 10y ago
    Also note that "speed" includes latency, and not just low latency but also deterministic. You can do things like adjust a timestamp or tweak a control equation knowing that a sample has been delayed through an N-stage pipeline/filter that advances at M hertz.
    - pdelbarba 10y ago
      Yea, I misspoke there. %s/speed/latency/ Certain industries (esp nuclear) really like them because they can "prove" the set of attainable states in the FPGA.
  - thesz 10y ago
    Exactly. There is an algorithm for detecting bursts of unusual activity which is extremely well suited for FPGAs: http://www.cs.nyu.edu/cs/faculty/shasha/papers/burst.d/burst.pdf http://www.cs.nyu.edu/cs/faculty/shasha/papers/burst.d/burst... Basically it is a tree of registers with checks. It can compute burst position and duration in the O(log(window size)) time (clocks). You look here at 2.5..5ns (200MHz..400MHz) multiplied by log2(window size) - 25..50 ns for window with 1024 samples. You just cannot get that kind of connectivity with CPU/GPU. Processing these samples in CPU will get you into several hundreds of ns, if not more.
lvoudour 10y ago
They've grown beyond prototyping a long time ago. They are full featured SoCs with great flexibility that fill niches where CPUs, GPUs, ASICs can't compete in flexibility/power consumption/development cost. - ASICs are too rigid and require high volumes to be profitable - GPUs are too power hungry - CPUs are not good for massively parallel processing FPGAs are heavily used in industrial/military/aerospace applications
- vvanders 10y ago
  If you think GPUs are too power hungry then you're in for a shock with FPGAs. Switching FPGAs are incredibly power hungry since they run on much larger processes. FWIW most modern FPGAs use discrete DSPs anyway so you're not really getting the flexibility at that level.
  - PhaseLockk 10y ago
    > Switching FPGAs are incredibly power hungry since they run on much larger processes. I don't think the comment about process is really true, from what I can tell, Xilinx is only a few months behind the biggest SoC makers in terms of its process adoption, and is shipping 14nm parts currently. Not sure about Altera, but they are on Intel's process, which is bit ahead of the competitors anyway. In terms of switching power, you definitely pay a penalty to have the reconfigurability in hardware, but on the other hand you don't have all the unused logic that you would on a GPU. I'd guess the comparative efficiency depends on the specific problem and specific implementation, but I don't have any numbers to back that up.
    - vvanders 10y ago
      It's a couple things, process is a large part. You're also dealing with 4-LUT instead of transistors so you pay both in switching power and leakage since you can't get the same logic-to-transisitor density that's available on ASICs. Also there's a ton of SRAM for the 4-LUT configuration so you're paying leakage costs there as well.
      - deleted 10y ago
pbh101 10y ago
>I'd go learn FPGA dev then if there were things that needed accelerating and were personally lucrative to me HFT
alain94040 10y ago
They are better than GPUs at machine learning inference, so there's that. Ask those guys for some benchmark results, you'll be impressed: http://mipsology.com http://mipsology.com
- deleted 10y ago
  [deleted]
Matthias247 10y ago
They for sure have a future. But imho the main usage scenario for FPGAs is not the acceleration of things which are otherwise run on CPUs and GPUS. I think one of the main values of FPGAs when you need custom hardware/"glue" between other chips, because you e.g. need to connection 30 I²S connections to your application processor or need to handle multiple video streams with different formats for which no custom IC exists. That's for sure niche applications, but lots of these products reach 6digits of sales. The other usecase is when you need superhard-realtime behavior, which means things should work exactly synchronously to a hardware clock. E.g. I used it back at university for radar systems, but there are also lots of applications around telecomms, networking and audio/video processing and transmission. These are often low to medium volume products, where custom ASICs are not lucrative or updateability is required. Afaik custom ASICs also got more expensive over time through higher process costs, so you need a higher volume to justify it instead of going for FPGAs.
- throwayedidqo 10y ago
  Ah someone that's actually used them eh :) ? My experience is the same. People have this impression that they're being used for all this exciting stuff when the average FPGA is because you need some multiplexing on IO lines and you're not running a RTOS. Basically using them in place of what would be software if your micro was better suited to your application
- wycx 10y ago
  and here is an example of exactly that sort of application: http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/tuppc069.pdf http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/t...
vidarh 10y ago
Heat (and as a result: size), power generation and cost. There are plenty of problems where, sure, you could get an x86 or a powerful GPU and do it faster, but you'll be paying for it with power usage. E.g. take [1] - they're making a modern M68k compatible CPU in an FPGA. They're getting performance that's beating ASIC ColdFire CPUs (Motorola/Freescale's M68k descendant) and ASIC PPCs with several times the clock, and beating the fastest "real" M68k systems by a factor of 3x-10x. You could beat that with a software emulator on a powerful enough x86, sure. Easily. Especially if investing enough time in dynamic translation and the like. But this thing instead fits on a far less power hungry FPGA that gives off far less heat, and fits on a board that'll fit in one of the real small case Amiga's - try to do that with a x86 with heat sink.. [1] http://www.apollo-core.com/ http://www.apollo-core.com/
- makomk 10y ago
  The Apollo core only has a market because Amiga fans are willing to pay a premium in price, complexity, heat and reduced performance to use something other than ARM or x86. I wouldn't be surprised if software emulation on a low-power, cheap ARM core could beat it; JIT on a powerful x86 is apparently 5-7x faster. It's also the exact opposite of open source, being a proprietary core tied to a single-source commercial boards.
  - vidarh 10y ago
    > The Apollo core only has a market because Amiga fans are willing to pay a premium in price, complexity, heat and reduced performance to use something other than ARM or x86. Heat? Really? A modern x86 with a heatsink won't physically fit in the cases these boards go in. To be viable these cards must run cooler than the alternatives - that's part of the point. > I wouldn't be surprised if software emulation on a low-power, cheap ARM core could beat it; JIT on a powerful x86 is apparently 5-7x faster. The current boards are kept cheap - they're nowhere near using the fastest available FPGAs, and the cores keep making massive performance leaps iteration to iteration and have been tested and works on FPGAs more than twice as fast as the ones on the current Vampire boards. The publicly released cards are now beating ASIC PPC cores clocked 7x as fast on some benchmarks. If JIT on a powerful x86 is only 5-7x faster now, odds are they'll be able to reach parity with the UAE JIT soon. > It's also the exact opposite of open source, being a proprietary core tied to a single-source commercial boards. Which is entirely irrelevant to the point I was making.

syntheticnature 10y ago

Sometimes they're good for "need ASIC-like results in a low-volume design" but that's more a special case of what you give, and of course the 'upgradable glue logic' case also is in play. I think the killer application would be to have programatically reconfigurable FPGAs that reconfigure on the fly to fit the needs, which has been discussed in various overhyped ways in the past, but I don't think the tooling is there. This effort might or might not make that possible -- imagine a chip where, say, the regex you're going to use to scan 1GB of data could be turned into an FPGA and then it just shovels the whole thing through a "HW" FIFO that detects matches much faster than a processor could. Nifty... but is it worth the effort to do?

pdelbarba 10y ago
You can kind of do this now if you want. The SOCs like the Cyclone V or Zinq have an arm core or two surrounded by FPGA fabric. The only barrier right now would be the dynamic reloading of the FPGA which I haven't seen done, but would be simple in principle (as opposed to having a soft core that would likely have it's state interrupted if you re-flashed everything)
- aseipp 10y ago
  Most newer Intel (Cyclone and beyond) and Xilinx (-7 series) support various levels of partial logic reconfiguration. If you plan your device layout right, you can simply reprogram a region of fabric that is hardwired wired to the 'shell' of your system (which is connected to the peripherials). If you have setups like Vivado's SDSoC/high-level synthesis, you can do things like dynamically reconfigure OpenCL kernels, etc. Of course, the problem is synthesis, verification, testing etc is all rather difficult in practice and takes a long time. The boards themselves also can't do synthesis/compilation, obviously, since they're fairly limited and it's a time-consuming process. You'd have to make it act more like an OTA update system, but that comes with a lot of its own problems...
gibrown 10y ago
This is what I've used them for. Low volume design as in thousands of chips a year rather than millions. Or cases where reprogrammability greatly improves the ability to provide fixes and improvements in the field as a part of very expensive support contracts.
ne9xt 10y ago
this is possible today. check out the digilent pynq ( www.pynq.io ). i just bought a dev board, i'm pumped to try a few things out.
- trapperkeeper79 10y ago
  I really wanted to get that board - but the price difference between academic and regular users was a bit too much given this was coming out of my own pocket (I ended up buying used FPGA dev boards from ebay, etc.). I recall there was a lot of excitement around the Pynq. Has anything notable been done with it yet?

PhaseLockk 10y ago

FPGAs are a useful means of accelerating any algorithm where you want more performance than you would get from executing it on a CPU, but can't afford to create your own ASIC because the volume is relatively low. For example, it may be used in DSP applications for things like radar. This use as a reprogrammable accelerator is also why Amazon has introduced instances with on-board FPGAs to AWS.

pdelbarba 10y ago
Also worth noting that for real time control you can't beat the speed. Essentially, everything you do on an FPGA happens at the same time. You could see a 1000 line Verilog file that completes a huge operation in a handful of cycles.
- 0xcde4c3db 10y ago
  Also note that "speed" includes latency, and not just low latency but also deterministic. You can do things like adjust a timestamp or tweak a control equation knowing that a sample has been delayed through an N-stage pipeline/filter that advances at M hertz.
  - pdelbarba 10y ago
    Yea, I misspoke there. %s/speed/latency/ Certain industries (esp nuclear) really like them because they can "prove" the set of attainable states in the FPGA.
- thesz 10y ago
  Exactly. There is an algorithm for detecting bursts of unusual activity which is extremely well suited for FPGAs: http://www.cs.nyu.edu/cs/faculty/shasha/papers/burst.d/burst.pdf http://www.cs.nyu.edu/cs/faculty/shasha/papers/burst.d/burst... Basically it is a tree of registers with checks. It can compute burst position and duration in the O(log(window size)) time (clocks). You look here at 2.5..5ns (200MHz..400MHz) multiplied by log2(window size) - 25..50 ns for window with 1024 samples. You just cannot get that kind of connectivity with CPU/GPU. Processing these samples in CPU will get you into several hundreds of ns, if not more.

lvoudour 10y ago

They've grown beyond prototyping a long time ago. They are full featured SoCs with great flexibility that fill niches where CPUs, GPUs, ASICs can't compete in flexibility/power consumption/development cost. - ASICs are too rigid and require high volumes to be profitable - GPUs are too power hungry - CPUs are not good for massively parallel processing FPGAs are heavily used in industrial/military/aerospace applications

vvanders 10y ago
If you think GPUs are too power hungry then you're in for a shock with FPGAs. Switching FPGAs are incredibly power hungry since they run on much larger processes. FWIW most modern FPGAs use discrete DSPs anyway so you're not really getting the flexibility at that level.
- PhaseLockk 10y ago
  > Switching FPGAs are incredibly power hungry since they run on much larger processes. I don't think the comment about process is really true, from what I can tell, Xilinx is only a few months behind the biggest SoC makers in terms of its process adoption, and is shipping 14nm parts currently. Not sure about Altera, but they are on Intel's process, which is bit ahead of the competitors anyway. In terms of switching power, you definitely pay a penalty to have the reconfigurability in hardware, but on the other hand you don't have all the unused logic that you would on a GPU. I'd guess the comparative efficiency depends on the specific problem and specific implementation, but I don't have any numbers to back that up.
  - vvanders 10y ago
    It's a couple things, process is a large part. You're also dealing with 4-LUT instead of transistors so you pay both in switching power and leakage since you can't get the same logic-to-transisitor density that's available on ASICs. Also there's a ton of SRAM for the 4-LUT configuration so you're paying leakage costs there as well.
    - deleted 10y ago

pbh101 10y ago

>I'd go learn FPGA dev then if there were things that needed accelerating and were personally lucrative to me HFT

alain94040 10y ago

They are better than GPUs at machine learning inference, so there's that. Ask those guys for some benchmark results, you'll be impressed: http://mipsology.com http://mipsology.com

deleted 10y ago
[deleted]

Matthias247 10y ago

They for sure have a future. But imho the main usage scenario for FPGAs is not the acceleration of things which are otherwise run on CPUs and GPUS. I think one of the main values of FPGAs when you need custom hardware/"glue" between other chips, because you e.g. need to connection 30 I²S connections to your application processor or need to handle multiple video streams with different formats for which no custom IC exists. That's for sure niche applications, but lots of these products reach 6digits of sales. The other usecase is when you need superhard-realtime behavior, which means things should work exactly synchronously to a hardware clock. E.g. I used it back at university for radar systems, but there are also lots of applications around telecomms, networking and audio/video processing and transmission. These are often low to medium volume products, where custom ASICs are not lucrative or updateability is required. Afaik custom ASICs also got more expensive over time through higher process costs, so you need a higher volume to justify it instead of going for FPGAs.

throwayedidqo 10y ago
Ah someone that's actually used them eh :) ? My experience is the same. People have this impression that they're being used for all this exciting stuff when the average FPGA is because you need some multiplexing on IO lines and you're not running a RTOS. Basically using them in place of what would be software if your micro was better suited to your application
wycx 10y ago
and here is an example of exactly that sort of application: http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/tuppc069.pdf http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/t...

vidarh 10y ago

Heat (and as a result: size), power generation and cost. There are plenty of problems where, sure, you could get an x86 or a powerful GPU and do it faster, but you'll be paying for it with power usage. E.g. take [1] - they're making a modern M68k compatible CPU in an FPGA. They're getting performance that's beating ASIC ColdFire CPUs (Motorola/Freescale's M68k descendant) and ASIC PPCs with several times the clock, and beating the fastest "real" M68k systems by a factor of 3x-10x. You could beat that with a software emulator on a powerful enough x86, sure. Easily. Especially if investing enough time in dynamic translation and the like. But this thing instead fits on a far less power hungry FPGA that gives off far less heat, and fits on a board that'll fit in one of the real small case Amiga's - try to do that with a x86 with heat sink.. [1] http://www.apollo-core.com/ http://www.apollo-core.com/

makomk 10y ago
The Apollo core only has a market because Amiga fans are willing to pay a premium in price, complexity, heat and reduced performance to use something other than ARM or x86. I wouldn't be surprised if software emulation on a low-power, cheap ARM core could beat it; JIT on a powerful x86 is apparently 5-7x faster. It's also the exact opposite of open source, being a proprietary core tied to a single-source commercial boards.
- vidarh 10y ago
  > The Apollo core only has a market because Amiga fans are willing to pay a premium in price, complexity, heat and reduced performance to use something other than ARM or x86. Heat? Really? A modern x86 with a heatsink won't physically fit in the cases these boards go in. To be viable these cards must run cooler than the alternatives - that's part of the point. > I wouldn't be surprised if software emulation on a low-power, cheap ARM core could beat it; JIT on a powerful x86 is apparently 5-7x faster. The current boards are kept cheap - they're nowhere near using the fastest available FPGAs, and the cores keep making massive performance leaps iteration to iteration and have been tested and works on FPGAs more than twice as fast as the ones on the current Vampire boards. The publicly released cards are now beating ASIC PPC cores clocked 7x as fast on some benchmarks. If JIT on a powerful x86 is only 5-7x faster now, odds are they'll be able to reach parity with the UAE JIT soon. > It's also the exact opposite of open source, being a proprietary core tied to a single-source commercial boards. Which is entirely irrelevant to the point I was making.