FPGA Horizons Journal Issue 3



(This article is from Issue 3 of the FPGA Horizons Journal. If you’d like to read more FPGA-related articles, you can download a PDF of the issue right now.)

Implementing functional safety in hardware and software

Martin Kellerman, Manager Marketing, Microchip Technology Germany GmbH Nikola Velinov, Senior Business Development Engineer, Green Hills Software

As embedded systems become more intelligent and interconnected, the margin for error in their operation narrows dramatically. From automotive electronics and industrial automation to medical and aerospace systems, functional safety (FuSa) has become a non-negotiable aspect of modern design.

To achieve safety compliance, engineers must combine deterministic, fault-tolerant hardware with safety-certified software that ensures predictable, verifiable performance.

Functional safety is about controlling failure, while continually striving to eliminate it. It accepts that faults caused by aging, interference, or random hardware events are inevitable, but ensures that when they occur, the system reacts safely.

This structured approach ensures that critical systems in robots, vehicles, aircraft and many other applications areas can detect, isolate, and respond to faults, minimizing the chance of harm or damage.

PolarFire FPGA and SoC devices, for example, are engineered specifically for high-reliability environments. Their non-volatile flash-based architecture makes them inherently resistant to single-event upsets (SEUs) on configuration data that can compromise SRAM-based designs. This immunity has been validated even in radiation-prone and space environments.

For safety certification of hardware designs, certified design flows like the Microchip Functional Safety Package provide documentation, reliability data, and design guidance to support compliance with SIL 3 (IEC 61508) and ASIL-D (ISO 26262) levels. This helps development teams align their processes and documentation with recognized safety standards.

However, hardware determinism alone cannot guarantee system safety. Software is increasingly responsible for control, coordination, diagnostics, system update, and system recovery — making its predictability and verifiability equally critical.

This is where software like Green Hills Software’s safety product portfolio comes into play: The safety-certified MULTI toolchain and the pre-certified INTEGRITY Real-Time Operating System provide a safe and secure foundation for application design and implementation.

Developing safe hardware

Developing safe hardware and software requires a dedicated development process, which focuses primarily on risk analysis, assessment and mitigation. Standards like ISO 26262 and IEC 61508 for example require the use of a process which follows the FuSa V-Model (figure 1).

Fig 1. The FuSa V-model mirrors development stages with corresponding test phases

FPGA designs are typically proprietary systems for targeted applications. However, common cause failures and their mitigation will employ similar means with a typical goal of avoiding single points of failures in all designs. On top of these common mitigations, the application-specific design elements can then be implemented, aided by the functional safety package.

Fig 2. The stacked layers of functionality which need to be tested

Based on the layered approach, the mitigations can be derived step by step. The correct functionality of the FPGA, for example, depends on the power supply being within specifications. This needs to be guaranteed from a system level, through an appropriate power management IC (PMIC), or with independent monitoring provided by a separate microcontroller with integrated ADCs. The integrity of the fabric configuration is guaranteed by the single-event upset immune FPGA fabric and only content in the fabric needs to be protected. This can be achieved by redundancy on flipflop structures and ECC in BlockRAMs (LSRAM). On SRAM-based FPGAs, mitigation schemes need to be implemented to monitor the integrity of the configuration and, when required, perform a reconfiguration. Additionally, for Microchip devices error-mitigation schemes can also be tested using SmartDebug, a tool which allows a non-altering intrusion into the design for testing the ECC-functionality. Other critical system components are PLLs and clocks. In contrast to standard microcontrollers, all FPGAs allow the monitoring of these components without dedicated hard logic. Using standard FPGA fabric, counters and checkers can be built based on independent clocks to continuously verify at run-time that clocks are within specified and designed frequency ranges to each other.

Fig 3. Adding an additional clock signal for monitoring and diagnostics

Should dedicated clock MUXes fail due to hardware failure this will be detected, and appropriate alarms can be raised to the system level. Typical communication interfaces provide protocol level protection to account for transmission errors. However, for basic IO-interfaces driving other basic components or actuators this protection is not present. To avoid single-point failures or stuck-at-x faults, antivalent interfacing or redundant outputs can be used (figure 4).

Fig 4. Monitoring using an external watchdog

Additionally, the external watchdog shown in figure 4 can determine whether the FPGA is still correctly reacting. Challenges and responses between the FPGA and, for example, an external controller used as watchdog extend the hardware fault tolerance from HFT0 on device level up to HFT1. With these approaches, hardware designs of SIL3 are possible.

Developing safe software

To create safe software, the software lifecycle also needs to be aligned with the development methodologies in use and industry standards. Such a process gradually takes higher-level requirements and translates them into source code, validating and verifying produced artifacts along the way. In the end, all artifacts like requirements, design documents, architecture documents, and software source code must be validated and verified.

When it comes to software, a key element of the process must be the assurance that the machine instructions processors execute match the quality level of the source code. A safety-certified toolchain, like the MULTI IDE from Green Hills Software, significantly reduces the effort required to achieve this level of rigor. The MULTI History viewer, for example, enables developers to find and solve bug or performance bottlenecks quickly by providing full visibility into complex systems.

Fig 5. The History viewer in Green Hills Software MULTI iDE

Just as an FPGA provides documentation for its proper configuration, so does a certified toolchain for governing its use in safe systems. This is key to achieving quality in the machine code generation process, which in technical terms consists of source code compilation and binary linking. When it comes to the functionality that a safe software-based system must implement, there are three categories: safe application, base software and additional safety mechanisms. The safe application is the core and implements features like safe communication, safe computing, safe actuation, etc. The base software is responsible for correctly configuring the processor cores and the peripheral devices which perform the I/O operations for the safe applications. Finally, the additional safety mechanisms include software that monitors the system for faults and reacts to these. A good example is where communication errors are detected and managed by end-to-end protection. A reaction to a fault must contain the fault and bring the system to a state where safe operation is guaranteed. A final note on software is that it exists in the context of the hardware it runs on. Faults in the hardware layer may bring the software to a state where it is not able to respond. Handling these faults requires a system-wide approach which is a cooperation between the software, the underlying hardware and external safety elements like watchdogs or PMICs.

This article is from Issue 3 of the FPGA Horizons Journal. If you’d like to read more FPGA-related articles written by FPGA engineers for FPGA engineers, why not go ahead and download a PDF of the issue right now?

Download the pdf