[bhb916]

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....

[lambda]

The last time I looked into FPGA programming (probably back when I was in college), the cheap eval hardware cost at least a few hundred dollars a board, if not a few thousand. For something that would just be a toy to play around with, it was too much to justify spending money on.

On top of that, the tooling is all proprietary, clunky, with obnoxious licensing. If you notice, that eval board you pointed to comes with "ISE® WebPACK® software with device locked SDK and ChipScope™ Pro licenses". I'm just not interested at all in any "device-locked SDKs".

And finally, there's a bootstrapping problem. FPGAs aren't really a mass-market platform, because no one has them (unless they're developing custom hardware).

If there are now $90 eval boards, that solves part of the problem. Another big step would be building a reasonable toolchain around it that does not consist of big clunky proprietary tools with onerous licensing.

And finally, someone will need to start shipping FPGAs with a standardized interface on commodity hardware. If I can depend on their being an FPGA in a phone, in a workstation, or in COTS server hardware, there are lot more possible applications. As it is, you already have to be building your own hardware before an FPGA is something you would want to target at all. The vast majority of programmers write code to run on COTS hardware (servers, desktops, mobile), not custom hardware.

[tlrobinson]

And finally, someone will need to start shipping FPGAs with a standardized interface on commodity hardware.

If Apple included an FPGA in their machines with some cool sounding marketing name like Particle Accelerator™ it would probably catch on.

The last time I looked into FPGA programming (probably back when I was in college), the cheap eval hardware cost at least a few hundred dollars a board, if not a few thousand.

Not sure when you were in college, but we used FPGAs in my upper level computer engineering courses, circa 2006, and the Xilinx dev boards we used were about $120.

[woodchuck64]

> Another big step would be building a reasonable toolchain around it that does not consist of big clunky proprietary tools with onerous licensing.

While I think a toolchain other than Xilinx or Altera is out of the question due to technical complexity, Quartus Web Edition is free and supports the low-cost Cyclone devices including the ones with ARM cores (SoC): (pdf) http://www.altera.com/literature/po/ss_quartussevswe.pdf. I imagine Xilinx has something similar.

> And finally, there's a bootstrapping problem. FPGAs aren't really a mass-market platform, because no one has them (unless they're developing custom hardware).

Yes, that's the chicken/egg problem that both Xilinx and Altera are addressing by putting ARM cores on their devices that run just fine without any FPGA configuration at all. It's an appeal to software developers while pitching the FPGA hardware as a super-special add-on feature really cool to have for ... something.

Altera has just started shipping the first SoC devices I think, about 6 months or so behind Xilinx. Now we'll see if the strategy works...

[VLM]

The problem with eval boards is the tendency to explode price upward by sticking peripherals on the board. Sure, a 10/100 ethernet intf sounds cool and it'll only add $5... times 50 other devices and next thing you know you have one of those cool, but expensive Digilent boards that has more I/O options than you could ever use, but costs $200.

If you just want a nearly bare FPGA google for "micronova fpga mercury" and for $60 you get a DIP-64 circuit board with quite a few I/O and that's about it. No on board graphic LCD. No on board VGA output jack and D/A interface. Think, the basic stamp from 20 years ago, now a FPGA dev tool. I have one sitting on my desk waiting to fool around with it (I have a lot on my desk...)

Also all the software is free now. Maybe limited such that you need a license to synthesize for a $2000 chip, which doesn't matter. Pretty much if your average garage hacker can afford the dev board, the limits on the software don't matter. Closed source, but available for linux and windows and free.

[jbester]

Papilio one and papilio pro are both under $100

Vendor - https://www.sparkfun.com/products/11158

OEM - http://papilio.cc/

[olouv]

You can have a small FPGA test board here http://be.eurocircuits.com/shop/offtheshelf/product.aspx?&an... for 60€. The tutorials (non-free) can be found there http://www.elektor.com/magazines/2012/december/taming-the-be...

[lambda]

That only addresses the one point (expense of the test boards), which as I pointed out, is the one major problem that has been solved (I consider a $90 dev board reasonably affordable for tinkering, so a $70 dev board is better, but not by much).

It doesn't seem to solve the other two problems, though I suspect that solving the second (lack of open tools) would go a long way towards solving the third as well (ubiquity of hardware available to target).

[rwmj]

The proprietary software is always going to be there (unfortunately).

The precise hardware layout of an FPFA is important for performance and a trade secret. Proprietary software algorithms can squeeze more out of the fixed hardware.

[dllthomas]

If proprietary software is why I'm not buying an FPGA (and if there are a lot of people like me) there will be much more to be made opening things up than keeping things closed. Not saying that this is the case, just that it could be, so "always" might be an overstatement.

[rwmj]

I hope you're right, I work at Red Hat after all.

However I still don't think it's likely. The trouble is this is all tied to the hardware. FPGAs are integrated circuits with a complexity and development cost close to that of CPUs. (The fact that you can only use about 4% of the density of the FPGA is beside the point here). Because of this huge barrier to entry -- building your own fab -- we don't have fully open source x86-compatible high end processors, and we don't have open FPGAs either.

As long as the hardware is closed, the software for doing FPGA design is also going to be closed, for the reasons I outlined in my comment above.

[dllthomas]

Yeah, it's more hope than expectation; it just seems unlikely not absurd though.

[Brashman]

If you're interested in a non-proprietary toolflow, you can try taking a look at VPR (http://www.eecg.toronto.edu/vpr/). It's an academic place and route tool out of the University of Toronto. You may still need to use some parts of the proprietary toolflow. I've never used it to actually run on an FPGA, but it's a popular tool for academic research in FPGA design and EDA algorithms.

[Florin_Andrei]

http://www.adafruit.com/products/451

[robomartin]

> I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general.

While I appreciate your sentiment, it isn't programming, it's hardware design. To do anything beyond the somewhat trivial you need to learn a pile of EE stuff. Thinking of FPGA's as software might be nice, but that's not reality. Some examples of this are signal integrity, metastability, transmission lines, propagation delays, timing closure, SSO, etc. And that's the tip of the iceberg. You can't just shove in a 600MHz clock, write something that looks like software and expect the darn thing to work. I once spent nearly three months chasing a 3 nanosecond timing problem on a complex design. The "code" was perfect. It was a layout, routing and timing problem. FPGA's are not software.

Of course, this is assuming an EE has done the hard work of designing a solid board with all the right I/O, interfaces as well as the all the initialization and setup files. Again, as an example, a DDR3 bank is not a trivial piece of hardware to design, layout, interface and configure.

None of this is to say that it is impossible for a non-EE to learn and become quite capable at developing with FPGA's. however, this isn't just like learning a new programming language. I'll venture a guess that most programmers would have trouble committing to going down the deep and twisted rabbit hole they'd have to navigate. Again, not impossible. Seen it done. But it isn't software and it requires serious dedication.

[_yosefk]

I agree about the pile of EE stuff, but it's not unlike having to learn a pile of math to work on, say, graphics; it's two areas into which programmers can naturally branch out, but it's not trivial.

And yes, you'd need EEs around; you'd need artists around to ship nice graphics, ultimately, or you'd need to be one yourself. Another angle - to be really good at C, you basically have to be fluent in assembly, at least in reading it, so you could say that C isn't just another language, or "C isn't a high-level language, it's a portable assembler", analogously to "FPGA isn't software, it's hardware design." In reality there's a continuum between hardware and software design, as there is a continuum between programming and math, programming and art, high level languages and low level languages, etc.

[robomartin]

Well, we might have to disagree. Implying that it is just a matter of math is almost like saying that any programmer could just walk in the shoes of an EE by just doing some math. Which, of course, isn't even remotely true.

I have a high-school age kid. I taught him Java, C and chunks of PHP. He's already written a half dozen simple games. All of that in about a year of sporadic time. Now I am gettimg him started in electronics. The road ahead is far more difficult than learning to program in any language. Buying Arduinos isn't knowing electronics. There's a vast difference between using an Arduino and designing one. And, BTW, that's relatively simple embedded stuff.

I am not saying that a talented software guy can't learn to design with FPGA's. Not at all. Talented driven people can do anything with enough motivation. All I am saying is that EE doesn't magically turn into software development just because one is using an FPGA. Examples of the complexity and range of disciplines required abound, things like thermal design, signal and power integrity are disciplines in and of themselves that are often the domain of specialized EE's in design teams. The first time I laid out a design with clocks ranging from tens of MHz to GHz, as an EE with excellent command of the science behind the task at hand, it took me months to get it right. That had to work perfectly before my FPGA design and embedded code had even the slightest chance of making the board go.

[lkozma]

I don't think he meant that EE is just a matter of math, but rather that branching out into EE can be thought of as analogous to branching out into math.

[epsylon]

> I agree about the pile of EE stuff, but it's not unlike having to learn a pile of math to work on, say, graphics

If you're thinking about CGI, honestly I'd say that the maths really isn't that hard. Most of it is basic linear algebra and a bit of signal processing.

I might be biased in saying that (because I have a solid maths background as well as a computer graphics one) ; but I've done a lot of electronics as well (including working on FPGAs) and I still feel that EE is a whole different world.

(Off-topic: I realized that you were the guy behind the C++ FQA. Thank you a million times for that! )

[schabernakk]

> I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general.

unsufficient tooling? I did some programming with FPGAs once and it seemed the best option I had for programming was proprietary software by altera (quartus). I never got debugging to work or perhaps I did and I didnt understand the stuff it was showing me (I am no hardware guy)

My impression was that an eclipse-like ide, perhaps with a built in HW simulator would make things A LOT easier, especially for beginners like me. Of course this could be completely unrealistic and impractical for hardware design in which case I will show myself out.

[_yosefk]

A free simulator (like iverilog) plus a free waveform viewer (like gtkwave) is a nice way to start fiddling with these things. Verilog is way - WAY - easier to deal with than say C, actually, because you have much more visibility (waves instead of a variable view) and much better error detection (none of those bloody memory overruns, built-in Valgrind with the "X" values, etc.)

I'm a programmer by training, and I got into hardware architecture in part because of how fun Verilog was, actually - seeing all this stuff.

Compile and run Verilog online (which is how I tested the Verilog code in the article):

http://www.compileonline.com/compile_verilog_online.php

Running on FPGA without testing on a simulator first can indeed be tough for a newcomer, I'd guess.

[jlgreco]

Eh, gtkwave is the sort of thing that I feel allergic to. I've used it extensively in the past but at no point was it something that I enjoyed having to use. Moreso than not liking to work with proprietary software, what I really don't like to do is work with non-browser/non-terminal based programs. Those sort of tools just really don't seem like tools that were designed with users like me in mind. If I have to work with programs like that then I of course will, but in my personal time that sort of program drives me away.

If gtkwave took some high-level inspiration from graphviz, that would be great.

Also, good god is GHDL horrific...

[simias]

I've started to learn hardware design a couple of months ago and this is good advice.

However I'd like to mention that many constructs work fine in simulation but are completely backwards/impossible to synthesize in FPGA or ASIC. Writing verilog is easy, writing good verilog much more difficult.

I don't know if there are any good and comprehensive resources for learning hardware design coming from a software background, I have the chance to work with some ASIC guys who can help me with those things.

[alok-g]

I seriously want someone to disrupt FPGA tooling.

In my understanding the tooling for FPGAs has been made purposefully complicated to achieve a lock-in. The issue is that adoption of new tooling practically requires compatibility with the existing tools from the two key market holders, and I do not think even they themselves could do that anymore.

[ChuckMcM]

Yes and no. So on the one hand there are lots of open source efforts at both Hardware Description Languages (HDLs) such as JHDL, variations on Systems C, Verilog, and the async work that was going on at Utah State I believe. But the "place and route" bits are, by their nature, unique to the FPGA architecture. Further there is a lot of work on encrypting bit streams so that designs can't be "stolen" and you end up with a very proprietary 'blob' at the bottom of the stack. Xilinx did an "open" FPGA for a while (the 3000 series) but nobody used it at the time in volume.

That said, the complexity of the FPGA tools is also as much about the circuit capabilities (describing IO pads for example in terms of their power levels, latencies, and connectivity) as it is about the overall complexity of the problem.

The methodology for designing these things is surely straining. And of course its a very test driven practice, since no hardware engineer ever seems to just "try" something in an FPGA until they have a testbench that can simulate it. (the equivalent of unit tests in software).

Most (all?) vendors offer a bit of a free stuff, and I know the Xilinx place and route engine can take its input from any EDIF source so you can write your own 'design' tools if they output EDIF. I'm a bit scarred because there was an effort called the "CAD Framework Initiative" which was going to standardize APIs between all the layers of the stack but once vendors figured out that their high priced tools could be easily disrupted they backed out of that standard in a hurry. Too bad really.

[marshray]

An industry ripe for disruption. My guess is that patents and military contracts are propping up the few entrenched vendors.

Eventually, the simple FPGA designs from 20 years ago will perform "good enough" when shrunk down to modern manufacturing processes. Only then will the new age of reconfigurable computing begin.

[shubb]

As far as I've seen, the main users of FPGAs are developers eventually targeting ASICs.

A video codec or whatever might first be implemented in C++, then 'translated' to verilog and tested thoroughly on an FPGA. Having solved all the logical issues, and detected a lot of potential timing issues, the HDL design could be translated into an ASIC design, and heavily simulated. Then, confident that the design is good, the company could spend the bucks to make a mask for mass manufacture.

You do occasionally see people using FPGAs where they need the zero latency of a hardware design, but only need a couple of devices. Usually this is in RF research labs and the like.

I suspect most people with compute problems would be better off using a GPU.

[marshray]

Perhaps. But I think we'll never know unless they can be fit within a mainstream software workflow at a reasonable price.

[_yosefk]

It's genuinely complicated; if Xilinx could disrupt Altera by making easier-to-use tools, it would. (In fact it tries with AutoESL.)

I hope to explain why FPGA tooling is intrinsically hard in my next write-up.

[amirhirsch]

here's a few good reasons why it's hard to make easy-to-use vendor-neutral FPGA tools:

- all the devices/bitstream formats are proprietary with little or no documentation of the logic blocks or programmable interconnect structures. it is probably technically easier to build a new FPGA from scratch and design tools for that, than to reverse engineer existing chips [1]

- there is very little cross-compatibility between vendor products (a 4-lut here, a 6-lut there, some carry-chain logic here, a DSP block there)

- all the optimizations (synthesis, place-and-route) are NP-hard problems

- sequential imperative (C-like) thinking is not the correct way to make parallel systems

- the FPGA vendors compete on tools and offer their software for free to push hardware. hard for an independent vendor to compete.

[1] some reverse engineering efforts exist. see "From the bitstream to the netlist" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117... / http://code.google.com/p/debit/

[mjn]

all the optimizations (synthesis, place-and-route) are NP-hard problems

I suspect this one in particular could be chipped away at pretty successfully if the tooling were less closed. When you get some open benchmarks and let both researchers and systems-builders hack away at it, you can get very good practical solutions to NP-hard problems, as the current crop of SAT-solvers, SMT engines, and TSP-routing tools attest.

[amirhirsch]

I wrote an post 5 years ago about how an electronic-design-automation-as-a-service company could sell access to a huge supercomputer for solving these problems faster: http://fpgacomputing.blogspot.com/2008/08/megahard-corp-open...

most researchers make up their own architectures to demonstrate place-and-route algorithms, for example there is this challenge to improve p&r: http://www.eecg.toronto.edu/~vaughn/challenge/challenge.html

[fieldforceapp]

Commercial "vendor neutral" tools do exist, Synplicity was a public company which sold such tools for several years before branching into proto board hardware sales and then being acquired by Synopsys [1]. Their tools for synthesis, partitioning and debug are still available [2] and strong sellers to both Altera and Xilinx FPGA developers.

[1] http://news.synopsys.com/index.php?s=43&item=570 [2] http://www.synopsys.com/Tools/Implementation/FPGAImplementat...

[alok-g]

While I find your comment informative, points 3 and 4 do not really explain why vendor-neutral tools cannot exist. Point 2 (my best understanding) should not be a breaking issue if documentation and specifications are available (which is covered by point 1). It seems to me that point 5 is part of the thing they have done to prevent alternative tools to come to market. Lastly, point 1 is exactly what begs for disruption.

[makomk]

The manufacturers also treat the exact implementation details of their FPGAs - how exactly all the routing fabric is structured, the fine details of some of the macros, etc - to be their secret sauce that gives them an edge over their competitors. So they're pretty hostile to the idea of documenting anything.

[bhb916]

It being "hard" shouldn't give them a pass on quality control. From the early Project Navigator to ISE to Vivado, Xilinx tools are buggy, poorly documented, and completely unintuitive. Yet, they're still better than Altera's.

[alok-g]

I had never used Altera. It's sad to hear that it is even worse!

[bhb916]

I moved one of our smaller projects over to Altera because they were first to 28nm plus the local Altera team was willing to help out with porting any device-specific code.

I was very disappointed with the tools. It's worth a write-up all on it's own, but my staff struggled through the tooling which consumed most of their time.

[mjn]

I'm waiting for Chuck Moore to release 2kb of Forth that he claims replaces the only parts you need...

[fnordfnordfnord]

Please do.

I have some opinions here and I wish I was prepared to make good comments. I've seen some horrible things. I hope you give it as thorough a going-over as you did in this article.

[alok-g]

@_yosefk: I am interested in this write-up. Will wait for it. Thanks

[DigitalJack]

The problem is a lack of overlap between software engineers and hardware engineers, particularly in the open source arena.

I'm a digital designer, and do software as a hobby. I've thought about writing up a guide to get into fpga hacking. Tools are always a hindrance. Simulation has some free tooling, but as far as I know there is nothing for synthesis.

EDIT: There is this https://code.google.com/p/vtr-verilog-to-routing/. It targets hypothetical architectures.

There could possibly be a kickstarter idea here to pick an architecture they have targeted and get some designers to implement this. You could even host one of these theoretical architectures on top of another FPGA. It'd be slower than the host, but feasible.

[_yosefk]

I think partial reconfiguration is actually vital - you can't do stuff without it - while C-to-Verilog is not. Though I've seen people loving AutoESL; one claim - always repeated about higher-level languages - is that you can explore more possibilities and thus beat hand-coded Verilog because of the time it takes to hand-code yourself into a local optimum while missing the global optimum. I sort of ignore the language question, because Verilog feels nice enough to me, though perhaps it's important in the sense that most programmers want C.

[lambda]

> most programmers want C

Hmm. I've always thought that most programmers want languages that offer more abstraction than C. C is probably about the opposite of what you want, since it's a fairly low level language targeting a fairly different model of computation than an FPGA. What you want is higher-level tools that are designed and built around this much more parallel model, not something that allows you to compile C to an FPGA.

In fact, I think that there would be a lot more interest in creating better languages and tools for FPGAs, if there were actually open documentation on the low levels of how to program FPGAs, so people could actually write their own tools targeting them. But most vendors seem to just provide their own Verilog compilers with onerous licensing restrictions, and there's little portability between hardware, so there's nothing really good to target.

[skaevola]

AFAIK C is by far the most prevalent language for embedded systems, which are typically the applications FPGA's are also used for.

[bhb916]

I agree with your assessment. PR is important to designers and system engineers and architects. C-to-Gates is important to business types.

[sliverstorm]

The best part of learning HDLs and other bare-metal experience, I've found, is it taught me to think in parallel and asynchronous frames.

[fieldforceapp]

>High Level Synthesis isn't here yet

Plenty of commercial development on that front recently. Forte Design Systems [1] is selling tools targeting both FPGA and ASIC design using a C++ class library front end (SystemC). Synopsys has two flows in their Synphony product line, one which synthesizes from C called Synphony C Compiler [2] and another flow based on Matlab libraries which isn't really synthesis per se but supports mapping between Matlab Simulink to FGPAs [3].

Use of these (including AutoESL) seem focused on certain domains. Image processing, cryptography and machine vision seem popular areas just now.

[1] http://www.forteds.com/products/cynthesizer.asp [2] http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/Synpho... [3] http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/Synpho...

[bhb916]

I find it interesting that Synopsys would attempt to compete directly with Xilinx's System Generator product. The latter is to my knowledge completely endorsed and supported by The Mathworks. Something to investigate ...

[fieldforceapp]

The comercial tools market is usually based around "flows," which is a fancy way to say they try to bundle their offerings. While Xilinx is primarily interested in an FPGA flow, Synopsys of course would be happy to help you retarget your design to the more expensive ASIC flows as well. In addition, Synopsys offers hardware prototyping & emulation. All of which means while there's competition with Xilinx (and Altera, and Mathworks too) each vendor is focused a different use case of FPGA's.

[damian2000]

I was lucky enough to be able to do a tiny bit of FPGA programming last year in Verilog. Its deceiving how similar to C it seems initially, then when you start getting into it how vastly different it is to normal programming. I remember thinking that everything is literally running in parallel.

[dualogy]

> I see the utility of FPGAs everywhere I look

Examples?

[jff]

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.

[Florin_Andrei]

> 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.

If it's indeed just a soda machine, you could implement it in a microcontroller and code plain C for the whole thing. The FPGA seems overkill.

Take Atmel for example. The Arduino boards are based on the Mega series. Fairly complex things (the ATMega microcontrollers), yet easy to program. I've played with the Tiny series - they're great if you don't need that many inputs / outputs.

http://www.atmel.com/products/microcontrollers/avr/default.a...

It's instant-on and very low power.

To me, an FPGA is better for real-time video scrambling and stuff like that.

[HeyLaughingBoy]

Exactly, and this is pretty much the answer to the OP's question about why software engineers haven't embraced FPGAs.

Answer; there are other solutions that are simpler and much closer to their existing knowledge base. You want to build a soda machine? I can implement that logic in an 8 pin, fifty cent Atmel tinyAVR device that can be programmed in C or C++

Skills of software engineers are probably better applied to building better FPGA toolsets.

[kragen]

You can probably also implement it in a PLC, which costs more than fifty cents but already includes the relays that you need to drive the solenoids that drop the soda cans and the darlingtons you need to drive the relays. Overall it might be cheaper and easier to program. The US$100 Phoenix 2701043 is the low end here: http://www.digikey.com/product-detail/en/2701043/277-2648-ND...

You might reasonably ask why there aren't 8-pin fifty-cent FPGAs. I don't really know, but some PLDs (not PLCs) come pretty close; http://www.digikey.com/product-detail/en/ATF16V8B-15JU/ATF16... was what I came up with on a Digi-Key product index browse: the Atmel ATF16V8B-15JU-ND, 84 cents in volume, a 20-pin Flash PLD with 8 macrocells, each with a flip-flop, 8 I/O pins, 10 input pins, and 10ns pin-to-pin latency. You can probably do a soda machine with 256 states. But an ATTiny has at least 1024 bits of RAM, which is a lot more than 8, and can do much more complex logic; it's just hundreds of times slower than the PLD.

A little higher upmarket, there are CPLDs like the 24-pin ATF750LVC-15SU-ND, which goes for US$3.72 in volume, with 20 flip-flops (bits of memory), 10ns pin-to-pin delay, EEPROM, 171 product terms feeding into 20 sum terms, and 12 input pins and 10 I/O pins.

For a while there was a Spartan FPGA that went for US$5, but perhaps due to a lack of articles like Yossi's here, it didn't do well and seems to be out of production.

Basically I think that when we're talking about state machines that are constrained to operate at mechanical speeds, it makes more sense to use the microcontroller approach — when your response times are measured in microseconds or milliseconds instead of nanoseconds, when you really only need one addition or multiplication per clock cycle instead of 8 or 100, you might as well do them one at a time and spend the extra real estate on more programmability rather than more computational power.

On the other hand, there are lots of computational tasks where it really would be nice to be able to do more ops per cycle.

[skaevola]

I guarantee the things you are thinking of are implemented in microcontrollers, not FPGA's. FPGA's aren't even that good at state machine type logic - they excel in parallel tasks which make the most use of each (longer) clock cycle.

[chinpokomon]

Similar to the NAND to Tetris article posted earlier, when I went through college, we built a microcontroller using Altera EPROMS. I had been programming for years prior, and understanding how the ALU could be performing many simultaneous calculations only switching the output based on the opcode, completely changed my perspective. The newer FPGAs sound pretty nice and significantly more capable than what I've worked with. Definitely something I'll keep in mind.