“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?
Not only is the corruption of the flash an issue, how the remote data is secured is also of critical importance. When an embedded product is accessible by an end user, it has the potential of being tampered with. To prevent unwanted attacks, both software and hardware security must be employed. It is not adequate to only have a remote configuration data file encrypted. Although this software encrypted security helps, the hardware (FPGA) that is going to unencrypt the data must have built in security protection too. An encrypted data file can easily have its key extracted when the user can access the embedded device. This is done by using an inexpensive electromagnetic probe and implementing differential power analysis (DPA). There are numerous examples of FPGA security keys which have been extracted by using this technique. If the FPGA does not have DPA countermeasures built in, then any remote update could become a security vulnerability. When an embedded product is accessible by a user, not having DPA countermeasures is the same as having no security.
With flash-embedded FPGAs, the configuration memory is stored on-chip and is closely integrated within the FPGA fabric. For example, on Microsemi SmartFusion2 and IGLOO2 flash FPGAs, programming can take place via an external communications port such as USB, PCIe or JTAG and the entire programming process is managed by an on-chip dedicated programming interface. Additionally, an advanced programming facility, called In-Application Programming (IAP) is available on SmartFusion2 and IGLOO2 FPGAs which provides the desired reliable, safe and secure programming facility even in the face of a power loss during programming. Let’s now look at how the IAP facility can be used to help implement the robust remote update capability required by todays embedded systems.
Implementing a Reliable, Safe and Secure Remote Update in an FPGA-based Embedded System
A flash-embedded FPGA can provide the key functions required to more easily support secure and robust remote updates. For example, SmartFusion2 has all the mainstream FPGA features needed to implement the key bridging functions as well as the required security and IAP functions. As shown in Figure 3 below, the low speed interfaces can connect using I2C and GPIO. The high speed host interface, PCIe, is implemented as a dedicated port that doesn’t require FPGA fabric.
Figure 3. SmartFusion2 In Application Programming (IAP) Supports Secure, Safe and Reliable Remote Updates in a Chassis Control Plane Bridge
The on-chip processor can use the high speed memory subsystem (HSMS) to access the large internal flash memory for code storage, large internal SRAM for data buffering and the dedicated DDR controller provides access to additional external memory if needed. The dedicated system controller provides security functions used during programming and the IAP function used during remote updates. A more detailed view of the key functions available on the SmartFusion2 FPGA is shown in Figure 4, below.
Click for larger image
Figure 4. Microsemi SmartFusion2 SoC FPGAs have Mainstream Features along with Robust Security and Remote Update Capabilities
Using In-Application Programming for Safe, Secure and Reliable Updates
The In-Application Programming (IAP) facility available with SmartFusion2 and IGLOO2 provides a means for securely and reliably updating the configuration bitstream remotely. IAP is executed from the dedicated system controller within the FPGA so it doesn’t require the use of any FPGA fabric or other user configurable logic. The IAP function is two-step process and uses an external SPI flash memory device. In the first step the external SPI flash device is programmed with the desired bitstream using any of the available interfaces – PCIe, USB, JTAG or even Ethernet. All bitstreams used to program SmartFusion2 devices are encrypted to make sure they are protected from tampering, so this bitstream will also be in an encrypted form.
In the next step the System Controller performs the IAP service via a system service call. The user provides a pointer to the System Controller with the starting address of the bitstream location in the external SPI flash memory. The IAP system service call also has three options for the user: Authenticate, Program or Verify. Authentication is typically performed prior to programming the FPGA configuration memory to verify that the bitstream in the SPI flash is properly constructed for the device being programmed. During authentication the device operates normally.
The external SPI flash that contains the new bitstream can also contain an additional image as well, one that can be used as a known good version for recovery purposes. The user can at any time point to the recovery image and use it to configure the FPGA into a known good state. The recovery image can be saved, ‘as is’ from day one, or it can also be updated for critical bug fixes as needed.
During the IAP function a Program Recovery option is available. When Programming Recovery is enabled if power fails during programming, the system controller will disable internal charge pumps used to program the FPGA in a controlled manner. On the next subsequent power-up cycle, prior to enabling the FPGA fabric, the system controller will detect that the device programming operation has been interrupted and it will initiate a programming cycle from a bitstream located in the external SPI flash. Users have a choice of updating from the known good image or the remote updated image that was just pushed to the SPI flash memory. When an external bitstream is loaded into the SmartFusion2 FPGA, it employs the built in DPA countermeasure logic. This ensures no electromagnetic probe can decipher the encryption key, thus resulting in a trusted, secure device for the embedded system.
Program recovery, when combined with the secure encrypted bitstream and bitstream authentication, delivers the reliable, safe and secure remote programming update facility required by today’s connected embedded systems, even if power is lost during FPGA configuration memory programming.
Ted Marena is the director of FPGA/SOC marketing at Microsemi. He has over 20 years’ experience in FPGAs. Previously Marena has held roles in business development, product & strategic marketing. He was awarded Innovator of the Year in February 2014 when he worked for Lattice Semiconductor. Marena has defined, created and executed unique marketing platform solutions for vertical markets including consumer, wireless small cells, industrial, cameras, displays and automotive applications.