Cheap FPGA Development Boards: What to look for

Not exactly a dev board, and $500 price bracket, but possibly more practical for many: http://redpitaya.com/

If you want to interface with the real world it is great to get something where the analog part is done well. All the low level stuff already works.

Depending what you're doing, you might still have a better time pairing a high level ARM processor running Linux to a low-level ARM MCU running bare metal or FreeRTOS.

What kinds of things can you really do better/faster/cheaper on an FPGA vs, say, STM32 F4 series?

Its a good article in general with one very minor error. It explains you want on board LEDs and switches because its too easy to screw up soldering your own. The core reason why you want LEDs and switches on a FPGA board, why you'd buy included or solder your own, is too often during debugging this will be your UI.

So you are in a quandary about which of several PLL designs to implement. Its not 1990 anymore, you've probably got space on the chip to put them all in, and select which operates in real time using the switches. Then you wire up your spectrum analyzer or scope or whatever exotic test gear you require, fire it up, and instantly flip between implementations while its running. You figured it out in theory, now in practice which one actually has the fastest lock up, or the lowest noise performance, or the least noise spurs at critical freqs? Just flip the switches and find out.

And on the LED side, there's a lot of testing patterns that boil down to "and when the state machine hits this state, aside from entering state 8, it also fires the LED on a little timer" Again hook up all your real world hardware and see what happens.

True, you could implement a VGA display and PS/2 keyboard without much hardware work, but then you have to drive them probably with an embedded processor, a little picoblaze or whatever running the UI... and all that screwing around to basically re-implement LEDs and switches, just slower and harder to do.

There are in circuit analysis tools, some of them pretty cool, and some of them are actually reliable, but fundamentally you're always going to find some LEDs and switches, its just too easy and convenient.

There is also the "hello world" test proving your hardware and dev system aren't screwed up, everyone has their personal favorite, what I always use is a simple 3-input switch / 2 output LED full adder.

I've also been known to do things like output the version number of my project on the LEDs. Hey, they're just sitting there and everyone who's actually done labwork has had the amusing experience of thinking they're testing version 12 but finding out they uploaded version 11 or whatever.

Finally when the analog / hardware side isn't ready, if theres no timeouts and its a strict state machine, I've been known to flip switches as inputs, many millions of times slower than the real hardware works. Hand toggling switches to talk to an I2C slave or SPI is a little tedious, but sometimes the best option. Once you get past layer 2/3 type problems there's higher level protocol tools, some are even cheap like the "bus pirate" or you can send $375K to Agilent for slightly more advanced test equipment.

"STM32 F4 series"

You know how you start a microcontroller project with a "dream shopping list" of timers, I/O devices, memory, whatever features, then all the mfgrs have a giant table you scroll thru and then you trade off, "well, I need at least 3 SPI and 128K of ram, but they don't sell 128K ram with 3 SPI I need to buy a 192K to get my 3 hardware SPI, of course I could do two in hardware and bit-bang in software the 3rd...". Or even worse "I need at least three hardware PWM timers although they only need to be 24 bit, but the entire F4 series has exactly two 32 bit timers, oh knoes what am I going to do?" Even worse as the project changes over time.

With a FPGA you skip all that garbage and just synthesize in what you need. Oh I need 3 PWM timers, well, include three of them, no big deal. Wanna HDMI, if you can wire it in, you're good.

Ideally you'd put the "boring" parts of your software in the FPGA I/O device. If you're building a thermostat, why write the state machine in assembly or C, just use some mag comps and timers. Put the UI in the softcore processor.

If you're doin' it right, your UI soft processor need run no faster than a human, say 100 KHz clock speed. How fast can a human being hit a hardware debounced up arrow and read the LCD? If you're doing it wrong, you've got a softcore processor running multiply-add in software at 80 MHz and wishing for higher CPU performance.

There was an era of a couple decades which ends with FPGAs where its cheaper to throw in software than hardware, even throw in multiple microcontrollers. Why put in hardware schmidt trigger gates and resistors/caps to hardware debounce a switch if you can write 10 lines of code to do it in software? The hardware of the future will be a FPGA with exactly what you need and a very smart/advanced peripheral library. Why write 10 lines of buggy code to soft debounce a switch when you can just include some FPGA library code to get a perfect debounce with no race conditions or interrupt collision problems in the software, its just perfect.