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