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 :)
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.
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
http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/t...
- 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
FWIW most modern FPGAs use discrete DSPs anyway so you're not really getting the flexibility at that level.
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.
Also there's a ton of SRAM for the 4-LUT configuration so you're paying leakage costs there as well.
NVidia managed to get it right about year and half ago. Before that their gates leaked power all over the place.
The LUTs on Stratix are 6-to-2, with specialized adders, they aren't at all that 4-LUTs you are describing here.
All in all, there are places where FPGAs can beat ASICs. One example is complex algorithms like, say, ticker correlations. These are done using dedicated memory (thus aren't all that CPU friendly - caches aren't enough) and logic and change often enough to make use of ASIC moot.
Another example is parsing network traffic (deep packet inspection). The algorithms in this field utilize memory in interesting ways (compute lot of different statistics for a packet and then compute KL divergence between reference model and your result to see the actual packet type - histograms created in random manner and then scanned linearly, all in parallel). GPUs and/or CPUs just do not have that functionality.
(I don't know if you can publicly get Stratix 10 devkits yet, but you can get an Arria at least.)
On the DSP side, you're using a ASIC DSP(can't change the width for instance) anyway on most modern FPGAs so you're comparing ASIC to ASIC at that point.
Of course you can get better price/GFLOP with GPUs + quicker time to market
GPUs have very particular cache and computation hierarchy which is not necessarily a best/good fit for all problems that are being thrown at them.
You can fuse more operations into DSP using FPGA and/or you can perform less operations per FLOP. One example is to avoid rounding and packing/unpacking when creating deep pipelines for floating point processes.
For open source hardware I doubt you'll see people shell out the cost of a used car to be able to match modern ~$200 GPUs.
I don't even what to know what Stratix 10 starts at.
This was admittedly a space certified radiation hardened chip. Still alarming when you had to pick it up and carry it somewhere
The Xeon Phi board https://www.cnet.com/products/intel-xeon-phi-coprocessor-712... is $4.2K..$5K
The Stratix V board will not consume more than 60W when used as PCI Express card. The requirements for Xeon Phi is at least 250W.
With a difference of ~200W, there will be difference in ~4.5kW/h per day or ~1600kW/h or $160 in hard cash per year (US average). Very probably more - getting rid of heat produced, etc.
Just being a SoC has another advantage: reduced part count, so you can fit more functionality onto a smaller PCBA.
Another commenter mentioned the Cyclone V and Zynq SoCs. My day job is in the telco industry. The equipment vendors we sell to are always pushing for higher and higher densities in their chassis and line cards, and it drives a lot of our design decisions. Chips like the Cyclone V and Zynq help a lot in achieving those aims. Our PCBAs have shrunk dramatically (with increasing functionality) over the last decade.
The continual pressure to reduce costs and power consumption also leads to choices like minimizing the other available system resources (e.g. clocks, memory bandwidth, RAM, flash), which can end up reducing the effectiveness of a GPU.
As with everything in engineering, there are many different problem domains, each with unique constraints dictating different solutions.
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?
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...
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.
I recall there was a lot of excitement around the Pynq. Has anything notable been done with it yet?
Certain industries (esp nuclear) really like them because they can "prove" the set of attainable states in the FPGA.
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...
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.
HFT
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..
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.