Remote Field Updates Using FPGAs

Introduction
Updating software remotely with new enhancements and bug fixes is fairly common in the electronics industry. Remotely updating hardware in this same manner might seem slightly more challenging because the system hardware is typically a fixed entity that can only be updated by manual replacement (board swapping). 

Creating hardware that can be upgraded in the field can significantly increase the useful lifetime of a system. The ability to add new hardware features and fix existing ones without sending a technician out to the field can add up to considerable maintenance and support savings over the entire life of the system. 

Designing systems that do remote upgrades can also provide new revenue prospects. After the initial product is released, new hardware features can be developed, sold and distributed inexpensively to existing customers in much the same way as new versions of software can be distributed today. In addition a standard "off-the-shelf" application can be developed so features can be swapped in and out depending on what the end-user purchases or needs. 

The types of systems that could benefit from being field updateable are wide-ranging. Almost any system that has some type of connectivity to the "outside world" could potentially benefit from being designed to support field updates. Some typical types of applications include:

Network Appliances 

• Set Top Box
• Security System

• ATM Switch
• Cellular Base Station

Data Communications (Wired & Wireless)

• HDTV 
• Video, Image Processing
• Encryption

• Surveillance
• Radar, Sonar

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 FPGAs PROGRAM pin, or by power-cycling the board. Another methodology would be to use the FPGAs 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. 

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 may wish to scrutinize the various aspects of the update process to ensure that their data is secure throughout any transfer. 
 

Security
Security can be broken up into a few general areas: protecting data as it transferred across an unsecured network, protecting an application from being updated by an unauthorized bitstream, and protecting existing configuration data from being copied from a working system. 

Fortunately, the existing security schemes that an application utilizes to protect other data transfers will usually be adequate for the remote update. Ensuring the security of update information as it travels over a network can be as simple as using encryption. There are many industry standard software and hardware encryption methodologies that can be employed to ensure secure data transfer. 

If the data transfer medium is unsecured, a basic requirement is making sure that only authorized configuration data has access to the system. Unauthorized accesses not only subject the system to the risk of being brought down, but also make the system vulnerable to serious damage. Designers can use one of the many existing password / verification technologies to give the system the ability to differentiate and restrict the access of rogue update data. 

Although copying the bitstream for the purpose of deciphering its functionality would be nearly impossible, copying the bitstream for the purpose of cloning a system is not inconceivable. Depending on the application's susceptibility to being cloned, it may be necessary to protect the configuration data from being copied directly from the application. The simplest methodology would be to prohibit the configuration data from being transmitted back across the communication channel. In systems where Readback verification is required, utilizing an encryption / verification scheme will ensure that the data cannot be copied over the communication channel. 

An additional level of security is possible if you take advantage of the volatile nature of Xilinx FPGAs. Hardware can be shipped separately from the FPGAs configuration bitstream, so that it is impossible to copy the shipped application's intellectual property. The application's configuration data would be remotely uploaded using some secure methodology only after the system is installed and the end user verified.
 

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 FPGAs 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 CD-ROM) 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. 
 

Other Resources

Xilinx WebLINX Silicon Xpresso Site

The Xilinx Silicon Xpresso on the World-Wide Web includes a special section on software tool sets that can be used to create remote update applications in JAVA. These can be used to deploy device configurations locally or remotely over the Internet. The URL for the Silicon Xpresso web site is 
 

References

to view the PDF files below

[1] Carmichael, Carl. "Configuring Virtex FPGAs from Parallel EPROMs with a CPLD", Version 1.0, March 1999.

Available on WebLINX at

http://www.xilinx.com/xapp/xapp137.pdf

[2] Xilinx, Inc., "Boundary Scan in XC4000 and XC5200 devices", Version 2.1, December 1997.

Available on WebLINX at

http://www.xilinx.com/xapp/xapp017.pdf

[3] Xilinx, Inc., "Java Boundary-Scan API: Enabling Technology for Internet-Driven PLD Systems", Version 1.0, September 1998.

Available on WebLINX at 

http://www.xilinx.com/products/software/sx/sxwhitepapr.pdf

[4] Xilinx, Inc., " Virtex™ 2.5 V Field Programmable Gate Arrays Advance Product Specification", Version 1.2, January 1999.

Available on WebLINX at 

http://www.xilinx.com/partinfo/virtex.pdf

[5] Xilinx, Inc., " XC4000E and XC4000X Series Field Programmable Gate Arrays Product Specification," Version 1.5, January 1999.

Available on WebLINX at

http://www.xilinx.com/partinfo/4000.pdf
 
 

Glossary of Terms

CRC-- Cyclic Redundancy Check is a method of error detection in data transmission applications.

CPLD-- Complex Programmable Logic Device.

Daisy Chain-- Multiple FPGAs with different configurations connected together and using a single bitstream to configure all the devices in the chain.

FPGA-- Field Programmable Gate Array.

HDL-- Hardware description language such as VHDL or Verilog.

IRL-- Internet Reconfigurable Logic combines Java based APIs and programmable logic devices to give designers of Internet or network appliances different reconfiguration options.