11 ms·

How FPGAs work, and why you'll buy one

379 points by edwintorok 13y ago

csense 13y ago
Question for people familiar with the Parallella project [1]: I see the board design has an FPGA. If I buy a Parallella, can I take the Verilog source code in this article, run it through some toolchain, and actually execute it on the board? [1] http://www.parallella.org/board/ http://www.parallella.org/board/
- vidarh 13y ago
  You should be able to. The SoC used for the Parallella is a Xilinx Zynq-7020 which is available on various FPGA dev boards too. The Parallella will use some of the FPGA for various glue logic, but the code in question either is or will be open sourced - they're being very good about opening up whatever they can (since their goal after all is to get people to build stuff that'll drive orders for their chips going forwards)
ChuckMcM 13y ago
Nicely done, if you add a bit about clock distribution it would be perfect. Clock distribution is important because sometimes you want all the parts of your FPGA design to wait until a particular time to allow for various gate delays etc before they do the next thing. You can synchronize to a "global" clock but if you only have one global clock then you may be limited on how much of the circuit can be in your FPGA if other parts need a different clock. That said, as FPGA vendors get closer and closer to an efficient mix of hard and programmable gates, their utility gets higher and higher. That increases volume and helps get prices lower. I've mentioned the Zynq-7000 (which I'm playing with using a Zedboard[1]) which is dual ARM9 cores and an FPGA which can drive several HDMI 1080p/60 displays. Other systems with fully "soft" CPUs use definable instructions to optimize code execution but that hasn't been as useful as I expected. Back when Xerox PARC was building the 'D' machines it was great fun when a new release of Mesa microcode came out because everything would get faster or more compact (rarely together though ;-) [1] http://www.zedboard.org http://www.zedboard.org -- of course I'm currently fighting a tool/license issue with the Xilinx tools but once that gets sorted I'll actually be building new designs on it.
dchichkov 13y ago
If you want to get your hands dirty, there is a pretty good eval kit available at Lattice, $100 gives you a PCI express board with GbE port, 1GBit DDR3 1330 and software...
- sliverstorm 13y ago
  This? http://www.latticesemi.com/products/developmenthardware/developmentkits/ecp3versadevelopmentkit/index.cfm http://www.latticesemi.com/products/developmenthardware/deve...
alecdibble 13y ago
I believe the next big jump in FPGA utilization will involve high-level synthesis. Verilog and VHDL are essentially analogous to assembly languages in terms of abstraction.
- swah 13y ago
  That will happen at the same time PS3 games are written in Haskell instead of C++ :)
- anon859486896 13y ago
  I think that is true, but I think there is another problem as well. There is no, to my knowledge, equivalent of GCC for an FPGA, and by that I mean a free, open source, cross platform synthesizer. You are stuck using their tools, and they are generally suboptimal at best when it comes to the IDEs at least. I think one of the main problems is that it is the FPGA manufacturers that also provide the toolchains, and that is your only option. Edit: Also, forgot to add. I am not sure FPGAs are that ameniable to using higher level languages simply because you can make a trivial adjustment to your code and resource usuage will jump from 1% to 27%, which is not trivial. It used to be the same with your normal CPUs, every cycle counted, this will improve with time of course.
- kryten 13y ago
  I was using Xilinx FPGAs in 1998 and they were saying next year then for such a thing. It's 15 years later and it's still the same with shitty overpriced tools, per-vendor ghettos and crazy per-unit prices. Granted we've got a couple of ARM cores instead of a single PPC 603 and a clock speed ramp but that's it. If they snap out of that crap, perhaps, one day we'll reach utopia. Then again, fucking rich engineering companies over for wads of cash is better for business.
  - sliverstorm 13y ago
    I don't know that it's by choice. The market is small, and the problems are not easy. Software compilers have had tons of effort, money, and mathematical knowledge thrown at them for the past several decades. HDL-to-FPGA synthesis and place/route on the other hand has been driven by only a few companies, and hasn't been around nearly as long.
namank 13y ago
Programmers don't give a crap about the reasons mentioned in the post. So, if FPGAs do take off in the dev community, it'll be for different reasons. Such as when 80% of the world's code can be, with accuracy, can be parsed into HDLs.
- VikingCoder 13y ago
  I'm a programmer, and I care about delivering great performance at reasonable price to my clients. If I had a set of problem in an application where an FPGA would benefit the customer, I'd seriously consider targeting one.
  - namank 13y ago
    Would you trade off developer time to figure out how many registers to use, how many pipeline stages you want every single time you need to write code? How many of your developers are apt at figuring that out? And that's a decision you have to make every time you want to add a feature because FPGA architecture is, more often than not, dependent on the business logic you want it to encapsulate. It's cheaper to get an Arduino instead. FPGAs look very attractive when you're used to comparing C#/Python/Java/everything to C but that fades away as soon as the complexity in managing code on FPGAs comes to light. All the points mentioned in the article under "performance"? It's left up to you, the developer, to configure the board in such a way that you can leverage them. And that's before you've written a single line of the business logic. In theory, FPGAs give you the power to code your business logic as circuits (making it monumentally faster) but in practice, the story is very different. You may want to look at High Frequency Trading - they use FPGAs for stock analysis there.
    - whatshisface 13y ago
      When you need an FPGA, you need an FGPA. I don't think anyone would spec out one gate at a time if C and an operating system could cut it.
      - namank 13y ago
tim_hutton 13y ago
More context about how FPGAs compare with GPGPU: http://blog.streamingcores.com/index.php?/archives/20-Programming-massively-parallel-systems-FPGA-vs.-GPU.html http://blog.streamingcores.com/index.php?/archives/20-Progra...
vasco 13y ago
There's a lot of good information in the article for software people for whom hardware design is strange but I think the author makes some strange points. For starters, its strange to have him refer to Verilog as a programming language multiple times all over the article. Anyone that has ever tried to do even minimal stuff on hardware will know this the wrong way to think about things. Verilog, VHDL and whatever other hardware description languages should not be approached as programming languages, or you'll have a bad time. You need to think about what you are generating. By using HDL's we have the ability to avoid messing with crappy interfaces where you drag chips and connect wires by hand, but ultimately you really need to know what's being generated. If you write a couple of lines and have no idea of the hardware behind it, you'll likely be making a lot of mistakes. Everyone that has tried messing with FPGA's without thinking about this has ended up with hundreds of generated latches among other niceties... There's already some degree of syntactic sugar on VHDL processes (or verilog @ blocks) which make it really easy to shoot yourself in the foot by abstracting stuff. Ultimately you'll want to know what's going on rather than not. Hardware is hard, but when you need the performance you'll do it the right way, or you might as well save yourself a lot of trouble and just go with a beefier machine and some optimized C code.
- schabernakk 13y ago
  yup. I worked on a simple game AI (Connect6) for a university project implemented in Verilog. Initial prototyping in python was super easy and quickly done, translating the same program to Verilog took multiple weeks. We split the program up into multiple modules with each module handling different cases. While writing the program we only compiled it with the modules we were currently working on and even that took long enough (remember: we were trying to more or less directly translate the python program to verilog with a bit more global state). Once we finished we tried to compile the whole program with each module enabled and it compiled and compiled and compiled. We aborted after 20 hours of compiling and no end in sight, the design we were using was just not suited to be used with hardware. Now, this was the first time ever I worked with hardware and while I really liked having something tangible and all those nice blinking lights on the fpga board, programming one was a pain in the ass. Towards the very end of the project I slightly got the hang on how you should approach writing such software. And the most important thing is to not think like you would when programming traditionally. Designing and later implementing a FSMD for example is far more efficient.
