The big problem is software people thinking that they have any concept of actual hardware design.
If they understood hardware, they would understand that an FPGA is the least efficient way to accomplish anything.
Routing is sparser than any chip. You burn 10-100x the transistors to do the same task. FPGA's are hot and slow.
Even for signal processing, an FPGA is going to be quite hard pressed to beat a 2.0GHz ARM with Neon extensions unless it is very expensive and your algorithm is very dataflow oriented. How many ARM's can I put on a board for $10,000-$100,000 (the very highest end FPGA's)?
You use an FPGA because you have a low-volume application that you can't do any other way, and your application has enough margin that you can eat the cost of the FPGA. And you are always looking to wipe out that FPGA and replace it with a microprocessor because it is so much cheaper and easier to deal with.
"FPGA's are hot and slow" - compared to a full custom IC? Sure. FPGA's improve with every process generation (like all silicon devices) and an ASIC design won't intrinsically take advantage of those advances; an FPGA design that didn't meet it's power or thermal envelope 5 years ago might easily do so now, without incurring the NRE of the ASIC - add to that the fact that the first stage of the ASIC design can be prototyped via the FPGA, and you have a viable product without the risk of a bad ASIC.
I've been involved in converting several Virtex-2 designs to newer devices - the huge reduction in power and increase in available logic has led to some extremely impressive gains. There is work to do in such a conversion, but it is understood work - there's no real mystery to updating the CoreGen components.
Agree it is a useless article though, because digital logic design is not programming (it is architectural work). There is no 'abstracting' that away - all attempts thus far have failed miserably (Vivado HLS, for example, turns out designs that work but are HUGE compared to what even a passable designer can do).
While hardware design often has awkward constraints that make generalised abstractions tricky, there is still a lot that can be done to improve over Verilog or VHDL. I've been working in Bluespec for a couple of years now, and the difference is night and day. Having a modern type system in our HDL makes experimentation and iteration so much easier.
And reading about these projects, one gets the impression chisel was critical for them.
[1]https://chisel.eecs.berkeley.edu/chisel-dac2012.pdf
[2]http://www.eetimes.com/document.asp?doc_id=1324759
[3]http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=654588...
And that's it. That is the ONLY place where an FPGA makes sense--"I'd like to have an ASIC, but I can't afford the NRE."
There is no technological axis in which an FPGA is superior to anything.
It looks to me like a typical situation of legacy tools and some degree of oligopoly. I imagine a hardware person going into programming would have a similar experience (in reverse).
In fact, if you know of ANY general purpose hardware that will talk to gigasample ADCs/DACs, I'd love to know about it.
The only thing an FPGA wins on is NRE (non-recurring engineering).
The real problem is that the giga-sample DAC's/ADC's aren't willing to speak one of the actual high-speed interfaces or put a DSP directly on the ADC/DAC. So, everybody needs to use an FPGA to shoehorn the data into a useful form.
If somebody put an actual DSP on their ADC/DAC, FPGA's would evaporate for this application like they have evaporated for so many others.
Any FPGA application with volume eventually gets subsumed by special purpose hardware on a microcontroller. For example, people used to use FPGA's for PWM, motor control, etc. Now those blocks are standard on microcontrollers.
I fail to understand why using a HDL for a digital ASIC is fine, but using one for a FPGA in the context of acceleration is not.
It's like compiling against a binary library, except that the binary isn't another piece of software, it's an etched pattern on your FPGA's wafer. Even if you did have the "source code" it wouldn't do you any good unless you have a foundry in your backyard :-)
I'm skeptical of the calls for a higher level of abstraction. How are you going to abstract away the fact that the FPGA has exactly 2 embedded memory controllers that have precisely A, B, and C inputs and X, Y, and Z outputs? Either you come up with a solution that's effectively just as ugly as what we have now (because it exposes the FPGA's resources explicitly) or you come up with a solution that hides these details and as a result becomes enormously fragile because it's easy to accidentally change something that prevents the compiler from inferring which embedded ASIC chunk you meant to use. You need to be aware of limitations to work within them, and the limitations seem to be stuck with us for the foreseeable future.
The same thing we do every time, Pinky: assume the existence of a sufficiently advanced compiler. ;)
Designing a fast processor is very expensive, far beyond the means of the research community. The only way anyone can afford it is to sell millions of the things to gamers. To put $1 of special hardware on your numerical card, we have to put it on 1000 graphics cards too, so you'd have to pay $1000 for it. Bad luck: scientists are destined to hack hardware that was designed for larger markets.
Good luck: You get the perfomance of what was considered a supercomputer little over two decades ago, by hacking a consumer-technology product.
But what I cannot get from this article is what is exactly wrong with the current FPGAs design? They've got DSP slices (i.e., ALU macros), they've got block RAMs and all the routing facilities one can imagine. For the dataflow stuff it's more than enough.
Of course it would have been much better if the vendors published the detailed datasheets for all the available cells and the interconnect, for the bitfile formats, etc. - to make it possible for the alternative, open source toolchains to appear. Yes, their existing toolchains are, well, clumsy. But it is still quite possible to abstract away from the peculiarities of these toolchains.
I hoped the author would expand on this point.
It is also my impression that GPGPU are just "a hack": they should had been normal coprocessors to the main CPU, just like the FPU and the vector units are. It seems that now we are finally reaching that model (in Linux the graphics device is almost completely separated from the computational device, although they are on the same physical device most of the time) but we are still far from the "Comprocessor extension" opcode space of MIPS processors or to the "brain and arms" of CELL (1 generic CPU, many specialized coprocessors).
