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 is the least efficient way to accomplish anything"
Define 'efficient'. If you're talking about cost, it costs far less than an asic below a certain volume, and it certainly costs less in tooling and development.
"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.
You can still abstract lots of it. For example chisel[1] does so through high level abstractions and parametrized generators - while still offering results equal to verilog.It's also also used for the open source risc-V architecture[4], the recent highly-efficient parallel cpu[2] done by a small start-up(2 guys),and a floating-point alu generator[3] that explores the design space of fpu's and finds optimal designs.
And reading about these projects, one gets the impression chisel was critical for them.
He is right in the sense that for someone from a programming background, using FPGAs is far harder than it could be. I have looked into it a few times and it is indeed horrible.
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).
Okay then. I wanna know of a better way to take four 1 GSPS signals, demodulate them, and pump out another two 1 GSPS signals which encode decisions made every every four samples on the incoming signals. That's ONE of the problems in quantum control for stabilizing one qubit. We did it with an FPGA. If you know of a DSP or systolic array or processor or what have you for doing this, I'm ALL ears. Oh and the timing must be COMPLETELY deterministic down to the nanosecond.
In fact, if you know of ANY general purpose hardware that will talk to gigasample ADCs/DACs, I'd love to know about it.
ASIC. The timing will be better. Less power will be burned.
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.
The grandparent is responding to the article, which is talking about general purpose computation. There's no question that your application is a prime use case for an FPGA.
I'm not sure fpga's are the least efficient everywhere,aren't there micro+fpga chips(like xilinx zynq) used in high/medium volume embedded system ? and wouldn't better tools increase volumes, leading to lower costs ?
Comments
What a useless article.
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 is the least efficient way to accomplish anything" Define 'efficient'. If you're talking about cost, it costs far less than an asic below a certain volume, and it certainly costs less in tooling and development.
"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.
You can still abstract lots of it. For example chisel[1] does so through high level abstractions and parametrized generators - while still offering results equal to verilog.It's also also used for the open source risc-V architecture[4], the recent highly-efficient parallel cpu[2] done by a small start-up(2 guys),and a floating-point alu generator[3] that explores the design space of fpu's and finds optimal designs.
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...
[4]http://www.eetimes.com/author.asp?doc_id=1323406
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.
He is right in the sense that for someone from a programming background, using FPGAs is far harder than it could be. I have looked into it a few times and it is indeed horrible.
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).
Legacy tools, IMHO, is the biggest problem. This article got it right -- you can't just get rid of them.
Okay then. I wanna know of a better way to take four 1 GSPS signals, demodulate them, and pump out another two 1 GSPS signals which encode decisions made every every four samples on the incoming signals. That's ONE of the problems in quantum control for stabilizing one qubit. We did it with an FPGA. If you know of a DSP or systolic array or processor or what have you for doing this, I'm ALL ears. Oh and the timing must be COMPLETELY deterministic down to the nanosecond.
In fact, if you know of ANY general purpose hardware that will talk to gigasample ADCs/DACs, I'd love to know about it.
ASIC. The timing will be better. Less power will be burned.
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'd LOVE to make an asic, but we're a small lab and don't have that much to spend.
Exactly. It's not that an FPGA is better, more flexible, faster, etc. It's that you don't have the money for the NRE on an ASIC.
That is EXACTLY the reason to use an FPGA. I use them all the time for projects like that.
This is different from the software people who want a magically flexible brain for generic tasks.
The grandparent is responding to the article, which is talking about general purpose computation. There's no question that your application is a prime use case for an FPGA.
I'm not sure fpga's are the least efficient everywhere,aren't there micro+fpga chips(like xilinx zynq) used in high/medium volume embedded system ? and wouldn't better tools increase volumes, leading to lower costs ?