Jemaclus 13y ago
It'd help if someone defined FPGA before the 12th paragraph... I like to learn things, but when you start out assuming I know what the acronym means, then you lose me before I get to the good stuff. :(
- whatshisface 13y ago
  Field-programmable gate array.
  - Jemaclus 13y ago
    Yeah, I got that at the 12th paragraph. :(
taylorbuley 13y ago
Here's the FPGA from Adafruit: http://www.adafruit.com/products/451 http://www.adafruit.com/products/451 At the time they wrote "we searched around for a fpga board we really liked, here's the one we picked" (https://plus.google.com/+ladyada/posts/VZ1zyTF73oM https://plus.google.com/+ladyada/posts/VZ1zyTF73oM) Here's an example demo using that hardware: http://learn.adafruit.com/fpga-rgb-matrix/overview http://learn.adafruit.com/fpga-rgb-matrix/overview
- fnordfnordfnord 13y ago
  Source for that is Terasic http://www.terasic.com.tw http://www.terasic.com.tw They do reference designs for Altera, and have quite a few neat dev boards.
zw123456 13y ago
I think the author makes a number of good points. I think in the future, it may be possible for machine code to be converted directly to RTL (the equivalent of machine code for FPGA's) without going through the intermediate steps of converting C code to a multi-state machine in Verilog or similar types of coding. If this happens then a CPU or OS, could use an FPGA as a Co-processing Cache of sorts, in the same way that often accessed data in placed in higher speed cache RAM; often executed pieces of code could be placed in the FPGA co-processor. If that happens, I believe we could see the same kind of order of magnitude jump in performance we see due to memory cache happen in processing speeds.
bhb916 13y ago
This is a solid article. I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. In my mind, it is an easy way to expand your breadth of knowledge and make you a touch more valuable to future employers. They say that when all you have is a hammer, everything looks like a nail and I'm certainly inflicted with that same disease as I see the utility of FPGAs everywhere I look. Prices have plummeted while densities have skyrocketed. A simple $25 part gets you quite a bit of fabric and some $90 eval hardware will give you a sweet little platform. [1] With that said, since I began working with them there have been two "Holy Grails" of FPGA design: (1) Partial Reconfiguration and (2) High Level Synthesis. The first, Partial Reconfiguration, has been more-or-less solved although the tools have a long way to go. One current design I'm working on loads it's PCIe endpoint and DDR3 controller first, establishes communication with the application running on the host PC, then based on user input loads the rest of the FPGA. The second, High Level Synthesis, isn't here yet. The goal is to turn a company's vast army of software engineers into FPGA programmers overnight. A worthy cause. Every foray into this field has failed (although the jury is still out on Xilinx's purchase of autoESL) Honestly, I'm not sure it will ever get there. The point of optimized, custom hardware is to make use of it. Abstracting it all away seems counterproductive, not to mention very hard. [1] http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9.htm http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9....
- dualogy 13y ago
  > I see the utility of FPGAs everywhere I look Examples?
  - jff 13y ago
    I see the utility anywhere a simple, repetitive task is performed with interaction from the physical world. The canonical student example is the soda machine. Sure, you could put a small Linux system in there and write Python code, but then you have millions of lines of Linux and Python code underlying your simple little soda vending code. Instead, you describe the problem as a state machine and implement it in the FPGA. This gives you an instant-on solution. I often find myself looking at the behavior of basic systems like automatic doors, card readers, thermostats, and motion-triggered light switches, thinking about their behavior and how I might describe it as a state machine. Thinking about what combination of inputs and outputs, what sensors and actuators would be needed to perform the task. It's fun.
mncolinlee 13y ago
GPGPUs have been a lot more interesting with the rapid pace of development in recent years, but there are still software optimizations that are only feasible on an FPGA. They're one of the most interesting pieces of hardware a programmer can use to develop high-performance hacks. When I worked at Cray, our team found numerous ways to make them useful. I've been meaning to pick one up for a long time.
nwhitehead 13y ago
This article reminds me how much fun it is to program an FPGA. It's one of those mind-expanding exercises like learning logic programming or writing a purely functional persistent data structure. "Describing hardware" is quite a different way of looking at computation. In case you want to try, I had good success playing around with the Altera DE2. It's got lots of "goodies" on the dev board and there are lots of existing class projects, class notes, etc. that use it. It's fun to get your own tiny CPU working and have it flash HELLO WORLD on the LCD display. You have to worry about bugs in your CPU as well as bugs in the program running on your CPU.
- rwg 13y ago
  The downside of the DE2 boards is that they're really stinking expensive if you don't qualify for the academic pricing. I'd love to have a go at Verilog and/or VHDL, but I'm turned off by all of the sub-$100 FPGA dev boards because they basically just break out all of the FPGA's I/O pins to 0.1" headers and leave doing anything useful (as far as I/O goes) as an exercise for the reader.
  - daniel-cussen 13y ago
    There's the Mojo at kickstarter. http://www.kickstarter.com/projects/1106670630/mojo-digital-design-for-the-hobbyist http://www.kickstarter.com/projects/1106670630/mojo-digital-...
    - duskwuff 13y ago
      …which only has a single button for input, eight LEDs for output, and a couple comm lines with the AVR. Everything else is just broken out to headers.
  - snom380 13y ago
    How about this? http://dx.com/p/fpga-ask2ca-8-diy-learning-development-board-blue-black-217979 http://dx.com/p/fpga-ask2ca-8-diy-learning-development-board...
  - zhemao 13y ago
Symmetry 13y ago
I've heard that there's been some progress in compiling Haskell to Verilog, but I don't know how far that effort has gone. Certainly more declarative languages seem much more suited to this than imperative ones. I have no idea how practical this is at the moment, though: http://cufp.org/conference/sessions/2012/peter-braam-parallel-scientific-awesome-haskell-fp http://cufp.org/conference/sessions/2012/peter-braam-paralle...
- amirhirsch 13y ago
  http://www.bluespec.com/ http://www.bluespec.com/ was based on Haskell. Polymorphism is awesome for FPGA design: it is incredibly satisfying to quickly turn a fixed-point FFT to floating-point and see the area/speed/power difference from the FPGA synthesizer
micheljansen 13y ago
I think the increasing popularity of functional programming or at least less imperative-style programming is making FPGAs more accessible. I remember my first brush with VHDL during my first year of CompSci and having a hard time adjusting to the fact that what you are writing is not a program that is executed step by step (whether line by line or instruction by instruction), but a description of hardware components/functions that all "run" simultaneously. Now that my brain is more comfortable thinking in terms of functional solutions, this all makes a lot more sense, but I haven't revisited FPGA programming since.
- _yosefk 13y ago
  Functional style indeed works fine with simple data flow graphs, but once you start fiddling with RAM you're back to imperative nightmares from hell (unless you're wielding a sufficiently smart compiler that I haven't seen, of course.)
twasfm 13y ago
This is written by the C++ FQA guy which is an amusing and honest look at C++
DennisP 13y ago
This may be a dumb question, but would FPGAs be a good choice for neural networks? Or is a GPU already ideal for that?
- _yosefk 13y ago
  There are academic people mapping neural nets on FPGAs; I'd expect FPGAs to do better if you manage to use integer arithmetic.
- sporkologist 13y ago
  Looks like they scale easily in parallel from what I read. Here's a book on it: https://www.springer.com/engineering/circuits+%26+systems/book/978-0-387-28485-9 https://www.springer.com/engineering/circuits+%26+systems/bo...
- kyzyl 13y ago
  Both can be made to work quite well for various ANN implementations. Currently GPGPU is a lot more popular because it requires far less hardware knowledge to get going, which translates into much quicker development cycles. For example, the boom of deep learning which has been going on since ~2002 has been largely couched in the massively parallel training of neural networks on GPUs. Some clever folks have written libraries like Theano, which allows you to create computation graphs in python that can be compiled, targeting either CPU or GPU. In principle FPGAs can be an extremely attractive option, because a well designed implementation could run very fast as scale very well, given that their massively parallel architecture lends itself to the parallel nature of ANNs. A few groups have gone to lengths to implement, for example, a Restricted Boltzmann Machine architecture directly on FPGA, and in raw benchmarks it works well. However, you start to run into practical limitations if you try to apply those archs to real-world problems, because all but the most expensive FPGAs have trouble fitting very large neural net architectures on-chip. Furthermore, the data required to train the nets is often too big to fit in RAM on the chips, meaning you're left with network or SD-card type approaches, which can be cumbersome and slow. I can recall at least one instance where the design explicitly addressed this issue by designing the architecture to be distributed over many hardware linked FPGAs, but even then you still run into the usual parallelism and concurrency issues: you need to balance parallelism overhead against speedups, you run into synchronization issues, and things can become non-deterministic and very difficult to debug. The bottom line is that it doesn't look like neural network FPGAs or ASICs are there yet. I'm sure there will be more exploration of this space in the future. As it stands right now, neural network training is dominated by GPGPU implementations.
ChikkaChiChi 13y ago
Are they referring to FPGAs in a mass-production/manufacturing sense or for the hobbiest/garage hacker? I guess I'm unsure why I would use an FPGA over say an Arduino microcontroller.
- VLM 13y ago
  "I guess I'm unsure why I would use an FPGA over say an Arduino microcontroller." Its unfortunate no one replied. First you upload an arduino reference design into the FPGA and continue working normally. This takes up about 1% of the FPGA gates, and leaves about 200 unused I/O pins (depending on FPGA device of course) and it probably runs faster than the real thing. (It also probably draws about 10 times the current...). Next, instead of you writing a bit-banged I2C interface, you download, include, configure, and synthesize a smart semi-intelligent I2C peripheral into your synthetic arduino on a I/O pin that doesn't exist in the real thing. Now your arduino source code to debug shrunk by perhaps 200 lines and the I2C is faster. Now your FPGA is 2% full and 98% empty. Hmm, what if instead of polling that pin in my arduino and/or going interrupt based, I simply included a whole picoblaze CPU core to do nothing but baby sit that input pin while outputting the correct servo signal... And the arduino sets it up and controls it as a very smart peripheral. Well, download, include, configure, synth, upload... Now your FPGA is like 7% used and 93% empty. Eventually your virtual arduino does pretty much nothing but UI. You can replace that with a CPU core of your choosing and OS and language of your choosing, simply upload it instead of the virtual arduino. Repeat a zillion iterations and thats how you started with an arduino and ended up with a MIPS UI written in C++ (why? Why not?) controlling a 8051 based thermostat coprocessor using a smart I2C controller to talk to the temp sensor and a smart servo pulsetrain generator to automatically make the servo signal. Or perhaps it gradually iteratively moves from an arduino to what amounts to a specific model of the MIPS based Microchip PIC32. Why? Who knows maybe you want a single chip $3 solution instead of an $30 arduino solution, or a $300 FPGA solution. Because your FPGA model of a PIC32 is pretty close to the real thing, the porting of your software from the virtual PIC32 to a real PIC32 only takes 15 minutes or so... So you end up not actually using a FPGA in the final product even though it started with an Arduino and ended up on a PIC32.
mrmagooey 13y ago
Now someone should open source a verilog tcp/ip and http stack, and maybe benchmark it against something like varnish.
deleted 13y ago
[deleted]
Jach 13y ago
MyHDL plug: http://www.myhdl.org/doku.php http://www.myhdl.org/doku.php Don't use Verilog or VHDL, use Python and compile to both while avoiding Verilog's pitfalls! http://www.sigasi.com/content/pitfalls-for-circuit-girls http://www.sigasi.com/content/pitfalls-for-circuit-girls
marshray 13y ago
FPGAs aren't going to take off until there's an open source toolchain to program them. Sure, vendors provide free-as-in-beer licenses for their smaller chips and one-off development boards. But the generally useful version will set you back $2 - $3K.
- astrodust 13y ago
  This has been the biggest pain point for me trying to use the MojoBoard (http://embeddedmicro.com http://embeddedmicro.com). It's a decent FPGA, but the tooling is entirely reliant on the Windows or Linux ISE program and you're almost entirely dependent on the IDE. The "loader" is disjointed from the compiler, too, as the loader is board specific. If there was an open-source FPGA core with an open-source compiler, it'd be a lot easier to work with these things.
e12e 13y ago
It's interesting to see how this fits with Chuck Moore's idea of miniature Forth computers: http://www.greenarraychips.com/home/products/index.html http://www.greenarraychips.com/home/products/index.html While not equivalent to FPGAs it does seem like a natural direction if what is desired is similar performance, but with more higher level tooling. That eval board/chip is for instance able to drive VGA using parts of the resources, leaving the rest for other stuff: http://colorforth.com/video.htm http://colorforth.com/video.htm
- _yosefk 13y ago
  Verilog is higher-level than a bunch of nodes talking only to their neighbors and having a tiny amount of RAM, by far...
  - kragen 13y ago
    I think the key difference is that there's already a whole lot of stuff available in Verilog from opencores, and basically nothing for the GreenArrays chips beyond what comes with them. It might be feasible to compile Verilog to the GA chips, but sadly, they don't seem to be working on that. But I don't think you can so easily make a "higher-level"/"lower-level" distinction between the two. On one of the GA cores, you could quite reasonably execute a recursive algorithm — as long as it doesn't need more than 64 words of RAM — in a few lines of code. You can do runtime code generation. You can execute extremely irregular algorithms almost as easily as extremely regular ones. But I think their failure to be compatible with anything else has doomed them.
ctdonath 13y ago
Identical articles were common 15 years ago.
InclinedPlane 13y ago
Just wait. When memristor technology matures it should be possible to create FPGA-like devices with feature density and clock speeds similar to ASICs (e.g. gigahertz, gigatransistors) with reconfiguration times on the same time scale as memory writes. That ought to cause some fairly significant ripples in computing.
- kragen 13y ago
  Hmm, I think memristors failed. The devices HP is promoting as "memristors" now have nothing to do with their original memristors. I don't know why. Maybe the devices started to fail after 100 write cycles or something; totally plausible for physics that depend on ion migration. Maybe someone will invent a new device that does what their original memristors did, but in a form that can be brought to market.
guiomie 13y ago
What would be a good approach to implement a web server in an fpga ? (verilog or vhdl? xillinx or altera? ...etc) It is something I have been thinking a lot lately.
- _yosefk 13y ago
  Run on the on-chip CPU :) (Which bits would you want to implement in Verilog? As to Verilog vs VHDL - Verilog, always :)
  - VLM 13y ago
    Correction that I'd use the on-chip CPU and make the on-FPGA ethernet controller smarter and smarter over time until the on chip CPU isn't doing much other than telling a terrifically smart TCP accelerating ethernet interface to look at a certain array every time someone connects to port 80. Doing that in one jump would be pretty dumb. I'd start with FPGA "hardware" acceleration of ethernet header checksum. Then start accelerating the IP headers. Then start accelerating the TCP headers.
  - jonmrodriguez 13y ago
    Maybe you'd want to write a super-fast template language evaluator. And give it the ability to call database queries.
vishal0123 13y ago
> No need for a full cycle for simple operations: on FPGAs, you don't have to sacrifice a full cycle to do a simple operation, like an OR, which has a delay much shorter than a full cycle. Instead, you can feed OR's output immediately to the next operation, say, AND, without going through registers. You can chain quite a few of these, as long as their delays add up to less than a cycle. With most processors, you'd end up "burning" a full cycle on each of these operations. This may be a dumb question, but how do FPGA execute multiple NON-PARALLEL simple instruction in 1 cycle. I always thought a cycle is undividable and can be used only for a single instruction.
- bhb916 13y ago
  That's not a dumb question at all. The answer is simple: by cramming for logic in between registers. Since you (or at least the tools) are in complete control of the routing, you can place as much logic as you would like between registers, thus accomplishing everything in one clock cycle. The trade-off, however, is that every level of logic adds delay to the path and you can't clock your registers any faster than the sum of all the delays allows (with some exceptions). This simple diagram sort of demonstrates the concept: http://m.eet.com/media/1176731/sync-vs-async-01.gif http://m.eet.com/media/1176731/sync-vs-async-01.gif
swamp40 13y ago
Somehow managed to get thru 20 years of hardware design w/o yet using an FPGA. Keep looking at them (esp. the IGLOO series), but keep finding some better suited or easier to implement alternative.
jwr 13y ago
The problem with FPGAs is that they are a niche technology that is unable to exit its niche. As someone who used FPGAs in a hardware design and regretted it later: there are two major problems with using an FPGA: * it is too expensive for cost-sensitive devices, * moving data onto and out of the chip is and always will be a problem. Now, as to #1 above, you will hear FPGA enthusiast say that prices are just about to fall as more and more devices are produced. But I've heard such claims since at least 1998 and so far this simply hasn't happened. As to #2, the number of MAC operations is irrelevant if you can't supply the chip with data. This is something even modern GPUs have trouble with, in spite of the monstrous bandwidth of the PCI slots they are placed in. Most algorithms will need to move data in and out, and use intermediate storage. Once you do all that, you end up with an expensive and complex design, that doesn't perform all that well anymore, and that is a pain to program and debug. Also, if what you're doing is high-performance computing, then you have to compare the expenses with just getting a larger AWS instance or a cluster. As a result, I tend to advise younger programmers to learn about FPGAs, but not become obsessed with them, as they are very rarely the right tool for the job. I'd even say they are almost never the right tool, except in very rare circumstances.
- digikata 13y ago
  FPGAs are also stuck in a lot of niches. Economically, any high volume application where they could useful also means that putting an investment into more custom silicon is then feasible to get a better price margins - ASICs, DSPs, or I recently learned a bit about metal-gate arrays which seem to be mid-way between FPGAs and hard silicon designs. They're stuck in a power niche because they're comparatively high power vs many embedded ICs, and if you're using a lot of power, as you said more desktop chips are economic to apply.
- _yosefk 13y ago
  With modern FPGAs, you have the CPU on the same chip, which means you can use just one chip and then it's OK for cost-sensitive devices - and your problem of moving data across chips is gone as well. I'm not an "FPGA enthusiast" myself - I work in chip design and Xilinx is a direct competitor. I think FPGAs have their share of problems preventing their adoption and I'll write a follow-up to elaborate. But the problems you mention are between solvable and solved. (BTW it's true for GPUs just as well: just integrate them on the same chip, and forget about the PCI slots. Every high-end to mid-range cell phone has done it a long time ago.)
