If you own a Cajun cookbook, you may have noticed that virtually every recipe begins with this step. If you can’t make a Roux, you can’t cook Cajun. The recipe for Roux (if you can find one) is always fairly vague – “Put some flour and oil in a pot and heat until the color changes to brown.” How much flour? How much oil? How much heat? What shade of brown? All of these questions are, as we learned in engineering school, “left as an exercise for the student.” Of course, if you make your Roux badly, you are creating a dish that is crippled from the start. Caveat Cook.
Designing with FPGAs works a bit like that. Here in the techno-editorial world, we simply state that you’ll need “some configuration logic” attached to your device before you go off enjoying whatever wonderful new feature we’re about to disclose in our article. What kind of configuration logic? You know – throw some flash and a JTAG thingy into a pot, maybe a CPLD or two, heat until it turns brown, and there ya’ go. Now, let’s talk about those new 18X18 multipliers…
Wait, I see the Actel folks coming over the hill waving banners and shouting… “Not us! Not us! We have single chip solutions…” OK, they didn’t really shout that, but they probably would have, given the chance. Let’s tackle that question from the start. Reprogrammable non-volatile FPGAs such as Actel’s ProASIC and Fusion families do not require additional logic to boot and run in the field. They are live at power-up with their programmed-at-your-factory configuration. If, however, you want to take full advantage of that reprogrammability and send new configuration bitstreams to the devices of your customers in the field, you’ll need to attach some stuff to even these FPGAs to manage the process. Also, although it may be obvious, antifuse-type FPGAs such as QuickLogic’s devices and Actel’s rad-hard families are not field re-configurable and don’t use the kind of configuration logic that is the subject of this article.
As we’ve discussed many times, most FPGAs are based on SRAM-like logic structures that hold the routing information and the contents of look-up tables (LUTs). While it’s true that the S in SRAM stands for “Static,” there’s nothing static about it when you take the power away. Configuration information must be loaded into your SRAM FPGA each time at power-up via a configuration bitstream that is pumped into the device through a Joint Test Action Group (JTAG) port. JTAG (also known as the IEEE 1149.1 standard) was designed for printed circuit board testing using boundary scan techniques. Over time, however, the use of the standard evolved to general-purpose access to internal registers and sub-blocks of ICs. One of the things that need such back-door access frequently is the configuration logic in FPGAs. As a result, almost every FPGA uses JTAG as its primary configuration mechanism.
Back in our Grandpa’s FPGA-configuring days, everybody pretty much designed their own little circuit that squirted the bistream into the FPGA via the JTAG port using the plain-old 1149.1 standard. Try and tell that to today’s kids, though, and they’ll start whining about how they want to do in-system reconfiguration, and how they’ve got processors and memory and all kinds of things they want to load separately. Some of the rebellious kids are even experimenting with partial reconfiguration. To keep us youngsters from having to trundle through ten feet of snow to get our newfangled platform-class FPGAs configured, a new IEEE standard (new back in 1999, anyway) – IEEE 1532 — was developed. 1532 is a “Standard for boundary-scan-based in-system configuration of programmable devices.” 1532 provides for a host of features that make FPGA configuration faster and more efficient.
Additionally, as FPGAs got larger, vendors began providing additional, faster options for configuration such as parallel interfaces. As you might suspect, an 8-bit parallel load can be accomplished something like 8 times faster than through a JTAG serial port. Matching up your configuration needs in terms of performance and features with your FPGA device’s storage option can be a little daunting, however. Add to that complexity a variety of schemes that determine what, exactly, in your design is controlling the reconfiguration process (is it a microprocessor? a CPLD? the FPGA itself?), and things start to look like one of those recipes with units like “a pinch” or “a handful” or “to taste”.
Short of attending a Cajun cooking class, how do we beef up our boards with the best configuration logic for our SRAM FPGAs? The easiest place to start is, as usual, with the FPGA vendors themselves. Each FPGA vendor offers proprietary solutions matched to their FPGAs for configuration management. For development work, when you’re just debugging and working with a prototype, you can configure your FPGA directly with a JTAG cable without even using a non-volatile memory. With your FPGA safely tethered to your PC, you can control the configuration process directly.
Break that development/debugging PC connection, however, and you’ll need a place (like flash memory, perhaps) to store your bitstream on the FPGA board. If you want to get fancy and allow your FPGA to be re-configured in the field, you’ll need even more complicated stuff. FPGA vendors offer purpose-made flash devices such as Xilinx’s “Platform Flash” and Altera’s “Enhanced Configuration Devices.” These devices are purpose-built for FPGA configuration with controller and non-volatile memory all in one. They can be set up to support a variety of schemes, but each one has limitations in terms of the devices it supports and the ways in which multiple configuration devices and multiple FPGAs can be utilized. They do offer some nice capabilities (in some cases) like compression and/or encryption of bitstream data.
These devices are handy, but fairly expensive for the amount of storage they provide. Wouldn’t it be nice if you could just use commodity flash to hold your FPGA configuration? It turns out that you can – in an assortment of interesting ways. First, if your design has a microprocessor or microcontroller already sitting there soaking up silicon budget and board space, you can task it with FPGA configuration duty as well. Using such an approach, you can store FPGA configurations (as many as you’d like) in whatever storage medium is attached to your processor – flash, hard drive, old-fashioned core memory, paper tape – yep, whatever you can tolerate in terms of speed, storage, and cost will work just fine. You can also write software to manage remote downloads of new bitstreams, decryption of configuration data passed over public channels, and pretty much any other configuration-related feature you can think of.
If you’re not so psyched about the idea of writing a bunch of software to manage configuration, and you don’t love paying the big bucks per bit or lashing yourself to one particular FPGA vendor’s proprietary configuration mechanism, you might want to consider a third-party, ready-made configuration system such as those provided by Intellitech. We visited Intellitech at the Design Automation Conference last week and got an overview of their SystemBIST devices which combine vendor-independent configuration management with support for board-level built-in self test (BIST).
Intellitech says that SystemBIST requires less board area and costs less than vendor-specific configuration devices. SystemBIST has a robust feature set that allows commodity flash devices to be used to host multiple FPGA configurations, flash binaries, and test data. The processor allows up to 15 different design/test suites to be stored in external flash. The company’s “Ultra TAP” controller connects your board to a PC to allow test and configuration data to be loaded into the system for debugging and prototyping, and a “fast access” flash programmer programs the on-board flash with the resulting data.
The company’s optional SRL device links multiple scan paths into a single high-speed test bus so you can configure and manage multiple programmable logic devices and configure and test them with a single SystemBIST processor. At power-up, the SystemBIST processor configures all on-board programmable logic devices and runs any board-level test programs. The processor also manages in-situ reconfiguration by simple re-programming of the external flash. The system is failsafe for field updates because you don’t need to erase the entire flash, and a backup configuration can always be saved and restored pending the correction of update problems.
Now that we’ve gotten you started sorting out your configuration situation, we’ll go back to telling you all the cool features of the latest FPGAs and tools. If someone should ask how you got those FPGAs configured in the first place, just point them to this article – or tell them to mix some flour and oil in a large pot…
