Solving the Challenges around In-Field Upgrades

A key benefit of programmable logic devices, such as FPGAs and CPLDs, is their programmability. These devices are typically deployed with a unique design intended to address application-specific problems. And because of these problems, many embedded systems that deploy programmable products benefit greatly from the ability to update their design and configuration after manufacturing. An upgrade feature is useful for multiple end-applications. For example, applications like sensor or display interfacing can take advantage of this feature to improve inventory control. These applications may have one end of a protocol bridge with a slightly different timing or specifications depending on unit type. Another example application is board management in industrial and telecom infrastructure applications. These applications typically have a long-life and benefit greatly from the ability to patch bugs or improve reliability by upgrading configurations over the air or in-field.

FPGAs with on-chip configuration Flash offer the benefit of in-field reprogrammability. However, this benefit comes with a disadvantage of increased complexity in system design. There are several challenges that system designers must overcome to properly implement an in-field upgrade scheme of such products. State-of-the-art Flash FPGA products include multiple features to help manage these issues.

The first system level challenge is downtime during an update. Some Flash FPGAs require that the device be taken offline, or placed in a dedicated programming mode, in order to update the device. In those cases, the system operation must be frozen or stalled, and the device I/O must be held in a known trustworthy state prior to entering the offline mode. For a scenario like this, some devices directly support an I/O freeze mode. Devices that do not provide such a dedicated mode may require additional external resistors or other components to hold I/O in a safe state.

Placing the device in an offline mode has several drawbacks – depending on the interface used for programming and the size of the programming memory of the device, reprogramming the device can take several seconds. This amount of down time may not be allowed in many systems, especially infrastructure applications that need to operate continuously.

More advanced Flash FPGAs support background programming modes. The background programming modes enable the reprogramming of the configuration Flash memory of the devices without taking the device offline. This allows the device to continue operating normally during the several seconds of programming time, easing concerns about downtime.

Once a device has been background programmed, the configuration Flash memory can be loaded into the active SRAM memory of the device. This step of activating the new configuration is often referred to as “refreshing” the device, and only takes a few milliseconds compared to the seconds it takes to program the device in offline mode. Ideally, this refresh step can be accomplished without powering down the device depending on its technical features. Some devices can utilize the I/O freeze feature combined with a refresh command to provide essentially a zero downtime update of the device. The I/Os are frozen during the refresh step and only release when the new configuration is active in the device. This feature is sometimes called Hitless Update and is illustrated below.

Interfacing for Background Programming

Interfacing to a device for background upgrades is another challenge in many embedded systems. The most common interface used to program Flash FPGAs during manufacturing is the JTAG interface. JTAG is an ideal interface for the manufacturing environment since it can combine board test features like boundary scan with reprogramming in a single device chain. It is also commonly used as a debug interface.

Most in field reprogramming will occur using another programmable device in the system, such as a microcontroller or applications processor. This device will receive the programming update file “over the air” and act as a programming master to the FPGA. The challenge here is that many MCUs and processors do not have a JTAG master block on board, meaning this interface is not very useful for background reprogramming in-field. Fortunately, many programmable devices also support a SPI interface for reprogramming, which is highly common in the industry. Some recently released Flash FPGAs have added the ability to reprogram over I2C, which requires less I/O than a SPI bus and has emerged as a preferred sideband interface in many systems. This is especially beneficial in small form factor applications with a low I/O count, where the difference between two and four pins can determine which packages can be used.

Recovering from Programming Failures

Background reprogramming adds yet another challenge to device usage in the field. During Flash reprogramming, the Flash memory must be erased prior to being programmed with the new configuration. The erase step typically takes the bulk of the overall programming time, presenting a particular challenge – a power failure or other failure during the erase or programming steps will result in a corrupted configuration.

Programming failures present a critical challenge in many of the same systems where downtime would be a concern. In systems where the Flash FPGA or CPLD is the first device to turn on and handle the board management and startup / shutdown of the system, programming failures can render the entire system frozen. Such applications must have a method to recover from programming failures. Many Flash FPGAs have a feature known as Dual Boot, which provides recovery from programming failures. The Dual Boot feature provides a method to store and access a Golden or Fallback image, which is left undisturbed during programming. This image, which can be stored in an off-board SPI Flash, is then available when the system attempts to boot following a programming failure. At this point, the FPGA can detect that the main device image is corrupted, and fallback to boot from the secondary image. High reliability systems which take advantage of background reprogramming will typically require a dual boot solution.

Security from Malicious Updates

An emerging concern in embedded systems is firmware security. Any device which enables in-field or over-the-air upgrades should include a measure of protection against malicious updates to the device. FPGAs provide a variety of solutions to these problems. One solution is password protection. Password protection requires that a secret code be passed to the FPGA over the programming interface, before background programming can begin to operate. This code is stored in flash memory in the FPGA and only programs what is downloaded to the system, including the secret password that will allow programming the device.

MachXO3

Lattice provides an industry leading solution for in-field upgrades, with the most complete solution around secure and transparent background upgrades. The MachXO3 family of low-density FPGAs include multiple features designed to address the challenges around in-field upgrades including the most background programming interfaces in the industry. The devices also support key security and reliability features like hitless updates, dual boot and password protection. Start your designs with MachXO3 FPGAs by using our latest MachXO3-9400 board.