Securely updating FPGA-based embedded systems

December 01, 2015

Ted99-December 01, 2015

“Do not turn off power while system is updating.” We’ve all seen this warning before. It typically occurs when one of our electronic devices is updating its flash memory to install a code update. If this update is interrupted the flash memory will not be updated correctly. The code will be corrupted and the device inoperable, or ‘bricked’. The underlying reason for the familiar warning notice is that the vast majority of semiconductor devices that use flash memory require power to be applied at all times during programming or erase operations. Clearly it’s important to avoid creating a ‘bricked’ device. But what if it’s not sufficient to just issue a warning? Some embedded devices don’t even have a user display, so a warning can’t be generated. What can you do in your designs to create a reliable, safe and secure remote system update?

The Importance of Remote Updates in Embedded Systems
Remote updates are an increasingly important feature for connected embedded systems. Being able to fix bugs or add features remotely, over the internet, saves the significant expense of a service call and when thousands of embedded systems are deployed service calls become problematic. The increasing frequency of security breaches that target embedded systems also highlights the need for remote security oriented code updates to fix potential security exploits. Clearly the updates need to be secure or attack algorithms can use an insecure security update as an easy method of compromising the system. Let’s look at a typical system to better understand the requirements for a safe, secure and reliable remote update facility.

Example System - A Control Plane Bridge
One common example system that requires remote updates is a control plane bridge within a communications or networking chassis. This subsystem aggregates many low speed peripherals - such as analog sensors, power management modules, fans, fault logging memory and status outputs using I2C, SPI and GPIO interfaces. A higher speed bus, perhaps PCIe - a very common subsystem interface in many communications and networking chassis - can then be used to communicate with low speed peripherals directly. The chassis control subsystem can implement intelligent aggregation functions that ‘push’ communications when specified trip points are activated - maximum temperatures or minimum voltage levels for example. Figure 1 below shows such a system implemented using an FPGA with an on-chip microcontroller, commonly called an SoC FPGA.

Figure 1. Chassis Control Plane Bridge with Remote Updates via PCIe

FPGAs and Flash Memory
In the above example system, remote updates are made via the PCIe bus but have not been protected from a possible power outage during programming. Let’s look at the common types of FPGA implementations to better understand the requirements to protect a flash memory remote update process from critical failures during a power outage.

Just about every FPGA-based system requires some form of non-volatile memory to store configuration memory. Typically configuration memory resides either off-chip or on-chip. SRAM-based FPGAs require an external flash memory for configuration on power up. Flash-based FPGAs either store configuration memory embedded within the FPGA fabric (fabric embedded flash FPGAs) or use SRAM-based fabric but put a flash memory block on-chip (flash on the side FPGAs).

With SRAM-based FPGAs typically a NOR SPI flash is used because it consumes the fewest pins, has multiple suppliers with the same pin out, and is available in densities up to 1 Gb. Current NOR SPI flash devices have a 32-bit address option allowing for growth to 4GB device without any changes in the command and control protocols. What happens when this SPI flash is in a program or erase mode (charge pumps are active) and power disappears? Where does the charge dissipate? Is there circuitry to detect power failure in these flash memories and shunt the charge safely to ground? Typically what occurs is the page being written to will experience data corruption.

Figure 2. Diagram of Three FPGA Configuration Options: SRAM-based with External Configuration Flash, Flash on-the-side and Embedded Flash

With flash on-the-side FPGAs, a wide on-chip data bus is used to load the SRAM-based configuration memory on power-up. Usually configuration is faster than for an SRAM-based FPGA where external flash memory is used to configure the device. However similar questions with respect to power loss during a program or erase cycle need to be asked. Where does the charge go? Does the flash memory become corrupted? Is only the page being written to corrupted? Or is the entire flash memory at risk? Can the FPGA detect a corrupted on-chip memory or does the corrupted data get loaded into the configuration memory during the power-up process?

Next page >


< Previous
Page 1 of 2
Next >

Loading comments...