ChrisNorstrom 13y ago
(By the way, FPGA = Field Programmable Gate Array)
xradionut 13y ago
Software Defined Radio is a good FPGA application: http://www.srl-llc.com/ http://www.srl-llc.com/
shaurz 13y ago
I bought one, never got around to using it, and sold it a few years later. Like a lot of cool technology, it will go underused due to difficulty of use / lack of good, easy-to-use applications. And for all the things I want to do, it's easier to just write software.
VLM 13y ago
There are aspects of the whole technology that were avoided in the article, or edited out for length, or whatever. Regardless of reason, here's some filled in blind spots: One important ignored aspect is you can treat the FPGA as a magic universal microcontroller. Oh, you need 3 UARTs now, I'll INCLUDE another at a different I/O addrs. And you'd like a CANbus now? No problemo in 10 minutes you'll be programming on the same hardware now with a CANbus. Oh you don't want to use a Z80 anymore, fine I'll compile the FPGA to be some pic variant in 5 minutes, or a microblaze, or whatever you want as a CPU core. As long as you slowly successively approximate real available microcontroller hardware, you can ease the eventual port off the FPGA to some microcontroller hardware that costs $1.50 in qty instead of $15.00 in qty. Its a lot easier, faster, and cheaper to upload a bitstream to a FPGA than to solder in a different microcontroller hardware. This makes device selection during development much less critical/scary. You don't have to sit in paralysis wondering if you need 3 or 4 I2C busses. Another thing is not mentioning the open development community. Most HN readers probably hang out at github. The place where most FPGA folks hang out is opencores.org. People who exclusively hang out on github are going to wonder why "no one" is using FPGAs and theres "nothing out there" and "not much activity". Well come on over to opencores and you'll get more than a lifetime of entertainment ahead of you, for free... Its like going to CPAN and hanging out with CPAN people and wondering why "no one" uses Python. Looking in wrong spot. Need a more target rich environment. You can do a lot of "stuff" with FPGAs as the underlying technology without doing much of anything with HDLs. Much as I once programmed on a Silicon on Sapphire CPU a long time ago, but the underlying technology simply didn't matter at the assembly language level. I'm sure it was very exciting on the factory floor and in the R+D labs, but I wasn't there, so I didn't much care. In a similar way you can synth up a perfectly good 6502 and give it twenty semi-intelligent ethernet interfaces without too much HDL effort and then just do your "software thing" on the synthesized device without touching the HDL. Tying it all together, you'll get people outside the community reinventing the wheel, trying to slowly and methodically invent the concept, purpose, and implementation of the WISHBONE interconnect bus standard or something like that. Well, all that stuff got figured out and implemented inside the community like a decade ago, so... Much like the old saying about people refusing to use unix inevitably end up poorly reimplementing it.

