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.

For the rest of this article, visit the Aldec Design and Verification Blog.

Related posts:

Tags: Aldec, do-254, DO-254 Compliance, do-254/cts, FPGA Design, FPGAs, Requirements Management, safety-critical, spec-tracer, Traceability

Categories: FPGA Design, Requirements Management

This entry was posted on Tuesday, August 25th, 2015 at 9:02 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.