With increasing frequency, automotive manufacturers regularly inquire about using FPGAs in high-reliability systems. There are several concerns that are raised during these discussions about corruption of the FPGA configuration used for initialization and SRAM corruption during operation. In this entry, I will highlight several solutions to mitigate initialization configuration corruption using Lattice AEC-Q100 qualified devices. Part 2 of this blog post will show solutions for dealing with potential SRAM corruption issues.
SRAM-based FPGAs download their configuration from an external source when the system powers up. The boot source can be from a memory device such as a serial EEPROM or FLASH device. Boot sources can also be an intelligent device like a microcontroller that can provide the correctly formatted bitstream. All FPGAs have some type of CRC check of the initialization bitstream when the device starts. If an error is found in the bitstream, then the FPGA will not start operating which prevents incorrect (and possibly dangerous) operation of the system. Most FPGAs will then notify the system that the initialization failed and then start another initialization sequence that hopefully will be successful.
There are several scenarios that can cause the corruption of the initialization bitstream. These include:
- Hard failure of the boot memory
- Memory retention issues
- Deliberate tampering
- Memory erasure
- Electrical noise
There are four basic steps for using FPGAs when designing ultra-reliable systems, they are:
Step one is to move the primary boot device (contained in an external component) to a memory array that is internal to the FPGA. This step eliminates many of the common initialization failure modes. The integrated design also increases the initialization speed and allows the FPGA to be used in “Instant-On” systems. The LatticeXP2 is the only non-volatile AEC-Q100 qualified SRAM/FLASH FPGA available. Having on-die FLASH in devices like the XP2 allows extensive memory testing of the entire device at 125C. This assures that even with continuous operation of the XP2 at the maximum temperature, there will be no losses in the FLASH memory content for a minimum of 10 years.
The second step for reliable systems is to add a redundant boot device. This is accomplished by adding an external boot device that can be an automatic fallback device. As the XP2 Flash Memory is field reprogrammable, it is possible for events to take place during an authorized download of new operating code during a dealer update. By adding the secondary boot device, there is an assured backup or “limp home” operating image if necessary. The typical use is to place a “golden” factory copy of the initialization code in the eternal memory device. This allows the system to recover any problems with the image stored in the internal memory array.
Thirdly, secure the backup bitstream that is contained in the external memory device by using bitstream encryption to secure the boot image. The XP2 and the LatticeECP2/M families support 128-bit AES bitstream encryption to prevent reverse engineering and unauthorized changes to the design. An encrypted image is stored in the external boot device and during initialization; the image is unencrypted and moved into the SRAM cells. This encryption mechanism can also be used to download a new image into the internal FLASH memory.
The last step is to “lock down” the FPGA to prevent unauthorized access to the stored configuration. Several programmable registers internal to the XP2 control access to the configuration memory. The possible combinations are:
2. Key Locked – Presenting the 128-bit key through the programming interface allows the device to be unlocked.
3. Permanently Locked – The device is permanently locked.
To further complement the security of the device a One Time Programmable (OTP) mode is available. Once the device is set in this mode it is not possible to erase or re-program the Flash portion of the device.
FPGA designs implemented with these four steps can be considered Ultra-Reliable for startup and initialization with the ability to: start with a valid configuration, allow secure updates and prevent attempts to erase, download or modify the initialization configuration.
In the next entry, I will finish off this discussion with the monitoring and protection of the SRAM contents during operation.