379 points by edwintorok 13y ago

Question for people familiar with the Parallella project [1]: I see the board design has an FPGA. If I buy a Parallella, can I take the Verilog source code in this article, run it through some toolchain, and actually execute it on the board? [1] http://www.parallella.org/board/ http://www.parallella.org/board/

vidarh 13y ago
You should be able to. The SoC used for the Parallella is a Xilinx Zynq-7020 which is available on various FPGA dev boards too. The Parallella will use some of the FPGA for various glue logic, but the code in question either is or will be open sourced - they're being very good about opening up whatever they can (since their goal after all is to get people to build stuff that'll drive orders for their chips going forwards)

ChuckMcM 13y ago

Nicely done, if you add a bit about clock distribution it would be perfect. Clock distribution is important because sometimes you want all the parts of your FPGA design to wait until a particular time to allow for various gate delays etc before they do the next thing. You can synchronize to a "global" clock but if you only have one global clock then you may be limited on how much of the circuit can be in your FPGA if other parts need a different clock. That said, as FPGA vendors get closer and closer to an efficient mix of hard and programmable gates, their utility gets higher and higher. That increases volume and helps get prices lower. I've mentioned the Zynq-7000 (which I'm playing with using a Zedboard[1]) which is dual ARM9 cores and an FPGA which can drive several HDMI 1080p/60 displays. Other systems with fully "soft" CPUs use definable instructions to optimize code execution but that hasn't been as useful as I expected. Back when Xerox PARC was building the 'D' machines it was great fun when a new release of Mesa microcode came out because everything would get faster or more compact (rarely together though ;-) [1] http://www.zedboard.org http://www.zedboard.org -- of course I'm currently fighting a tool/license issue with the Xilinx tools but once that gets sorted I'll actually be building new designs on it.

