I love FPGAs. They're awesome for interacting at a low level with just about any kind of hardware, at nano-second-level latency.
But although I bought one, I don't think most people will end up buying one, unfortunately; the vast majority of the consumer stuff that we considered putting on FPGAs in the past (graphics rendering, heavy math) is solved six ways to Sunday by today's GPU. The FPGA also lacks an open-source (or even shared-source) toolchain, there's no way to perform resource sharing, they have code constraints that are physical limits, and so on.
Basically, FPGAs rock when used for chip design or for powering custom prototype or small batch hardware. But they fall into a really narrow portion of the market, because there are few cost-effective consumer-level solutions that make use of FPGAs.
Oh, wow. I have never seen this before. That's enormously useful and could be a huge step towards getting FPGAs on the "maker" market. Thanks for the link!
I agree with this. I've always wanted to use an FPGA for something cool, but never found a need. (I'm a hobbyist, fwiw).
They fall in a middle ground between things I can build more simply with a super cheap microcontroller (I buy Arduino nanos for $2, for example), and things I really need GPU compute for. So I'm stuck. I keep thinking I'll do a DSP project soon, but that's more because it is one of the few things I think an FPGA will be useful for, than because I need it.
So cool, yes. Practical, maybe - but not very, at least for me.
Bunnie Huang (Novena laptop) talks mention how they reverse engineered ISA by MitM the CPU through the FPGA on the Novena's board. That's as cool as epic.
He did it in a hotel room in a foreign country. He, Tarnovsky, Nohl and Goodspeed just blow my mind.
Things like the ZINC by Xilinx are working its way into things like the Red Pitaya[1] which is absolutely remarkably capable for the price range, but yeah FPGA's are pretty niche for the common end-user. Lithography on sil wafers ends up being cheaper at nearly any scale. It turns out more economical just to do that one of those cheap FPGA-to-ASIC conversion dealies (rather than using Cadence or whatever VLSI tooling you have to DFM from the start [I think UC Berkeley has a full architecture/RTL/logic/circuit/physical kit]) at the threshold of around a few thousand units.
>The FPGA also lacks an open-source (or even shared-source) toolchain,
I think this point is overstated. FPGAs are not microprocessors. I don't think an OSS toolchain would be anywhere near as beneficial as something like gcc. It would be nice to have but it's hard to think of any problems specific to programmable logic that this would address.
What would help is toolsets with less friction and less of an entry barrier.
Implementing your own routing algorithms, running these procedures in parallel on a cluster (something like distcc) and things like that would really benefit FPGA industry. The area is full of research problems, but only Xilinx progarammers and a few other companies are allowed to do research in this area and try their ideas. Well, some file formats are open (xdl/ncd files), but you have to reimplement everything from scratch.
FPGAs are awesome. They help solve problems that software is too slow to solve, but aren't large enough in scale for ASICs.
They're also great for prototyping new chips before actually shelling out the hundreds of thousands of dollars NRE for a new ASIC design.
In the projects where I use them in university I always found them quite hard to work with.
While the idea of programming them with VHDL or Verilog is quite straightforward, there were a lot of bumps in the road to getting a working design. Specialized tools which generate reports that go on for pages and pages (our team was completely unable to do something about the path of longest delay), complicated information about the clock, and having to work with vague documentation and intellectual property.
FPGA's are really nice when they work, but I feel like they are just too complicated for developers to get started with on their own, at the moment.
Yeah, they're a bit of a dark art. They require hardware design tricks like pipelining for best performance, you can run into fun stuff like routing fabric congestion which absolutely kills performance and in turn is affected by stuff like the layout the tools choose and whether you're using cheaper or more expensive FPGAs (which at least for Xilinx have very different balances of routing resources), etc. I've seen timing failures due to the signals having to divert around the clock generators at the edge of the chip, which were effectively a wedge with no routing fabric in between two sections of logic.
Just a shout-out about the Icestorm project which provides a complete open-source toolchain for Lattice's iCE40 FPGAs. It's mostly the work of one guy (Clifford Wolf): http://www.clifford.at/icestorm/.
The thing that really got me excited about FPGAs was working with the "HappyBoard" that was used for MIT's 6.270 robotics competition[1]: it's similar to an Arduino (AVR microcontroller with pin headers broken out and USB), but with most of its IO (sensors, motors) going through a Xilinx FPGA rather than directly connected to the ATMega128.
What that meant was that the AVR, which was relatively slow at 8MHz, was free to run all your logic (including multithreading!) while the FPGA handled most of the timing-critical things, like motor PWM and sensor decoding.
But the coolest part was that you could dynamically modify the IO if you needed different behavior. Instead of having to find, buy, and wire up a standalone quadrature decoder IC to count axle rotations, I just had to write some code [2] and suddenly the board has a high speed quadrature decoder (or several) built in!
The biggest roadblock is the toolchain though - even though [2] was a pretty simple change, it took a long time to download and install the Xilinx ISE tools, and they're not the easiest to use.
I would love to see a general purpose AVR+FPGA board with the FPGA toolchain neatly packaged the way Arduino/Wiring has done for AVR. Verilog has a somewhat steep learning curve, so you might want to hide that in some kind of module system, with basic library modules like PWM, edge counting, or quadrature decoding that can just be mapped to the pins you want. Maybe something building on top of Icestorm?
There's an important caveat that this is missing: yes, FPGAs can do a whole bunch of multiply-accumulate operations at once, but each of those units really wants to carry out the same multiply-accumulate operation every clock cycle, with inputs coming from the same sources and outputs going to the same destinations. With DSPs you can trivially execute a completely different step of the computation every clock using the same multiplier, but on FPGAs you either have to set up all your own control logic to multiplex all the DSP units in and out at the right time or have one multiplier per stage in the computation and inevitably lose efficiency because the rate you're feeding data in is slower than the speed the FPGA can run at. And large FPGAs are relatively expensive and, well, big - the bottom-of-the-range Artix 7 with 45 multiply-accumulate slices (enough for one 45-stage computation without complex tricks) is $25 and the smallest package you can get it in is 1cm2.
You are ignoring that the 12 core Xeons are still relatively cheap at $2000 which means it's still affordable to just buy four of them and put them into a single server.
Not only that, but at all of the price points I've back-of-the-enveloped, GPUs beat FPGAs hands down at processing power. Even if they didn't, the sheer effort required to take advantage of that power would make GPUs more attractive for general purpose compute. Here's the what you generally have to put up with on a FPGA:
* Fixed point.
* Resource starved. Limited # logic blocks, using DRAM from an FPGA is a massive PITA and you pay dearly for every 100kb of SRAM.
* You figure out how to pipeline so that every cell gets used on every cycle.
* HDL languages
* Terribly long compile+route times...
* ...and sometimes routing fails even if your program is well-formed and "ought to" fit on the chip!
* Proprietary toolchains
* Expensive kits (don't let the $20 kits fool you -- you'll spend thousands if you're really using an FPGA for what they're good at)
* Even more expensive test equipment (makes the thousands you spent on the FPGA kit look cheap)
The flipside is that GPUs don't do deterministic latency or talking to hardware. If you need to ship billions of samples per second from your JESD204B ADC back across your PCIe bus (to get them into your GPU, of course) then there's only one chip that fits the bill: the mighty FPGA.
To be frank after having experience with both FPGA and software development.
If you can solve the problem in software, just do it.
The cost in time and complexity of solving a problem in hardware is almost always larger.
When writing software you gain a level of abstraction.
You do not have to deal with getting a special hardware (the FPGA), mess with proprietary buggy tools, and all the nitty gritty stuff of proper reset, multiple clock domains, timing closure where each rebuild of your code might take multiple hours to close. And don't get me started with writing HDL-code.
I implemented an object tracker using a FPGA and a webcam and there were multiple hardware problems that needed to be handled such as buffering data in the sdram (design a sdram memory controller), research and implement image filters and debug why the camera image sometimes got corrupted (the connection cables were too long).
Almost all of these problems would have been gone by instead connecting an USB-webcam to my PC and utilize the openCV library.
> The cost in time and complexity of solving a problem in hardware is almost always larger.
Why?
I have exactly the opposite feeling when I'm dealing with software - "if only I could design my own cache here, how much easier would it be to get around this bottleneck!"
No, I'm arguing against a universality of such a claim. There is a performance/complexity threshold above which hardware or hybrid solution is a way easier than a purely software one.
I can see for performance. Software seems better at managing complexity if good structure is used. What example do you have where software is harder to develop and test than hardware due to complexity?
> Software seems better at managing complexity if good structure is used.
Not until you hit a deep semantic difference between your hardware and a code you're trying to build.
For example, there are many things that are best expressed as a Network-on-Chip: a pipeline of specialised CPU cores each doing something simple. And such a notion is not that easy to represent in a pure software without a gigantic performance penalty. A pair of a CPU core and a small piece of code running on top of it can be far simpler than any piece of code written for an existing but not fitting architecture.
A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86.
I still doubt it's better at reducing complexity because that stuff is horrific in RTL. I can express it with a parallel programming language with ease. A parallel programming language with macros and automatic placement onto cores/DSP's would be even easier. Describe it, compile, and it probably runs. With hardware, I'm looking at several more layers of verification, testing, material checks, and so on.
High-level synthesis tools on the other hand might make your claim true. They're a combo of HW and SW languages.
"A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86.
"
Simpler for who? The person implementing both a Forth implementation and a x86 processor? Or the person just implementing a Forth on x86? I've seen Forth implementations in SW. They're trivial. Compilers, libraries, and hardware do all the heavy lifting. I'll put it to the test, though, as I feel you might have picked a good example.
Maybe it's just that I don't know Verilog. However, the Verilog code looks more like the assembler in second link. It's like a pile of gibberish. The Ada code is very straightforward. I bet the debugging was easier, too. S, I'm still not sold on hardware reducing complexity versus software implementation.
I'm 100% agreeing on improving performance esp where semantic mismatch occurs. Hell, that's what inspired me to ask you and some others to evaluate those two or three HLS tools so I could start cranking out accelerators if one was legit. ;)
This is a nice intro but the author forgets another downside of FPGAs which is power consumption. The hard cores help, but in the limiting case you end up with an ASIC.
32 comments
[ 3.6 ms ] story [ 70.6 ms ] threadI love FPGAs. They're awesome for interacting at a low level with just about any kind of hardware, at nano-second-level latency.
But although I bought one, I don't think most people will end up buying one, unfortunately; the vast majority of the consumer stuff that we considered putting on FPGAs in the past (graphics rendering, heavy math) is solved six ways to Sunday by today's GPU. The FPGA also lacks an open-source (or even shared-source) toolchain, there's no way to perform resource sharing, they have code constraints that are physical limits, and so on.
Basically, FPGAs rock when used for chip design or for powering custom prototype or small batch hardware. But they fall into a really narrow portion of the market, because there are few cost-effective consumer-level solutions that make use of FPGAs.
A shame, really. They're super cool.
They fall in a middle ground between things I can build more simply with a super cheap microcontroller (I buy Arduino nanos for $2, for example), and things I really need GPU compute for. So I'm stuck. I keep thinking I'll do a DSP project soon, but that's more because it is one of the few things I think an FPGA will be useful for, than because I need it.
So cool, yes. Practical, maybe - but not very, at least for me.
Things like the ZINC by Xilinx are working its way into things like the Red Pitaya[1] which is absolutely remarkably capable for the price range, but yeah FPGA's are pretty niche for the common end-user. Lithography on sil wafers ends up being cheaper at nearly any scale. It turns out more economical just to do that one of those cheap FPGA-to-ASIC conversion dealies (rather than using Cadence or whatever VLSI tooling you have to DFM from the start [I think UC Berkeley has a full architecture/RTL/logic/circuit/physical kit]) at the threshold of around a few thousand units.
[1] http://store.redpitaya.com/red-pitaya-board-36.html
I think this point is overstated. FPGAs are not microprocessors. I don't think an OSS toolchain would be anywhere near as beneficial as something like gcc. It would be nice to have but it's hard to think of any problems specific to programmable logic that this would address.
What would help is toolsets with less friction and less of an entry barrier.
(109 points, 331 days ago, 107 comments)
https://news.ycombinator.com/item?id=9388751
(379 points, 999 days ago, 152 comments)
https://news.ycombinator.com/item?id=5895672
Here's a great stackexchange discussion on why and how FPGAs can outperform CPUs for certain tasks: http://electronics.stackexchange.com/questions/101472/how-ca...
While the idea of programming them with VHDL or Verilog is quite straightforward, there were a lot of bumps in the road to getting a working design. Specialized tools which generate reports that go on for pages and pages (our team was completely unable to do something about the path of longest delay), complicated information about the clock, and having to work with vague documentation and intellectual property.
FPGA's are really nice when they work, but I feel like they are just too complicated for developers to get started with on their own, at the moment.
It's worth noting that arachne-pnr (https://github.com/cseed/arachne-pnr) is written by a different person (Cotton Seed).
What that meant was that the AVR, which was relatively slow at 8MHz, was free to run all your logic (including multithreading!) while the FPGA handled most of the timing-critical things, like motor PWM and sensor decoding.
But the coolest part was that you could dynamically modify the IO if you needed different behavior. Instead of having to find, buy, and wire up a standalone quadrature decoder IC to count axle rotations, I just had to write some code [2] and suddenly the board has a high speed quadrature decoder (or several) built in!
The biggest roadblock is the toolchain though - even though [2] was a pretty simple change, it took a long time to download and install the Xilinx ISE tools, and they're not the easiest to use.
I would love to see a general purpose AVR+FPGA board with the FPGA toolchain neatly packaged the way Arduino/Wiring has done for AVR. Verilog has a somewhat steep learning curve, so you might want to hide that in some kind of module system, with basic library modules like PWM, edge counting, or quadrature decoding that can just be mapped to the pins you want. Maybe something building on top of Icestorm?
[1] http://spacecats.mit.edu/contestants/happyboard-manual.pdf
[2] https://github.com/sixtwoseventy/joyos/commit/44975ea9bc64e5...
That's an understatement.
http://www.findchips.com/search/xcvu9p
http://ark.intel.com/products/84685/Intel-Xeon-Processor-E7-... http://www.amazon.com/Nvidia-Accelerator-passive-cooling-900...
Now, I guess you can decent performance out of cheaper chips already, but paying $5000 for an Intel CPU is hardly rare.
* Fixed point.
* Resource starved. Limited # logic blocks, using DRAM from an FPGA is a massive PITA and you pay dearly for every 100kb of SRAM.
* You figure out how to pipeline so that every cell gets used on every cycle.
* HDL languages
* Terribly long compile+route times...
* ...and sometimes routing fails even if your program is well-formed and "ought to" fit on the chip!
* Proprietary toolchains
* Expensive kits (don't let the $20 kits fool you -- you'll spend thousands if you're really using an FPGA for what they're good at)
* Even more expensive test equipment (makes the thousands you spent on the FPGA kit look cheap)
The flipside is that GPUs don't do deterministic latency or talking to hardware. If you need to ship billions of samples per second from your JESD204B ADC back across your PCIe bus (to get them into your GPU, of course) then there's only one chip that fits the bill: the mighty FPGA.
The cost in time and complexity of solving a problem in hardware is almost always larger.
When writing software you gain a level of abstraction. You do not have to deal with getting a special hardware (the FPGA), mess with proprietary buggy tools, and all the nitty gritty stuff of proper reset, multiple clock domains, timing closure where each rebuild of your code might take multiple hours to close. And don't get me started with writing HDL-code.
I implemented an object tracker using a FPGA and a webcam and there were multiple hardware problems that needed to be handled such as buffering data in the sdram (design a sdram memory controller), research and implement image filters and debug why the camera image sometimes got corrupted (the connection cables were too long).
Almost all of these problems would have been gone by instead connecting an USB-webcam to my PC and utilize the openCV library.
Why?
I have exactly the opposite feeling when I'm dealing with software - "if only I could design my own cache here, how much easier would it be to get around this bottleneck!"
Not until you hit a deep semantic difference between your hardware and a code you're trying to build.
For example, there are many things that are best expressed as a Network-on-Chip: a pipeline of specialised CPU cores each doing something simple. And such a notion is not that easy to represent in a pure software without a gigantic performance penalty. A pair of a CPU core and a small piece of code running on top of it can be far simpler than any piece of code written for an existing but not fitting architecture.
A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86.
High-level synthesis tools on the other hand might make your claim true. They're a combo of HW and SW languages.
"A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86. "
Simpler for who? The person implementing both a Forth implementation and a x86 processor? Or the person just implementing a Forth on x86? I've seen Forth implementations in SW. They're trivial. Compilers, libraries, and hardware do all the heavy lifting. I'll put it to the test, though, as I feel you might have picked a good example.
J1 Forth CPU Verilog code http://excamera.com/files/j1demo/verilog/j1.v
eForth assembler for Z80 & such in few assembly instructions http://www.figuk.plus.com/4thres/systems.htm
Forth interpreter in Ada (1985) http://www.forth.com/archive/jfar/vol3/no2/article7.pdf
Maybe it's just that I don't know Verilog. However, the Verilog code looks more like the assembler in second link. It's like a pile of gibberish. The Ada code is very straightforward. I bet the debugging was easier, too. S, I'm still not sold on hardware reducing complexity versus software implementation.
I'm 100% agreeing on improving performance esp where semantic mismatch occurs. Hell, that's what inspired me to ask you and some others to evaluate those two or three HLS tools so I could start cranking out accelerators if one was legit. ;)