How to securely update FPGA-based embedded systems

We are all familiar to this warning: "Do not turn off power while system is updating". 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 sub-system aggregates many low speed peripherals—such as analogue 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 sub-system interface in many communications and networking chassis—can then be used to communicate with low speed peripherals directly. The chassis control sub-system can implement intelligent aggregation functions that 'push' communications when specified trip points are activated—maximum temperatures or minimum voltage levels for example. Figure 1 shows such a system implemented using an FPGA with an on-chip microcontroller, commonly called an SoC FPGA.

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).