feature article
Subscribe Now

First, Make a Roux

Beyond Basic FPGA Configuration

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…

Leave a Reply

featured blogs
May 17, 2022
Introduction Healing geometry, setting the domain, grid discretization, solution initialization, and result visualization, are steps in a CFD workflow. Preprocessing, if done efficiently, is the... ...
May 12, 2022
Our PCIe 5.0 IP solutions, including digital controllers and PHYs, have passed PCI-SIG 5.0 compliance testing, becoming the first on the 5.0 integrators list. The post Synopsys IP Passes PCIe 5.0 Compliance and Makes Integrators List appeared first on From Silicon To Softwar...
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...
Apr 29, 2022
What do you do if someone starts waving furiously at you, seemingly delighted to see you, but you fear they are being overenthusiastic?...

featured video

Building safer robots with computer vision & AI

Sponsored by Texas Instruments

Watch TI's demo to see how Jacinto™ 7 processors fuse deep learning and traditional computer vision to enable safer autonomous mobile robots.

Watch demo

featured paper

5 common Hall-effect sensor myths

Sponsored by Texas Instruments

Hall-effect sensors can be used in a variety of automotive and industrial systems. Higher system performance requirements created the need for improved accuracy and more integration – extending the use of Hall-effect sensors. Read this article to learn about common Hall-effect sensor misconceptions and see how these sensors can be used in real-world applications.

Click to read more

featured chalk talk

Machine Learning with Microchip

Sponsored by Mouser Electronics and Microchip

Can you design a machine learning application without a deep knowledge in machine learning? Yes, you can! In this episode of Chalk Talk, Amelia Dalton chats with Yann Le Faou from Microchip about a machine learning approach that is low power, includes an expertise in communication and security, and is easy to implement.

Click here for more information about Microchip Technology Machine Learning