Microprocessor and microcontroller development boards are powerful resources. They have a processor (of course) surrounded by a useful assortment of gadgets and gizmos for making whatever you build interact with the real world. You’ve got your processor, a power management IC (PMIC), some memory, a display (touch screen if you’re lucky), some audio gear – usually tied to a headphone and microphone jack, maybe an optional HDMI interface, and a 3-axis accelerometer (because…who doesn’t need one of those these days?)

You can connect to the outside world with things like USB, SD card slots, Ethernet ports, SATA connectors, JTAG, UART (You are going to debug, right?). And, you can usually drop in a copy of Linux, Android, or some flavor of embedded WIndows without too much trouble. Or, if you’re on the microcontroller side, you can probably be spinning a motor within minutes of opening the box.

Of course, development kits are not all generic. For just about any particular problem domain that you want to tackle, you’ll find a range of development kits tailored to almost-your-application. Chances are, they’ll come with a reference design/software that gets you 80% of the way to your design goal the first day. 

These development kits were designed for the software engineer who has at least some knowledge of hardware. You don’t have to be able to design a UART, but you need to know what one does. You will never have to decipher a timing diagram looking for race conditions or negative slack, or scratch your head wondering why your eye diagram is closed on your SerDes link. Even though those things may be essential to the success of your design, somebody else’s hardware engineers have already done all the work for you, scratched their heads in advance, and sorted out all the tricky bits. You need to know how to write software, how to use a debugger, and how to understand somebody else’s code. You most certainly do not need to know VHDL or Verilog.

Just about all the important work done with one of these kits is, therefore, software. Anything you can do in software with a suitably powerful engine is within your grasp. The board runs your software and gives you the resources to make it interact with the world. When you get ready to go to production, a hardware engineer can usually just take your development board, cross off all the things you’re not using to minimize the BOM, and you can be in production in the blink of an eye.

With all of that capability at your fingertips, the world is your oyster. You can build anything** you want. 

**almost

So, what can’t you do with a modern, cutting-edge processor development kit?

Let’s jump across the cube farm to the hardware side.

The most powerful resource available to hardware engineers is the FPGA development kit. If you fuzz your eyes a tiny bit, you might not even notice the difference between one of these and the processor kits described above. You often see all the same kinds of connectors, peripherals, and interfaces. The board is about the same size. You’ve got the same jumble of CDs, wall warts, and your 9,000th cheap USB cable. Just like the processor development kits, the entry-level ones cost about the price of a nice dinner. The only big difference is the silkscreen logo on the big chip in the middle. 

Also just like the processor development kits, FPGA kits usually come with robust reference designs. You can usually be blinking LEDs, watching fractals emerge on your touchscreen display, or seeing edge detection from your attached video camera within minutes of first opening the box. Also like with the processor kits, you typically get access to a suite of free tools and IP that will help jump-start your project.

Unlike processor kits, FPGA kits are NOT designed for the software engineer. You need to have more than a passing understanding of hardware to get past the demo designs. You probably DO need to be able to read and write VHDL or Verilog, and timing diagrams must be in your wheelhouse. With a few, insignificant exceptions, you need to be a hardware engineer to do anything useful with an FPGA kit.

With your FPGA kit, you can accomplish just about anything that can be done with digital logic (and some useful analog magic, too).

In the real world, most of our development projects involve both hardware AND software. Increasingly, software is shouldering the larger share of the functionality burden, and software takes the majority of the design time and effort. With the increasing performance and capabilities of leading-edge processors and microcontrollers, there are fewer and fewer things that software cannot accomplish.

What are those things?

First, FPGAs, as we have mentioned, are like duct tape. You can stick any two things together. Your processor development kit came with a prescribed set of hardware connections. If you need something different, you’re out of luck. With an FPGA kit, the raw pins of the FPGA are routed right out to the outside world. With a little hardware magic, you can make them communicate with just about anything – not just with one of the five interfaces that came with your dev board.

Second, FPGAs can accelerate compute-intensive tasks vastly beyond what you can do with even the fastest processors – without incurring a huge power consumption penalty. For applications that require signal-processing algorithms, you can create optimized, parallelized, pipelined datapaths in an FPGA that will outperform software by an order of magnitude while consuming far less power. Even if your compute-intensive task could be handled by your processor, chances are you can offload it to an FPGA and dramatically reduce the performance requirements of your processor. 

Third, FPGAs bring integration. An FPGA can clean up your board dramatically by pulling in dozens of functions that would have required separate components. You can build just exactly the mix of peripherals you need and not have anything that you’re not actually using hanging around costing money and sucking up power.

Fourth, and perhaps most interesting, FPGAs bring flexibility to the hardware portion of your design that was otherwise available only in software. As we mentioned above, software is becoming more and more the critical path in new product development. So much so, in fact, that it has become common practice to ship products when the software development is really not complete. We are used to getting a product where the initial software covers only the basics, and regular updates continue to improve the functionality and stability of the product – sometimes for years after we initially bought it and placed it into service. This field update capability has become so widespread that consumers have almost begun to rebel against products that don’t offer it. With FPGAs in the system, that same flexibility and upgradeability can be extended to the hardware portion of our design as well. We can add new features and fix hardware bugs long after the first boxes have left the loading dock. FPGAs make the field-upgrade potential of our system complete.

So – here we are with these two development kits – one for the software developers and the other for the hardware engineers. Both are designed with the idea that they are the center of our product-development universe. They come from different suppliers, are aimed at different audiences, and in many ways are competing for attention from our development team. There are only passing nods on each side to the existence of the other – the occasional processor board has a connector to hook up an FPGA board or vice-versa. What we’d really like, of course, is a well-conceived development board that takes into account the fact that most projects have both an embedded processing subsystem AND an FPGA. That kit truly could be the center of our development project. 

The new generation of FPGAs with integrated processing subsystems may eventually answer this call. Products like Xilinx’s Zynq truly bring both the software and the hardware side of the house a rich set of capabilities, and the smooth integration of the two makes things possible that could never be done with separate components. However, in their initial form at least, we get almost no choice in either the processor or the FPGA portion of that system. With literally hundreds of popular processor variants and at least dozens of popular FPGA configurations, the chances that an all-in-one device will have exactly what we’re looking for on both sides are low. This problem is not as bad as it might seem, however. The flexibility of the FPGA side of the chip can dramatically reduce the number of variants we’d normally require on the processor side. Since just about any mixture of peripherals and IO can be implemented with the FPGA fabric, what would be a huge range of processor part numbers/variants can be consolidated into one. 

Until and unless FPGA SoCs make the mainstream, however, we are left with a development board world divided. Two camps will vie for our project’s attention from different directions, wooing different parts of our development team. The resolution of all of the inconsistencies and incompatibilities between those worlds is, of course, left up to us to solve. We still have to design awesome products despite that disadvantage.