The FPGA "Fountain of Youth" (field logic updates)

Introduction
Long gone are the days when a single, complex system design could enjoy a 5- or 10-year market life. System requirements are changing at an explosive rate. I/O standards, data communications standards, system performance requirements, and demands on system functionality are all changing faster than ever before. System designers have two choices as follows:

1. Design systems with fixed capabilities, meeting today's requirements only and be forced to redesign the system when the system is no longer competitive in the marketplace. 
    
2. Design FPGA-based systems with the ability to be "rejuvenated" over time with an in-system reconfiguration or field logic update. Extend the life of current systems. Expand the capabilities and performance of boxes already installed in the field. Fix bugs without having to touch hardware. Reconfigure FPGAs, already deployed in the field, without taking the system off line ... and do it in a highly reliable and secure fashion. Sip from the FPGA "Fountain of Youth"!

Real-world examples
More and more system designers are taking advantage of the FPGA's capability to be reconfigured – after initial system design and deployment – to solve problems, extend system life cycles and expand system capabilities.

For example, there is an entire class of mainstream server vendors who now have a "hard" system requirement to support field logic updates of their FPGAs. Being able to remotely upgrade systems is essential for developing, deploying and maintaining a network of hundreds to thousands of servers located across diverse geographic locations. Technicians no longer have to tear apart a system to replace or upgrade an FPGA. It can all be done remotely ... no technician required.

A leading telecom solutions provider (base stations, network servers, routers etc.) based in China has a requirement to support remote field upgrades to implement bug fixes and to install new features and services. Further, their end customers have a requirement that any system update require no more than 50 milliseconds of system downtime!

A manufacturer of PC-based, broadcast video add-on cards takes advantage of FPGA field logic updates to incorporate refinements in video algorithms and to deliver enhanced feature support to users who pay for the upgrade. Reliability of the remote upgrade process is the critical concern for this supplier. There is also a strong desire to protect the intellectual property (IP) embedded in these video algorithms, so security of the FPGA code during the field logic update process is also critically important.

FPGA field logic update requirements
In order to execute a field logic update of an FPGA effectively, there are four fundamental requirements as follows:

1. Embedded Programming – The system microprocessor must be able to program the FPGA. Generally, this is an FPGA vendor-supplied C-code program that can be compiled and executed by the system microprocessor. The microprocessor is then able to provide the communication link (via Ethernet, Internet, RF or a land line) between the outside world and the target FPGA. The microprocessor can now access the new FPGA programming file; download this new bitstream to a dedicated memory chip or, potentially, to the FPGA's on-chip Flash memory; and then subsequently control the reconfiguration of the FPGA itself. 
    
2. Minimum System Downtime – More and more users are insisting on "5 Nines" (99.999%) system availability. The system is not available while the FPGA is being reprogrammed, so this process must happen very quickly to be useful. This is an area that must be researched carefully by any FPGA system designer. For the common SRAM-based FPGA, the time required to download the new bitstream to the target FPGA from the dedicated SPI Flash or EEPROM boot memory will range between tens and hundreds of milliseconds. If the designer takes advantage of a single chip, non-volatile, SRAM-based FPGA with dedicated Flash configuration memory, the complete FPGA reconfiguration will take a maximum of 2 milliseconds.

   The actual configuration of the boot PROM (SRAM-based FPGA) or the on-chip Flash memory (SRAM/Flash FPGA) will take place in "background" mode, while the system is still fully operational, so it is only the time required to actually download the new bitstream to the FPGA SRAM cells that determines how long the system must pause before it is able to continue operation with its newfound youth. 
    

3. I/O States Must Be Controlled – The outputs from the FPGA often drive key control signals within the system (chip resets, power supply enable, etc.). During the FPGA reconfiguration, it is critical that these signals continue to be driven in the correct state. A glitch on one of these signals could cause a system reset/re-boot.

   This is another area for FPGA designers to evaluate very carefully. Many FPGA architectures default all of their I/Os to tri-state values once the programming mode is entered, which will most certainly cause a significant interruption in system operation. Other FPGA solutions in the marketplace allow the user to pre-define – on a pin-by-pin basis – the state of I/Os (i.e. high, low, high-impedance or sampled and then driven to the current value) to support a transparent and orderly pause of the system. 
    

4. Device State Must Be Controlled – It is essential to control the state of the logic within the FPGA prior to exiting the configuration process. This allows the device logic to drive to correct levels on the outputs immediately after the device configuration is complete. Phase Lock Loops (PLLs) must also relock if necessary.

   These capabilities are essential to allow the system to smoothly waken from its brief nap and resume full speed operation with its rejuvenated FPGA. FPGA designers will find that most volatile (SRAM-based) FPGA architectures in the marketplace today do not support these critical capabilities. By comparison, the single chip, non-volatile, SRAM/Flash FPGAs in the marketplace do support these requirements.