DO-254 Certification Guide for FPGA and Complex Electronic Hardware

What is DO-254?

DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) defines the process required to develop airborne electronic hardware with a level of rigor appropriate to its safety impact.

For FPGA-based systems, DO-254 is not just documentation—it is a full lifecycle discipline covering:

• Planning

• Requirements capture

• Design

• Implementation

• Verification

• Configuration management

• Process assurance

The objective is simple:

Demonstrate that the hardware performs its intended function with no unintended behavior, at the assigned Design Assurance Level (DAL).

Explore more about “What is DO-254?”

Design Assurance Levels (DAL)

• DAL A – Catastrophic failure condition

• DAL B – Hazardous

• DAL C – Major

• DAL D/E – Minor / No effect

For modern FPGA systems, most certification efforts target DAL A or B.

Explore more about “Design Assurance Levels (DAL)”

Why DO-254 is Challenging for FPGA

FPGAs introduce complexity that traditional hardware does not:

• Massive logic density

• Embedded processors (e.g., MicroBlaze)

• Third-party IP (often encrypted)

• Toolchain dependence (Vivado)

Key challenges:

• Traceability across abstraction layers

• Verification completeness (coverage)

• Tool qualification or mitigation

• COTS IP integration

Explore more about “Why DO-254 is Challenging for FPGA”

DO-254 Hardware Design Lifecycle

1. Planning

Core artifacts:

• PHAC

• HDP

• HVVP

• HCMP

These define how you will comply, not just what you will build.

⸻

2. Requirements

• Hardware Requirements (HRS)

• Derived requirements identification

• Bidirectional traceability

Common failure:

Requirements written at too high a level to verify.

⸻

3. Design

• High-Level Design (HLD)

• Detailed Design (HDD)

For FPGA:

• RTL architecture

• Clock domain crossings

• Reset strategies

• IP integration boundaries

⸻

4. Implementation

• RTL coding

• Constraints

• Synthesis considerations

Critical point:

Implementation must be traceable—not just functional.

⸻

5. Verification

This is where most programs fail or slip schedule.

Typical expectations:

• ≥ 90% structural coverage (DAL A target)

• Requirements-based testing

• Element-level verification

• Robust regression strategy

Key issue:

Late design changes invalidate coverage and artifacts.

⸻

6. Validation & Certification

Includes:

• SOI-1 through SOI-4 audits

• Test Readiness Review (TRR)

• Certification liaison engagement

DO-254 for COTS and FPGA IP

One of the most misunderstood areas.

Problem:

Most FPGA designs rely heavily on:

• AMD/Xilinx IP

• Third-party cores

• Embedded processors

These are typically:

• Encrypted

• Not developed under DO-254

Options:

1. Treat as COTS (limited credit)

2. Reverse engineer verification (inefficient)

3. Use certifiable IP with source access

⸻

Common Failure Modes

• Underestimating verification effort

• Poor requirements definition

• Late-stage design changes

• Inadequate coverage strategy

• Improper handling of third-party IP

⸻

What Actually Drives Schedule

Not coding.

The real drivers:

• Verification runtime (often days per regression)

• Coverage closure

• Requirements maturity

• IP integration complexity

⸻

©2026 Logicircuit, Inc.   All rights reserved.