Traditional Approaches
Traditionally, field updates have taken the form of either software updates or hardware replacement by field personal. Even when there is programmable logic on the board, and a full board replacement is not required, the upgrade usually involves sending out a technician to either swap out configuration memory or connecting a portable PC to the target application and initiating the update.

An example where this type of manual update can be inefficient and costly is when an application depends on an industry protocol that is fluctuating during the development or production of a product. In an environment where standards have not been finalized, design modifications and updates can cause costly delays, or force the designer to move to less efficient, software-based implementations. Systems that support remote field upgrades can be shipped before standards are finalized and updated later.

Even with embedded applications or systems that depend only on static, industry standard specifications, the process of sending a technician to update hardware systems already deployed in the field can prove costly. In the extreme case of a satellite orbiting the earth the hardware update could be cost prohibitive or impractical.

FPGAs and Remote Field Upgrades
Since their inception designers have been using Field Programmable Gate Arrays (FPGAs) in systems that have exploited the advantages of field programmability and quicker time-to-market.

Xilinx FPGAs are based on SRAM technology and are customized by loading configuration data into internal memory cells. Because FPGAs are SRAM-based, it is very easy to re-program them an unlimited number of times. Updating the functionality of the FPGA only requires the designer to include a mechanism for updating the configuration bitstream.

The configuration bitstream is the programming file for the FPGA. This bitstream is created using the Xilinx development tools. Design entry can be performed using a variety of standard methods such as HDL or schematic entry.

Since the FPGA functionality is customizable, the types of systems that FPGAs are used in tend to vary considerably. In addition, the method by which the FPGA is programmed can also differ from system to system. To support remote field updates a system must have some sort of communication channel or connection across which data can be transferred, this could be a cable, or modem connection, or laser, infrared or radio transmitter / receiver interfaces, etc.

The main task in updating the functionality of the FPGA is replacing the bitstream used to program the FPGA. The best methodology for updating the bitstream is dependent on what resources the application has available to it and how these resources are connected.

The rest of this paper will focus on systems that have a microprocessor / microcontroller to control the update process. However, many of the issues discussed below are applicable across any method used to update a FPGA in an application.

A generic system demonstrating one possible solution for providing field updates is illustrated below.

Figure 1

The connection to the 'outside world' in the diagram above could represent an Internet connection, a simple twisted pair connection, a PCI or USB bus, or a satellite communications channel.

To initiate a remote field update a command must be sent across the interface to the communication processor signaling to the system that the FPGA needs to be updated. The communication device / interface could be something as complex as a microprocessor, or something as simple as a CPLD.

Once the communication processor knows that an update is required, it can reconfigure the FPGA directly using the slave, boundary scan, or peripheral FPGA configuration modes. Alternatively, as shown in the diagram above, the processor could update some sort of non-volatile memory (typically an EEPROM or Flash memory) and then simply initiate a standard FPGA reconfiguration cycle.

In this second case, after the update of the configuration PROM the system has several options for initiating the update of the FPGA functionality. The system can signal to the FPGA to start reconfiguration by pulsing the FPGA's PROGRAM pin, or by power-cycling the board. Another methodology would be to use the FPGA's built-in Boundary Scan configuration capability to configure the device via the processor. For more detailed information, refer to Xilinx application note XAPP017.

Planning for Remote Upgrade
Once the decision has been made to take advantage of remote field updates, a number of issues must be addressed:

Data Transmission
The type of communication channel that the update information will travel across will affect the speed, security and integrity of the data that is used to update the FPGA. If a communication interface is already being used for sending and receiving data in the system, it can usually also be used by the designer to perform the remote update. Some of the issues that should be considered when evaluating an interface's suitability for doing remote upgrades are listed below.

Data Integrity / Verification
It is extremely important that the integrity / reliability of the update data be assessed by the system before the configuration process even begins. Xilinx FPGAs have a cyclic redundancy check (CRC) built into each frame of the configuration data so that an error in the bitstream will most likely cause the configuration of the FPGA to fail. In the unlikely case that the bitstream is corrupted in a way that allows the FPGA to pass the CRC check (Xilinx FPGAs uses a CRC-16 CCITT polynomial) it is likely that the device will not function correctly.

The system should be able to detect transmission errors from the sender, and request a re-send of the data. The system may also need to let the sender know that the FPGA has been configured, and that the system is back on line. Accomplishing this can be as simple as monitoring the INIT or DONE pin on the FPGA.

