FPGA Development Boards: The Universal Prototyping Tool?

Does anyone else immediately grab an FPGA evaluation board when they need to prototype something?

With the growing availability of expansion boards, like
the FPGA Mezzanine Card (FMC), it is easier than ever to create a target hardware platform on which you can begin development. The FMC standard (available here), allows up to 20 high-speed differential pairs supporting 10 Gbps signaling, four
differential clocks supporting 2 GHz signaling, 80 differential I/O or 160 single-ended I/O, user selectable I/O voltage standards, and Intelligent Platform
Management Interface (IPMI) programming and card information. Now FMC is primarily targeted at networking, but there are also cards for AD/DA conversion,
serial connectivity, and image processing. You can find just about any interface you need. If you can't, it's easy to create an add-on card from the FMC
standard.

Worried about prototyping a design that also needs an MCU? The newest generation of FPGAs seems to be converging on ARM as the processor of choice. If you
are comfortable with ARM as a target processor (who isn't these days!) you can prototype much of your code using the FPGA and then port to an MCU later (or
just continue using the FPGA as a production vehicle if unit requirements are in the low to mid range). ARM even has a common middle-ware platform that you
can use to decouple some of the hardware implementation details of peripherals and such so code migration is easier.

Well, this might sound good, but maybe you're thinking: "Don't I need to know all about FPGAs to do this? I'm an MCU expert, not an FPGA guru." You are in
luck. The FPGA vendors are targeting designer just like you! They all have an easy to use Architecture GUI that guides you thru the process of defining the
MCU you want to target. Have a specific ARM-based MCU in mind? Just define the peripherals and other architectural features using drop down and guided
selection processes. Press a button and you have a target MCU with example code, drivers and even ARM compatible APIs. Wow!

OK. Fine. But maybe you are now thinking: "But I want to use my existing MCU software development environment! I bet I can't do that." You would likely
lose that bet. Most of the FPGA tool flows allow popular MCU development environments (like IAR or Keil) to "hook-in" to their flow. You will need to learn
a new project management tool to manage the overall process but that is fairly painless.

"How about RTOS, OS, Middleware, and other 'canned' code. I don't want to reinvent the wheel!" Remember we are talking ARM here. That means you can access
the entire ARM ecosystem of pre-build functions, drivers, RTOS, Middleware, and debugging capabilities. Some vendors even have advanced profiling tools to
help with performance and power management.

@Ken: I've been looking at your Ahtlatl FPGA board and I think it's very interesting, especially when combined with all the support documentation and examples you and your students are working on -- I'm planning on looking into this further in the not-so-distant future.

Several of our customers, our engineers, and engineering students use FPGA boards to make quick prototypes and test fixtures. In some cases it's for a one-off prototype, demo, or as part of a production test system. In others, it's an application where the chosen processor simply "ran out of gas" and just didn't have the throughput required to handle the processing in a timely fashion. And sometimes we've used an FPGA board to provide a quick solution to a component obsolescence problem. That replaces the obsolete part with a current production part and uses the FPGA as an intermediary between the processor and the new IC. The FPGA emulates the software interface on the processor side and translates signals from the processor into those compatible with the replacement part. While adding an FPGA might seem expensive, modifying the software, retesting, and requalifying the system may be far more costly and time intensive than the cost of requalifying the replacement hardware. This is especially true in the case of an FDA approved medical device or other application which has similarly long and painful requalification cycles.

For our purposes, we needed a better way than using the various demo and eval boards, which always had stuff we didn't need, and were ususally too big or had inconvenient connections for prototyping. That's a major reason why we implemented a bare bones design for the Ahtlatl FPGA board we developped for OEM ans student projects. It has just an FPGA, power supply, USB / JTAG configuration interface, and two 50 pin 0.1" header connector postions. (See http://DIYchips.com and http://htevp.com ) The typical eval board I/O was left off the FPGA board and placed on a separate PC board, so that most of the FPGA pins are available to the user. The board was also designed with constant impedance traces placed for high speed differential signals and selectable logic signal levels on the two 50-pin connectors to handle level translation.

Overall, an FPGA board is probably the closest thing we've got to a "universal digital translator / adapter" between two digital devices that otherwise won't play well together!

I remember when the first FPGAs appeared on the scene. 8 x 8 arrays of programmable logic cells where each cell held a 4-input lookup table (LUT), register, multiplexer, and not much more. Applications for these little scamps where pretty much lmited to gathering glue logic and implementing simple stste machines.