dchichkov 13y ago

If you want to get your hands dirty, there is a pretty good eval kit available at Lattice, $100 gives you a PCI express board with GbE port, 1GBit DDR3 1330 and software...

sliverstorm 13y ago
This? http://www.latticesemi.com/products/developmenthardware/developmentkits/ecp3versadevelopmentkit/index.cfm http://www.latticesemi.com/products/developmenthardware/deve...

alecdibble 13y ago

I believe the next big jump in FPGA utilization will involve high-level synthesis. Verilog and VHDL are essentially analogous to assembly languages in terms of abstraction.

swah 13y ago
That will happen at the same time PS3 games are written in Haskell instead of C++ :)
anon859486896 13y ago
I think that is true, but I think there is another problem as well. There is no, to my knowledge, equivalent of GCC for an FPGA, and by that I mean a free, open source, cross platform synthesizer. You are stuck using their tools, and they are generally suboptimal at best when it comes to the IDEs at least. I think one of the main problems is that it is the FPGA manufacturers that also provide the toolchains, and that is your only option. Edit: Also, forgot to add. I am not sure FPGAs are that ameniable to using higher level languages simply because you can make a trivial adjustment to your code and resource usuage will jump from 1% to 27%, which is not trivial. It used to be the same with your normal CPUs, every cycle counted, this will improve with time of course.
kryten 13y ago
I was using Xilinx FPGAs in 1998 and they were saying next year then for such a thing. It's 15 years later and it's still the same with shitty overpriced tools, per-vendor ghettos and crazy per-unit prices. Granted we've got a couple of ARM cores instead of a single PPC 603 and a clock speed ramp but that's it. If they snap out of that crap, perhaps, one day we'll reach utopia. Then again, fucking rich engineering companies over for wads of cash is better for business.
- sliverstorm 13y ago
  I don't know that it's by choice. The market is small, and the problems are not easy. Software compilers have had tons of effort, money, and mathematical knowledge thrown at them for the past several decades. HDL-to-FPGA synthesis and place/route on the other hand has been driven by only a few companies, and hasn't been around nearly as long.

namank 13y ago

Programmers don't give a crap about the reasons mentioned in the post. So, if FPGAs do take off in the dev community, it'll be for different reasons. Such as when 80% of the world's code can be, with accuracy, can be parsed into HDLs.

VikingCoder 13y ago
I'm a programmer, and I care about delivering great performance at reasonable price to my clients. If I had a set of problem in an application where an FPGA would benefit the customer, I'd seriously consider targeting one.
- namank 13y ago
  Would you trade off developer time to figure out how many registers to use, how many pipeline stages you want every single time you need to write code? How many of your developers are apt at figuring that out? And that's a decision you have to make every time you want to add a feature because FPGA architecture is, more often than not, dependent on the business logic you want it to encapsulate. It's cheaper to get an Arduino instead. FPGAs look very attractive when you're used to comparing C#/Python/Java/everything to C but that fades away as soon as the complexity in managing code on FPGAs comes to light. All the points mentioned in the article under "performance"? It's left up to you, the developer, to configure the board in such a way that you can leverage them. And that's before you've written a single line of the business logic. In theory, FPGAs give you the power to code your business logic as circuits (making it monumentally faster) but in practice, the story is very different. You may want to look at High Frequency Trading - they use FPGAs for stock analysis there.
  - whatshisface 13y ago
    When you need an FPGA, you need an FGPA. I don't think anyone would spec out one gate at a time if C and an operating system could cut it.
    - namank 13y ago

tim_hutton 13y ago

More context about how FPGAs compare with GPGPU: http://blog.streamingcores.com/index.php?/archives/20-Programming-massively-parallel-systems-FPGA-vs.-GPU.html http://blog.streamingcores.com/index.php?/archives/20-Progra...

vasco 13y ago

There's a lot of good information in the article for software people for whom hardware design is strange but I think the author makes some strange points. For starters, its strange to have him refer to Verilog as a programming language multiple times all over the article. Anyone that has ever tried to do even minimal stuff on hardware will know this the wrong way to think about things. Verilog, VHDL and whatever other hardware description languages should not be approached as programming languages, or you'll have a bad time. You need to think about what you are generating. By using HDL's we have the ability to avoid messing with crappy interfaces where you drag chips and connect wires by hand, but ultimately you really need to know what's being generated. If you write a couple of lines and have no idea of the hardware behind it, you'll likely be making a lot of mistakes. Everyone that has tried messing with FPGA's without thinking about this has ended up with hundreds of generated latches among other niceties... There's already some degree of syntactic sugar on VHDL processes (or verilog @ blocks) which make it really easy to shoot yourself in the foot by abstracting stuff. Ultimately you'll want to know what's going on rather than not. Hardware is hard, but when you need the performance you'll do it the right way, or you might as well save yourself a lot of trouble and just go with a beefier machine and some optimized C code.

schabernakk 13y ago
yup. I worked on a simple game AI (Connect6) for a university project implemented in Verilog. Initial prototyping in python was super easy and quickly done, translating the same program to Verilog took multiple weeks. We split the program up into multiple modules with each module handling different cases. While writing the program we only compiled it with the modules we were currently working on and even that took long enough (remember: we were trying to more or less directly translate the python program to verilog with a bit more global state). Once we finished we tried to compile the whole program with each module enabled and it compiled and compiled and compiled. We aborted after 20 hours of compiling and no end in sight, the design we were using was just not suited to be used with hardware. Now, this was the first time ever I worked with hardware and while I really liked having something tangible and all those nice blinking lights on the fpga board, programming one was a pain in the ass. Towards the very end of the project I slightly got the hang on how you should approach writing such software. And the most important thing is to not think like you would when programming traditionally. Designing and later implementing a FSMD for example is far more efficient.

