Developing High-Reliability FPGAs For DO-254

You have been developing FPGAs for a long time, and you know your designs from top to bottom. You know every interface protocol, configuration and optimization. You can visualize your timing diagram like you can visualize your upcoming vacation in Hawaii. You can manually write down your memory mapping accurately while under oath. You can pinpoint all CDC paths and emulate metastability in your mind. You are confident that your designs are fault-tolerant and will function as intended. You are the master of your domain.

But… can you bet your life on it?

Are you willing to bet your life on your designs? What about the lives of the thousands of passengers sitting on the airplanes where your FPGA design is installed? How certain are you that it won’t fail in the field? If it were to fail, can it resume normal operation safely and timely? Not just most of the time, but every time?

An FPGA installed on commuter aircraft systems with DAL A criticality level has 10^⁻⁹ probability of failure per flight hour. A failure of DAL A FPGA is classified as Catastrophic Failure Condition, in which a failure prevents the safe flight and landing of the aircraft resulting in fatalities of all occupants. The FAA calls this “Extremely Improbable”. The FAA further requires that “no single failure will result in a Catastrophic Failure Condition.”

Developing FPGAs for DO-254 compliance is serious business.

What does it mean to develop FPGAs for DO-254 compliance?
What type of development process is required? What type of data and documentation are required? What type of design philosophy is expected from organizations?

In order to comply with DO-254, organizations will need to:

• Establish a structured development process that meets the 34 objectives defined in the RTCA/DO-254 document;
• Establish a requirements-based verification process;
• Establish a configuration management process;
• Establish a process assurance role or department;
• Conduct peer reviews of data against a checklist with consideration for independence for DAL A and B;
• Interface with the customer or airframer;
• Interface with FAA DER regularly and conduct formal reviews with FAA DER
• Produce and organize the required hardware design life cycle data such as planning documents, design and verification standards, requirements documents, traceability data, design and verification data, test cases for simulation, test procedures for testing, problem reports, review and analysis reports and summary reports.

What is the hardware development process defined in DO-254?
DO-254 introduces a structured hardware life cycle that consists of three main parts: Planning, Hardware Design Processes and Supporting Processes. Each main part includes one or more processes that define a list of objectives that must be satisfied by the applicant in order to achieve compliance.

Planning Process (covered in RTCA/DO-254 Section 4) — This is the first step in which the applicant defines the overall plan by which the FPGA will be developed based on the functional and airworthiness requirements. The applicant selects and defines the hardware design life cycle processes, standards, design and verification environments and the means of compliance to the list of objectives.

Hardware Design Processes (covered in RTCA/DO-254 Section 5) – The processes introduce a requirements-based design process, which means all of the design data must be based on the requirements. Any functions of the final FPGA that are not based on the requirements must be properly mitigated in order to prevent anomalous operational behavior. There are 5 sub-processes that sequentially produce the FPGA device that fulfills the requirements:

• Requirements Capture (covered in RTCA/DO-254 Section 5.1) – This is an iterative process where the FPGA requirements are captured and defined. Requirements that are allocated from the circuit board become allocated FPGA requirements, and requirements that are created as a result of a design decision become derived FPGA requirements. FAA DERs pay a great deal of attention to derived requirements to ensure that they do not impact safety. Derived requirements must go through Validation Process.
• Conceptual Design (covered in RTCA/DO-254 Section 5.2) – Produces a high level design concept consistent with the FPGA requirements. Major peripherals, intellectual property (IP) and FPGA device are selected and defined. The concept design includes functional block diagrams, state machines and architecture description/constraints.
• Detailed Design (covered in RTCA/DO-254 Section 5.3) – Development of the HDL code consistent with the FPGA requirements. The HDL code must adhere to selected HDL coding standards and traceable to FPGA requirements. This process produces the synthesizable register-transfer logic (RTL) for the FPGA.
• Implementation (covered in RTCA/DO-254 Section 5.4) – Involves Synthesis and Place & Route and produces the programming file or fusefile for the FPGA. Proper steps must be taken to ensure that the Synthesis and Place & Route optimization switches do not change the designer’s intended design description.
• Product Transition (covered in RTCA/DO-254 Section 5.5) – Establishes the baseline that includes design and manufacturing data for consistent production and replication of the FPGA.

Supporting Processes (covered in RTCA/DO-254 Section 6 – Section 9) – For each step of the hardware design process, the corresponding activities described in the supporting processes must be performed.

• Validation and Verification (covered in RTCA/DO-254 Section 6) – This process introduces a requirements-based approach, which means that the FPGA must go through validation and verification against the requirements. The Validation Process provides assurance that derived requirements are correct and complete in relation to upper level requirements such as circuit board requirements. The Verification Process provides assurance that the final FPGA device functions as intended as defined in the requirements. Examples of validation and verification methods include reviews, functional simulation, timing simulation, static timing analysis and device testing. Traceability is an aspect of validation and verification in which the applicant must ensure bi-directional traceability between circuit board requirements, FPGA requirements, HDL design, verification test procedures and test results.
• Configuration Management (covered in RTCA/DO-254 Section 7) – Involves a controlled method of how the life cycle data must be configured consistently for the purpose of replication, regeneration and modification if necessary. Activities include configuration identification, baseline establishment, problem reporting/tracking/corrective action, change control and release/archive/retrieve. Two data control categories are defined: hardware control category 1 (HC1) and hardware control category 2 (HC2). HC1 is more stringent than HC2.
• Process Assurance (covered in RTCA/DO-254 Section 8) – Ensures that all of the objectives are satisfied and life cycle data adhere to the approved plans. The activities for this process include review of life cycle data based on checklist, audits of problem reports and peer review records and documentation of deviation and corrective action.
• Certification Liaison (covered in RTCA/DO-254 Section 9) – Establishes communication and agreement between applicant and certification authority throughout the project cycle. Activities include design approach presentation and approval, negotiations regarding means of compliance, stage of involvement audits and witnessing of tests.

As many lives are at stake once FPGAs go airborne, developing FPGAs for DO-254 compliance is a tremendous responsibility. However, FPGA developers new to DO-254 can rest easy in the knowledge that experienced DO-254 practitioners have successfully developed safe and high-reliable FPGAs efficiently simply by following the guidance described in DO-254. With their great experience, these practitioners perceive DO-254 as a well-structured development process that is rooted in pure engineering best practices for high-reliability designs.

If you are new to DO-254, and are just beginning to study the process, I recommend starting with this white paper, Introduction to DO-254. This document can serve as your starting point to begin your education in DO-254 guidance and regulation, and provides an overview of RTCA/DO-254 purpose, scope and processes, and links to most of the publically DO-254 related documents and FAA guidance.