Bare Metal Blog: Introduction to FPGAs

#FPGAs change a lot. Here’s why they’re a big deal. #BareMetalBlog

We’re having all of our sidewalks redone right this instant. In fact, I’ll include a picture of the “pavers” – which is the fancy new word for the stones used to build the sidewalk. If the construction and design team do something wrong, it will cost them a pretty penny to come back out, rip up the pavers (and the columns or knee wall they’re putting in with the pavers on the patio), and move things around or replace pavers to make it right. We hired a great company that has done good work for us in the past, so I’m not terribly worried about this possibility. It happens in construction, but happens a lot less with a reputable installer.

It does offer a solid introduction to Field Programmable Gate Arrays (FPGAs) though. Because before there were FPGAs, most hardware out there shipped with a well-defined, non-changeable logic path. It did what it did, and if the hardware designers made a mistake in this increasingly complex product, you were stuck with the results. Some EEPROMs were shipped with re-programmability, but the vast majority of hardware did not have any way to update it. If a bug appeared, you lived with it or the vendor took the very expensive step of replacing it. Much like what happens when pavers are installed incorrectly. The difference of course is that you can look at pavers and see if you think the work is right, while hardware needs to be run – and run a lot – before weaknesses show. Kind of like the case where pavers are laid down but the material underneath them is not properly prepared. The next spring you can expect a jungle to grow up between the pavers, but until then they look nice.

EEPROMs (Electrically Erasable Programmable Read Only Memory) and then FPGAs brought the ability to fix bugs in the field into the realm of hardware. As FPGAs progressed and became more complex, even real-time updating (as in on-the-fly) became a possibility. At this point, there are billions of gates on an FPGA, and they’re used in a wide variety of devices. If you’ve ever “Flashed the ROM” or “Updated Firmware” there is a good chance you’ve been updating the FPGA in the device (though of course, these terms are vague enough that it could be other things you’re updating too).

But the power of updating on-the-fly is huge. If for nothing else than prototyping and training. Need to teach people hardware design? How better than on a device that you can program, test, reprogram, test again… Indeed, for at-home use (having nothing to do with F5, just one of my many geek toys), I use an Actel FPGA to set up complex circuits. Actel is now MicroSemi, but I haven’t dealt with them since the change, so I don’t know any details there. But for designing circuits, you can’t beat it. I’ve abused mine, and it still does what I tell it to. Note I said “what I tell it to”, not “what I expect it to”… I’m not a professional at FPGA programming, but it is a lot of fun.

But in a professional setting, the power is even greater. Not only can you train staff in FPGA programming and prototype solutions with FPGAs, you can also ship with FPGAs installed. Having FPGAs installed means that a huge percentage of the logic that makes a device go can be updated as-needed. This helps the vendor by giving them a path to fixing logic errors that were not discovered before ship time (say because the error is not obvious until the device is under massive load for a long period of time). It helps the customer by giving them an obsolescent-resistant product. If the logic of the hardware can be updated, then the device is much more forward-compatible than those that are not. When an FPGA can have 500,000 to millions of logic elements on it, the level of re-programmability becomes amazing. No support for the newest standard that impacts your device? Download the update, and BAM! You’ve got support for a standard that might not have even existed when your device was originally designed.

This does of course come with some risks. A part of your system that was stable forever now has changes introduced to it dynamically, but most reputable vendors have tools/steps/security in place to protect their customers from hardware problems bringing down the entire system. I can’t speak for everyone, in fact, at this instant I can’t even authoritatively speak for F5, but this next week I’ll be talking to the hardware folks about what we do, and the next two installments in this blog will cover both what we do with FPGAs, and how we protect our customers.