Jemaclus 13y ago

It'd help if someone defined FPGA before the 12th paragraph... I like to learn things, but when you start out assuming I know what the acronym means, then you lose me before I get to the good stuff. :(

whatshisface 13y ago
Field-programmable gate array.
- Jemaclus 13y ago
  Yeah, I got that at the 12th paragraph. :(

taylorbuley 13y ago

Here's the FPGA from Adafruit: http://www.adafruit.com/products/451 http://www.adafruit.com/products/451 At the time they wrote "we searched around for a fpga board we really liked, here's the one we picked" (https://plus.google.com/+ladyada/posts/VZ1zyTF73oM https://plus.google.com/+ladyada/posts/VZ1zyTF73oM) Here's an example demo using that hardware: http://learn.adafruit.com/fpga-rgb-matrix/overview http://learn.adafruit.com/fpga-rgb-matrix/overview

fnordfnordfnord 13y ago
Source for that is Terasic http://www.terasic.com.tw http://www.terasic.com.tw They do reference designs for Altera, and have quite a few neat dev boards.

zw123456 13y ago

I think the author makes a number of good points. I think in the future, it may be possible for machine code to be converted directly to RTL (the equivalent of machine code for FPGA's) without going through the intermediate steps of converting C code to a multi-state machine in Verilog or similar types of coding. If this happens then a CPU or OS, could use an FPGA as a Co-processing Cache of sorts, in the same way that often accessed data in placed in higher speed cache RAM; often executed pieces of code could be placed in the FPGA co-processor. If that happens, I believe we could see the same kind of order of magnitude jump in performance we see due to memory cache happen in processing speeds.

bhb916 13y ago

This is a solid article. I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. In my mind, it is an easy way to expand your breadth of knowledge and make you a touch more valuable to future employers. They say that when all you have is a hammer, everything looks like a nail and I'm certainly inflicted with that same disease as I see the utility of FPGAs everywhere I look. Prices have plummeted while densities have skyrocketed. A simple $25 part gets you quite a bit of fabric and some $90 eval hardware will give you a sweet little platform. [1] With that said, since I began working with them there have been two "Holy Grails" of FPGA design: (1) Partial Reconfiguration and (2) High Level Synthesis. The first, Partial Reconfiguration, has been more-or-less solved although the tools have a long way to go. One current design I'm working on loads it's PCIe endpoint and DDR3 controller first, establishes communication with the application running on the host PC, then based on user input loads the rest of the FPGA. The second, High Level Synthesis, isn't here yet. The goal is to turn a company's vast army of software engineers into FPGA programmers overnight. A worthy cause. Every foray into this field has failed (although the jury is still out on Xilinx's purchase of autoESL) Honestly, I'm not sure it will ever get there. The point of optimized, custom hardware is to make use of it. Abstracting it all away seems counterproductive, not to mention very hard. [1] http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9.htm http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9....

dualogy 13y ago
> I see the utility of FPGAs everywhere I look Examples?
- jff 13y ago
  I see the utility anywhere a simple, repetitive task is performed with interaction from the physical world. The canonical student example is the soda machine. Sure, you could put a small Linux system in there and write Python code, but then you have millions of lines of Linux and Python code underlying your simple little soda vending code. Instead, you describe the problem as a state machine and implement it in the FPGA. This gives you an instant-on solution. I often find myself looking at the behavior of basic systems like automatic doors, card readers, thermostats, and motion-triggered light switches, thinking about their behavior and how I might describe it as a state machine. Thinking about what combination of inputs and outputs, what sensors and actuators would be needed to perform the task. It's fun.

mncolinlee 13y ago

GPGPUs have been a lot more interesting with the rapid pace of development in recent years, but there are still software optimizations that are only feasible on an FPGA. They're one of the most interesting pieces of hardware a programmer can use to develop high-performance hacks. When I worked at Cray, our team found numerous ways to make them useful. I've been meaning to pick one up for a long time.

nwhitehead 13y ago

This article reminds me how much fun it is to program an FPGA. It's one of those mind-expanding exercises like learning logic programming or writing a purely functional persistent data structure. "Describing hardware" is quite a different way of looking at computation. In case you want to try, I had good success playing around with the Altera DE2. It's got lots of "goodies" on the dev board and there are lots of existing class projects, class notes, etc. that use it. It's fun to get your own tiny CPU working and have it flash HELLO WORLD on the LCD display. You have to worry about bugs in your CPU as well as bugs in the program running on your CPU.

rwg 13y ago
The downside of the DE2 boards is that they're really stinking expensive if you don't qualify for the academic pricing. I'd love to have a go at Verilog and/or VHDL, but I'm turned off by all of the sub-$100 FPGA dev boards because they basically just break out all of the FPGA's I/O pins to 0.1" headers and leave doing anything useful (as far as I/O goes) as an exercise for the reader.
- daniel-cussen 13y ago
  There's the Mojo at kickstarter. http://www.kickstarter.com/projects/1106670630/mojo-digital-design-for-the-hobbyist http://www.kickstarter.com/projects/1106670630/mojo-digital-...
  - duskwuff 13y ago
    …which only has a single button for input, eight LEDs for output, and a couple comm lines with the AVR. Everything else is just broken out to headers.
- snom380 13y ago
  How about this? http://dx.com/p/fpga-ask2ca-8-diy-learning-development-board-blue-black-217979 http://dx.com/p/fpga-ask2ca-8-diy-learning-development-board...
- zhemao 13y ago

Symmetry 13y ago

I've heard that there's been some progress in compiling Haskell to Verilog, but I don't know how far that effort has gone. Certainly more declarative languages seem much more suited to this than imperative ones. I have no idea how practical this is at the moment, though: http://cufp.org/conference/sessions/2012/peter-braam-parallel-scientific-awesome-haskell-fp http://cufp.org/conference/sessions/2012/peter-braam-paralle...

amirhirsch 13y ago
http://www.bluespec.com/ http://www.bluespec.com/ was based on Haskell. Polymorphism is awesome for FPGA design: it is incredibly satisfying to quickly turn a fixed-point FFT to floating-point and see the area/speed/power difference from the FPGA synthesizer

micheljansen 13y ago

I think the increasing popularity of functional programming or at least less imperative-style programming is making FPGAs more accessible. I remember my first brush with VHDL during my first year of CompSci and having a hard time adjusting to the fact that what you are writing is not a program that is executed step by step (whether line by line or instruction by instruction), but a description of hardware components/functions that all "run" simultaneously. Now that my brain is more comfortable thinking in terms of functional solutions, this all makes a lot more sense, but I haven't revisited FPGA programming since.

_yosefk 13y ago
Functional style indeed works fine with simple data flow graphs, but once you start fiddling with RAM you're back to imperative nightmares from hell (unless you're wielding a sufficiently smart compiler that I haven't seen, of course.)

twasfm 13y ago

This is written by the C++ FQA guy which is an amusing and honest look at C++

DennisP 13y ago

This may be a dumb question, but would FPGAs be a good choice for neural networks? Or is a GPU already ideal for that?

_yosefk 13y ago
There are academic people mapping neural nets on FPGAs; I'd expect FPGAs to do better if you manage to use integer arithmetic.
sporkologist 13y ago
Looks like they scale easily in parallel from what I read. Here's a book on it: https://www.springer.com/engineering/circuits+%26+systems/book/978-0-387-28485-9 https://www.springer.com/engineering/circuits+%26+systems/bo...
kyzyl 13y ago
Both can be made to work quite well for various ANN implementations. Currently GPGPU is a lot more popular because it requires far less hardware knowledge to get going, which translates into much quicker development cycles. For example, the boom of deep learning which has been going on since ~2002 has been largely couched in the massively parallel training of neural networks on GPUs. Some clever folks have written libraries like Theano, which allows you to create computation graphs in python that can be compiled, targeting either CPU or GPU. In principle FPGAs can be an extremely attractive option, because a well designed implementation could run very fast as scale very well, given that their massively parallel architecture lends itself to the parallel nature of ANNs. A few groups have gone to lengths to implement, for example, a Restricted Boltzmann Machine architecture directly on FPGA, and in raw benchmarks it works well. However, you start to run into practical limitations if you try to apply those archs to real-world problems, because all but the most expensive FPGAs have trouble fitting very large neural net architectures on-chip. Furthermore, the data required to train the nets is often too big to fit in RAM on the chips, meaning you're left with network or SD-card type approaches, which can be cumbersome and slow. I can recall at least one instance where the design explicitly addressed this issue by designing the architecture to be distributed over many hardware linked FPGAs, but even then you still run into the usual parallelism and concurrency issues: you need to balance parallelism overhead against speedups, you run into synchronization issues, and things can become non-deterministic and very difficult to debug. The bottom line is that it doesn't look like neural network FPGAs or ASICs are there yet. I'm sure there will be more exploration of this space in the future. As it stands right now, neural network training is dominated by GPGPU implementations.

ChikkaChiChi 13y ago

Are they referring to FPGAs in a mass-production/manufacturing sense or for the hobbiest/garage hacker? I guess I'm unsure why I would use an FPGA over say an Arduino microcontroller.

VLM 13y ago
"I guess I'm unsure why I would use an FPGA over say an Arduino microcontroller." Its unfortunate no one replied. First you upload an arduino reference design into the FPGA and continue working normally. This takes up about 1% of the FPGA gates, and leaves about 200 unused I/O pins (depending on FPGA device of course) and it probably runs faster than the real thing. (It also probably draws about 10 times the current...). Next, instead of you writing a bit-banged I2C interface, you download, include, configure, and synthesize a smart semi-intelligent I2C peripheral into your synthetic arduino on a I/O pin that doesn't exist in the real thing. Now your arduino source code to debug shrunk by perhaps 200 lines and the I2C is faster. Now your FPGA is 2% full and 98% empty. Hmm, what if instead of polling that pin in my arduino and/or going interrupt based, I simply included a whole picoblaze CPU core to do nothing but baby sit that input pin while outputting the correct servo signal... And the arduino sets it up and controls it as a very smart peripheral. Well, download, include, configure, synth, upload... Now your FPGA is like 7% used and 93% empty. Eventually your virtual arduino does pretty much nothing but UI. You can replace that with a CPU core of your choosing and OS and language of your choosing, simply upload it instead of the virtual arduino. Repeat a zillion iterations and thats how you started with an arduino and ended up with a MIPS UI written in C++ (why? Why not?) controlling a 8051 based thermostat coprocessor using a smart I2C controller to talk to the temp sensor and a smart servo pulsetrain generator to automatically make the servo signal. Or perhaps it gradually iteratively moves from an arduino to what amounts to a specific model of the MIPS based Microchip PIC32. Why? Who knows maybe you want a single chip $3 solution instead of an $30 arduino solution, or a $300 FPGA solution. Because your FPGA model of a PIC32 is pretty close to the real thing, the porting of your software from the virtual PIC32 to a real PIC32 only takes 15 minutes or so... So you end up not actually using a FPGA in the final product even though it started with an Arduino and ended up on a PIC32.

mrmagooey 13y ago

Now someone should open source a verilog tcp/ip and http stack, and maybe benchmark it against something like varnish.

deleted 13y ago

[deleted]

Jach 13y ago

MyHDL plug: http://www.myhdl.org/doku.php http://www.myhdl.org/doku.php Don't use Verilog or VHDL, use Python and compile to both while avoiding Verilog's pitfalls! http://www.sigasi.com/content/pitfalls-for-circuit-girls http://www.sigasi.com/content/pitfalls-for-circuit-girls

marshray 13y ago

FPGAs aren't going to take off until there's an open source toolchain to program them. Sure, vendors provide free-as-in-beer licenses for their smaller chips and one-off development boards. But the generally useful version will set you back $2 - $3K.

astrodust 13y ago
This has been the biggest pain point for me trying to use the MojoBoard (http://embeddedmicro.com http://embeddedmicro.com). It's a decent FPGA, but the tooling is entirely reliant on the Windows or Linux ISE program and you're almost entirely dependent on the IDE. The "loader" is disjointed from the compiler, too, as the loader is board specific. If there was an open-source FPGA core with an open-source compiler, it'd be a lot easier to work with these things.

e12e 13y ago

It's interesting to see how this fits with Chuck Moore's idea of miniature Forth computers: http://www.greenarraychips.com/home/products/index.html http://www.greenarraychips.com/home/products/index.html While not equivalent to FPGAs it does seem like a natural direction if what is desired is similar performance, but with more higher level tooling. That eval board/chip is for instance able to drive VGA using parts of the resources, leaving the rest for other stuff: http://colorforth.com/video.htm http://colorforth.com/video.htm

_yosefk 13y ago
Verilog is higher-level than a bunch of nodes talking only to their neighbors and having a tiny amount of RAM, by far...
- kragen 13y ago
  I think the key difference is that there's already a whole lot of stuff available in Verilog from opencores, and basically nothing for the GreenArrays chips beyond what comes with them. It might be feasible to compile Verilog to the GA chips, but sadly, they don't seem to be working on that. But I don't think you can so easily make a "higher-level"/"lower-level" distinction between the two. On one of the GA cores, you could quite reasonably execute a recursive algorithm — as long as it doesn't need more than 64 words of RAM — in a few lines of code. You can do runtime code generation. You can execute extremely irregular algorithms almost as easily as extremely regular ones. But I think their failure to be compatible with anything else has doomed them.

ctdonath 13y ago

Identical articles were common 15 years ago.

InclinedPlane 13y ago

Just wait. When memristor technology matures it should be possible to create FPGA-like devices with feature density and clock speeds similar to ASICs (e.g. gigahertz, gigatransistors) with reconfiguration times on the same time scale as memory writes. That ought to cause some fairly significant ripples in computing.

kragen 13y ago
Hmm, I think memristors failed. The devices HP is promoting as "memristors" now have nothing to do with their original memristors. I don't know why. Maybe the devices started to fail after 100 write cycles or something; totally plausible for physics that depend on ion migration. Maybe someone will invent a new device that does what their original memristors did, but in a form that can be brought to market.

guiomie 13y ago

What would be a good approach to implement a web server in an fpga ? (verilog or vhdl? xillinx or altera? ...etc) It is something I have been thinking a lot lately.

_yosefk 13y ago
Run on the on-chip CPU :) (Which bits would you want to implement in Verilog? As to Verilog vs VHDL - Verilog, always :)
- VLM 13y ago
  Correction that I'd use the on-chip CPU and make the on-FPGA ethernet controller smarter and smarter over time until the on chip CPU isn't doing much other than telling a terrifically smart TCP accelerating ethernet interface to look at a certain array every time someone connects to port 80. Doing that in one jump would be pretty dumb. I'd start with FPGA "hardware" acceleration of ethernet header checksum. Then start accelerating the IP headers. Then start accelerating the TCP headers.
- jonmrodriguez 13y ago
  Maybe you'd want to write a super-fast template language evaluator. And give it the ability to call database queries.

vishal0123 13y ago

> No need for a full cycle for simple operations: on FPGAs, you don't have to sacrifice a full cycle to do a simple operation, like an OR, which has a delay much shorter than a full cycle. Instead, you can feed OR's output immediately to the next operation, say, AND, without going through registers. You can chain quite a few of these, as long as their delays add up to less than a cycle. With most processors, you'd end up "burning" a full cycle on each of these operations. This may be a dumb question, but how do FPGA execute multiple NON-PARALLEL simple instruction in 1 cycle. I always thought a cycle is undividable and can be used only for a single instruction.

bhb916 13y ago
That's not a dumb question at all. The answer is simple: by cramming for logic in between registers. Since you (or at least the tools) are in complete control of the routing, you can place as much logic as you would like between registers, thus accomplishing everything in one clock cycle. The trade-off, however, is that every level of logic adds delay to the path and you can't clock your registers any faster than the sum of all the delays allows (with some exceptions). This simple diagram sort of demonstrates the concept: http://m.eet.com/media/1176731/sync-vs-async-01.gif http://m.eet.com/media/1176731/sync-vs-async-01.gif

swamp40 13y ago

Somehow managed to get thru 20 years of hardware design w/o yet using an FPGA. Keep looking at them (esp. the IGLOO series), but keep finding some better suited or easier to implement alternative.

jwr 13y ago

The problem with FPGAs is that they are a niche technology that is unable to exit its niche. As someone who used FPGAs in a hardware design and regretted it later: there are two major problems with using an FPGA: * it is too expensive for cost-sensitive devices, * moving data onto and out of the chip is and always will be a problem. Now, as to #1 above, you will hear FPGA enthusiast say that prices are just about to fall as more and more devices are produced. But I've heard such claims since at least 1998 and so far this simply hasn't happened. As to #2, the number of MAC operations is irrelevant if you can't supply the chip with data. This is something even modern GPUs have trouble with, in spite of the monstrous bandwidth of the PCI slots they are placed in. Most algorithms will need to move data in and out, and use intermediate storage. Once you do all that, you end up with an expensive and complex design, that doesn't perform all that well anymore, and that is a pain to program and debug. Also, if what you're doing is high-performance computing, then you have to compare the expenses with just getting a larger AWS instance or a cluster. As a result, I tend to advise younger programmers to learn about FPGAs, but not become obsessed with them, as they are very rarely the right tool for the job. I'd even say they are almost never the right tool, except in very rare circumstances.

digikata 13y ago
FPGAs are also stuck in a lot of niches. Economically, any high volume application where they could useful also means that putting an investment into more custom silicon is then feasible to get a better price margins - ASICs, DSPs, or I recently learned a bit about metal-gate arrays which seem to be mid-way between FPGAs and hard silicon designs. They're stuck in a power niche because they're comparatively high power vs many embedded ICs, and if you're using a lot of power, as you said more desktop chips are economic to apply.
_yosefk 13y ago
With modern FPGAs, you have the CPU on the same chip, which means you can use just one chip and then it's OK for cost-sensitive devices - and your problem of moving data across chips is gone as well. I'm not an "FPGA enthusiast" myself - I work in chip design and Xilinx is a direct competitor. I think FPGAs have their share of problems preventing their adoption and I'll write a follow-up to elaborate. But the problems you mention are between solvable and solved. (BTW it's true for GPUs just as well: just integrate them on the same chip, and forget about the PCI slots. Every high-end to mid-range cell phone has done it a long time ago.)