For more thorough verification another option is to read back the bitstream from the EEPROM or Flash memory and verify it against the initial data. This type of verification can also be accomplished by reading back the configuration data from the FPGA. If this methodology is used, consult the Xilinx Programmable Logic Data book to determine the differences between the initial configuration bitstream and a bitstream obtained when performing a device Readback.

Security
If FPGA update information is sent over an unsecured network, design security may be an issue. Deciphering a configuration bitstream to extract information on the functionality of a design or make intelligent modifications to it is virtually impossible. Xilinx keeps the interpretation of the bitstream a closely guarded secret. Designers who feel the need for an additional level of security to keep their update data confidential may want to look into encryption.

An even more basic requirement is protecting the system from unauthorized access. Unauthorized accesses not only subject the system to the risk of being brought down, but also make the system vulnerable to serious damage.

Compression As FPGA densities increase, the size of the data required to configure increases. The rate at which the system must send and receive data may increase to the point where data compression can be beneficial. This would require some kind of additional software or hardware support to manage the compression / extraction.

Planning for Adding New Features and Bug Fixes
One of the major benefits of using FPGAs and supporting remote field upgrades is the ability to fix and add features after a product has been deployed in the field. Designing the system so that it can implement the current functionality and still be flexible enough to meet the requirements for future design revisions requires some advanced planning.

Choosing the Right Size for the FPGA
When choosing the size of the FPGA in a remotely updateable application one needs to consider future expandability and compatibility.

To determine which size FPGA to use, one must consider the size of the current design and the size of any potential future design enhancements. An advantage of Xilinx FPGAs is that for any device in a given architecture, in the same package, all device sizes are footprint compatible. This gives designers the ability to select and work with a specific device and still have the flexibility to easily change to a larger or smaller device before going to production.

Memory
The designer has a choice in terms of the size and type of memory used in their application. For a particular FPGA, every bit in the device needs to be programmed, regardless of whether it is used or not, so the size of the bitstream is constant for that target part. Therefore the size of the FPGA device and the mode of configuration will be the main factors in determining the required memory size.

The designer also has a choice of either volatile or non-volatile memory. The advantage of non-volatile (EEPROM or Flash) memory is that when reconfiguring the FPGA after a power cycle the system will still have the most recent configuration data in memory and will not require extra clock cycles to update its configuration data across the communication interface.

Most configuration modes require the entire bitstream to be stored in memory before configuration can begin. Some Xilinx FPGAs allow partial configuration and all devices can be configured one byte at a time with some added handshaking. Refer to the Xilinx data book for more information on the different configuration modes available for specific device architectures.

Design Expandability
Designing and testing a system for future enhancements is simpler when the functionality changes are self-contained within a specific FPGA. In some cases the board itself might have to be designed to account for future enhancements. For example, if additional connections between the FPGA and other devices are required in future revisions, then defining the interface between devices will need to be done during the initial product revision so that the connections are implemented and tested when newer revisions are created later. Designers can create small test cases that toggle these future I/O connections in order to test specific interfaces without actually completing the design, or alternatively use the Xilinx FPGA's built-in Boundary Scan functionality to perform an EXTEST.

Archiving the Design for Future Updates
When designing any system it is normally important to archive all the pertinent design files. When designing a system that will support remote field updates, being able to recreate or slightly modify an existing design version is important. Therefore it becomes critical to not only archive all source, implementation, or constraint files that were used to create the existing revision of the design, but to also document the entire flow used to create the final bitstream. Also, depending on the expected life of the application, it may be a good idea to archive (save the CDROM) the tools used in the creation of the bitstream. This would include all synthesis or schematic design entry tools a well as the Xilinx implementation tools.

Future Study
The sample system reviewed above included a communication processor that may have already been doing remote software updates. This application was the focus of this paper because it was the simplest type of system to make field updateable.

Other types of systems which are not discussed, but which could also be field updateable, include boards which do not have a processor to control the configuration bitstream update, or boards where the FPGA is the only significant logic in the system. An example is a PC add-in card that uses FPGAs for the PCI interface and backend design.

Although the issues discussed above also apply to these systems, there may be a few issues that are more prevalent in these types of applications. These issues could include the necessity of designing the system to automatically switch to a backup configuration bitstream or some sort of 'boot-prom' that allowed for another update in the case an update failure.