Newsletter

Tips and Tricks: Using FPGAs in reliable automotive system design

For FPGAs to be part of an ultra-reliable design, designers must protect the valid FPGA configuration used for initialization and prevent SRAM corruption during device operation

Page 1 of 2

Automotive DesignLine

Edited by Rick DeMeis

The increased use of complex automotive electronics systems requires that they be designed for "ultra-reliability," because the failure of an automotive system could place the vehicle's passengers in a life-threatening situation. System designers are considering the use of Field Programmable Gate Arrays (FPGAs) more frequently in these systems, due to the FPGA's ability to integrate and perform complex functions.

However, there are two primary concerns regarding the use of FPGAs in automotive systems: The need to protect the valid FPGA configuration used for initialization, and prevention of SRAM corruption during device operation. Unless these concerns are fully addressed, FPGAs cannot be part of an ultra-reliable automotive system design.

Fortunately, current AEC-Q100 qualified FPGAs incorporate several advanced features that resolve these concerns. This article will highlight several solutions that address both the initialization configuration and potential SRAM corruption issues.

FPGA configuration protection
Upon system power up, SRAM-based FPGAs download their configuration from an external source. The boot source can be memory devices such as serial EEPROM or flash. Boot sources can also be intelligent devices, such as a microcontroller, that can provide the correctly formatted and timed data bitstream.

All FPGAs have some type of cyclic redundancy check (CRC) for the initialization bitstream, which is tested at the end of startup to verify the integrity of the transfer. If an error is detected in the bitstream, the FPGA will not initialize. This routine prevents incorrect (and possibly dangerous) operation of the system. Most FPGAs will set an external pin that notifies the system controller that the initialization has failed, prompting another initialization sequence that, hopefully, will be successful.

There are several scenarios in which the initialization bitstream can be corrupted. These include:

  • Hard failure of the boot memory
  • Memory retention issues
  • Deliberate tampering
  • Memory erasure
  • Electrical noise

    When designing ultra-reliable automotive systems using FPGAs, there are four fundamental steps that must be followed to properly address these scenarios.

    Step one is to use a non-volatile SRAM FPGA that includes on-chip flash memory. This changes the boot device from an external component to a memory array that is internal to the FPGA. Moving the boot source onto the same die eliminates many of the common initialization failure modes. This type of integrated design also increases the initialization speed and allows the FPGA to be used in "instant-on" systems.

    An example of an FPGA dual-boot system

    Second step is to add an external boot device that can be the automatic fallback device (see figure above). A key feature of FPGAs is field reprogrammability. In automotive systems this feature allows new programs to be downloaded (for example, at the automotive dealership) as an authorized field update to add additional features or to fix design errors.

    However, it is possible that the data stream will be corrupted during both the transfer and the programming of the memory, and that the corrupted data stream will prevent correct FPGA initialization. To deal with update corruption, the design typically includes a "golden" factory copy of the initialization code in the external memory device. This duplicate allows the system to recover from any problems with the image stored in the internal memory array. By adding the secondary boot device, there is an assured factory backup, or at least a "limp-home" mode operating image.

    Decryption of external boot or flash programming bit streams

    Third step is to secure the backup bitstream that is contained in the external memory device by using bitstream encryption to secure the boot image (see figure above). Many of the automotive FPGA 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 same encryption mechanism can also be used to download a new image into the internal flash memory.

    The fourth and final step is to "lock down" the FPGA to prevent unauthorized access to the stored configuration. Programmable registers internal to non-volatile FPGAs control access to the internal configuration memory. The possible combinations are:

  • Unlocked
  • Key locked—Presenting the 128-bit key through the programming interface allows the device to be unlocked
  • 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 reprogram the flash portion of the device.

    When choosing an automotive grade AEC-Q100 qualified non-volatile FPGA, it is important to review the manufacturer's non-volatile memory endurance and data retention specification to verify that the FPGA will retain it's memory contents at both operation and storage temperatures for the life of the vehicle.

    For example, the LatticeXP2 is the a non-volatile AEC-Q100 qualified SRAM/flash FPGA available that satisfies all of these system requirements. The on-die flash of the LatticeXP2 allows extensive memory testing of the entire device, assuring that even with continuous operation at the maximum temperature, there will be no loss of memory content for a minimum of 10 years.

    Page 2: SRAM corruption: Soft error detection (SED) or 'It Came from Outer Space'  

    Page 1 | 2

    Related Links:
  • Cosmic rays damage automotive electronics
  • For cosmic ray effects, correcting soft errors can't be an afterthought
  • Timely testing avoids cosmic ray damage to critical auto electronics
  • Do's and Don'ts of Architecting the Right FPGA Solution for DSP Design
  • FPGA soft processor cores spur single-chip systems






  • Related Content

    TECH PAPER
    1. Xilinx DSP Design Platforms: Simplifying the Adoption of FPGAs for DSP

    TECH PAPER
    2. Embedded Signal Processing Capabilities of the LatticeECP3 sysDSP Block

    WEBINAR
    3. ISE Design Suite 11 - The Design Methodology for Targeted Design Platforms

    TECH PAPER
    4. Floating Point: Have it Your Way with FPGA Embedded Processors

     


     Featured Jobs
    Ascension Health seeking Solutions Development Analyst in St. Louis, MO

    National Semiconductor seeking Principal IC Design Engineer in Santa Clara, CA

    Taylor Guitars seeking Sr. Web Designer in El Cajon, CA

    Covidien seeking Hardware Manager in Boulder, CO

    Sierra Nevada seeking Software Engineer in Hagerstown, MD

    More jobs on EETimesCareers
     Sponsor
     CAREER CENTER
    Ready to take that job and shove it?
    SEARCH JOBS:

     SPONSOR

     RECENT JOB POSTINGS
    For more great jobs, career related news, features and services, please visit EETimes' Career Center.