ChrisNorstrom 13y ago

(By the way, FPGA = Field Programmable Gate Array)

xradionut 13y ago

Software Defined Radio is a good FPGA application: http://www.srl-llc.com/ http://www.srl-llc.com/

shaurz 13y ago

I bought one, never got around to using it, and sold it a few years later. Like a lot of cool technology, it will go underused due to difficulty of use / lack of good, easy-to-use applications. And for all the things I want to do, it's easier to just write software.

VLM 13y ago

There are aspects of the whole technology that were avoided in the article, or edited out for length, or whatever. Regardless of reason, here's some filled in blind spots: One important ignored aspect is you can treat the FPGA as a magic universal microcontroller. Oh, you need 3 UARTs now, I'll INCLUDE another at a different I/O addrs. And you'd like a CANbus now? No problemo in 10 minutes you'll be programming on the same hardware now with a CANbus. Oh you don't want to use a Z80 anymore, fine I'll compile the FPGA to be some pic variant in 5 minutes, or a microblaze, or whatever you want as a CPU core. As long as you slowly successively approximate real available microcontroller hardware, you can ease the eventual port off the FPGA to some microcontroller hardware that costs $1.50 in qty instead of $15.00 in qty. Its a lot easier, faster, and cheaper to upload a bitstream to a FPGA than to solder in a different microcontroller hardware. This makes device selection during development much less critical/scary. You don't have to sit in paralysis wondering if you need 3 or 4 I2C busses. Another thing is not mentioning the open development community. Most HN readers probably hang out at github. The place where most FPGA folks hang out is opencores.org. People who exclusively hang out on github are going to wonder why "no one" is using FPGAs and theres "nothing out there" and "not much activity". Well come on over to opencores and you'll get more than a lifetime of entertainment ahead of you, for free... Its like going to CPAN and hanging out with CPAN people and wondering why "no one" uses Python. Looking in wrong spot. Need a more target rich environment. You can do a lot of "stuff" with FPGAs as the underlying technology without doing much of anything with HDLs. Much as I once programmed on a Silicon on Sapphire CPU a long time ago, but the underlying technology simply didn't matter at the assembly language level. I'm sure it was very exciting on the factory floor and in the R+D labs, but I wasn't there, so I didn't much care. In a similar way you can synth up a perfectly good 6502 and give it twenty semi-intelligent ethernet interfaces without too much HDL effort and then just do your "software thing" on the synthesized device without touching the HDL. Tying it all together, you'll get people outside the community reinventing the wheel, trying to slowly and methodically invent the concept, purpose, and implementation of the WISHBONE interconnect bus standard or something like that. Well, all that stuff got figured out and implemented inside the community like a decade ago, so... Much like the old saying about people refusing to use unix inevitably end up poorly reimplementing it.