FPGA are very useful devices which are often designed into our customer’s designs along with things like ADCs or power ICs from Analog Devices. FPGA can implement microcontrollers and any glue logic required. In this blog I will discuss some of the issues related to functional safety and FPGA.

Firstly, what is an FPGA? An FPGA (field-programmable gate array) is an integrated circuit but instead of having dedicated on-chip logic it consists of reconfigurable logic and often hard macros including uC such as the ARM Cortex or A9 series (some uC are available in HDL/soft format also). The reconfigurable logic is generally in the form of arrays of logic blocks. FPGA manufacturers include Xilinx, Altera (now part of Intel), Lattice semiconductor and Microsemi. Being reconfigurable means that using an FPGA gives flexibility to your hardware that is normally only found in software solutions including the ability to make quick changes to your “hardware” which if using discrete ICs would take weeks or more and if using an ASIC would take several months. However from a safety point of view it means you get some of the headaches of software too.

The configuration of the FPGA is stored in on-chip flash or EEPROM for some FPGA but for the larger ones is stored in off-chip flash memory and loaded into RAM on the FPGA on boot up. The reconfigurable logic on the FPGA is often finalized using an HDL (hardware description language) such as Verilog or VHDL which looks very like software (I must add “Is Verilog software?” to my list of upcoming blogs).

Annex F of IEC 61508-2:2010 gives guidance on the avoidance of systematic errors during the design of digital ASICs (table F.1) and FPGA (table F.2). In effect table F.1 is relevant to the people who design FGPA chips, e.g. the engineers at Xilinx or Micro-semi and table F.2 is relevant to their customers who design what will be implemented within the FPGA.

Figure 1 - an extract from IEC 61508-2:2010 table F.2

Both tables give similar lists of measures ranked as HR or R depending on the SIL. HR standards for highly recommended and R for recommended.The meaning of R or HR seems to be interpreted differently by different people but for me it means that if an issue is marked as “R” you should provide a short justification for not implementing that measure, for something marked “HR” the justification needs to be much more detailed explaining why you in your wisdom know better than the experts who wrote the standard. Some of the items are actually marked as “HR*” which can be interpreted as no excuses just do it (we will ignore the fact that this is an informative annex and not supposed to contain any “shall” statements). The references under the “R”, “HR” etc. are meant to represent the effort at which this technique is to be implemented but the standard has no clear guidance as to what exactly low or high effort should mean in this regard.

The design flow for an FPGA implementation consists of steps such as the following

  • Create the description of the required circuitry in HDL (model based input possible too)
  • Choose a target FPGA with enough reconfigurable logic to handle your HDL
  • Use software tools to synthesize the behavioral code onto the available reconfigurable resources within the FPGA
  • Use a software tool to generate a bit stream representation of the above configuration which can be loaded into the FPGA

Now I would like to cover what I believe is the biggest concern with the use FPGA in safety applications, namely “soft errors”.

Soft errors have been covered in a previous “Safety Matters” blog. These are errors caused by alpha particles present in the packaging materials or neutron particles coming from space causing the stored values in RAM cells and FF to change state. While both an ASIC and an FPGA might contain RAM with the soft error concerns being similar, the issue with FPGA is that when the configuration of the programmable logic is stored in a RAM cell, a single bit upset effectively changes the hardware. For a hard wired ASIC the logic functionality is frozen and impervious to alpha and neutron particles but for an FPGA this is a real concern. If the soft error rate is taken as 1000 FIT/mega bit (see IEC 61508-7:2010) then an FPGA with 1 million configuration bits will have a soft FIT of 1000.

Guidance given at a Raytheon FPGA seminar, I attended in Albuquerque two years ago, quoted NASA and US Air force requirements that said that due to SEU (single event upsets) a failure rate of 1e-4/h for proven stable parts and 1e-2/h for unstable parts should be used in reliability calculations with some organizations assuming a failure rate of 1! I have seen the same failure rate assumptions mandated for software (I believe it was in a medical standard).

I note that IEC 62380:2004 allows a calculation of the hard FIT for an FPGA and even there the λ1 value of 20e-5/h for each transistor is high compared to 3.4e-6 for uC and DSP.

Other concerns with FPGA in a safety applications include:

  • Obsolescence – FPGA are often designed on the bleeding edge of technology and can go obsolete- to achieve the performance of an ASIC on 65nm you might need to get an FPGA designed on 20nm due to the overhead that comes with the reconfigurable logic
  • Single bit and multi-bit upsets caused by power supply sequencing and EMC
  • How to implement on chip hardware fault tolerance (see note 13 in IEC 61508-2:2010)
  • Achieving high digital fault coverage. Table F.1 requires > 98.5% for a digital ASIC but there is no minimum requirement given for an FPGA once it has been programmed
  • The relevance of IEC TS 61508-3-1:2016
  • FPGA are most likely expensive compared to ASICs implementing similar functionality
  • The extra responsibility placed on the user of the FPGA to implement HDL code where HDL coding is probably not the company’s core competency
  • Limited temperature ranges compared to dedicated industrial or automotive ICs
  • Relatively high power (can lead to worse reliability numbers if nothing else)
  • Cyber security issues related to the logic programmability over a serial interface

"One of the basic rules of the universe is that nothing is perfect. Perfection simply doesn't exist... without imperfection, neither you nor I would exist."

~ Stephen Hawking

Despite the concerns, the flexibility of FPGA especially for rapid prototyping and quick time to market, the fact that one hardware solution can be customized to several end applications without redesigning your PCB and the ability to connect to almost anything make them really useful. This is especially true for low volume and proof of concept designs. For instance, try finding a nice industrial processor with a MIPI interface, it is not easy but for an FPGA you just implement the glue logic in HDL and you are good to go.

For more information on the use of FPGA to implement safety functions see

  • FPGA for Dummies – a free “book” available online from Altera
  • IEC 62256-2:2017 – Nuclear power plants - Instrumentation and control systems important to safety – Development of HDL programmed integrated circuits for systems performing category B and C functions
  • IEC 62256-1:2012 – Nuclear power plants - instrumentation and control systems important to safety – Development of HDL programmed integrated circuits for systems performing category A functions
  • NT technical report – Guideline for design and safety validation of safety-critical functions using hardware description language

This week’s video is not related to FPGA but is related to Safety inspection and competence. I was keeping it for a later blog but I was stuck for a video today – Please watch: https://www.youtube.com/watch?v=_Rsk1quUps0