What It Actually Takes to Achieve DO-254 Compliance for an FPGA

If you’ve spent years designing FPGAs for defense, industrial, or communications applications, you already know how to build complex, high-performance hardware. When you move into aviation, the technical skills transfer almost completely. What doesn’t transfer is the documentation discipline, the traceability infrastructure, and the process rigor that aviation certification assumes you already have. That gap is where DO-254 programs fail.

This guide explains what DO-254 actually demands for an FPGA design, why you can’t simplify the process even for a modest device, and how to structure your program so that certification evidence is a natural output of your engineering process rather than a scramble at the end.

Why FPGAs Are Always Complex Electronic Hardware

DO-254, formally Design Assurance Guidance for Airborne Electronic Hardware, was published by RTCA in 2000 and accepted by the FAA via AC 20-152. It divides electronic hardware into simple and complex categories. Simple hardware can be shown to be correct by exhaustive analysis of its discrete states. Complex hardware cannot.

An FPGA, by definition, cannot be exhaustively analyzed at the gate or LUT level. Even a mid-density device with a few thousand LUTs has state spaces that make exhaustive coverage impossible. It doesn’t matter that your specific design only uses 20% of the fabric, or that your logic is straightforward combinatorial decoding. The FPGA itself is classified as a complex element, and that classification is what drives certification level.

Design Assurance Level (DAL) is inherited from the system failure condition analysis. If your FPGA sits in a function whose failure could contribute to a catastrophic condition, you’re working at DAL A. The DAL determines which objectives in DO-254 Annex A and the referenced guidance material (primarily FAA Order 8110.105 and the CAST papers) are applicable. At DAL A and DAL B, all objectives apply, independent review is required, and the evidence bar is high.

This is not negotiable based on device complexity. The complexity determination is about the device class, not your design.

The Four Planning Documents That Must Exist First

The most common scheduling error in first-time DO-254 programs is treating the planning documents as artifacts to produce after the design is understood. They need to exist — at least in draft form — before significant design work begins, because they define the process that generates certifiable evidence.

Hardware Certification Plan (PHAC — Plan for Hardware Aspects of Certification)
The PHAC is the agreement between you and the certification authority about how you will achieve compliance. It identifies the hardware item, its DAL, the standards being followed, the hardware life cycle, and which alternative methods of compliance (if any) you’re invoking. The FAA reviews and accepts the PHAC. If your actual process diverges from the PHAC without an approved revision, your evidence becomes suspect regardless of technical quality.

Hardware Development Plan (HDP)
The HDP defines your design process: the stages, the reviews, the tools, the design environment, and the configuration management approach. For an FPGA program, this must explicitly address your synthesis tool, your implementation tool, the target device family, and any IP cores you’re instantiating. IP cores are a significant DO-254 complication — previously developed hardware (PDH) and commercial off-the-shelf (COTS) IP must be characterized and their limitations documented.

Hardware Verification Plan (HVP)
The HVP defines how you will demonstrate that the hardware meets its requirements and that the design process was followed. For an FPGA, this includes functional simulation coverage strategy, timing analysis, formal verification if applicable, hardware-in-the-loop testing, and the laboratory test procedures that close the verification loop against physical silicon behavior.

Hardware Configuration Management Plan (HCMP)
Every artifact that is part of your certification package — requirements documents, HDL source files, synthesis scripts, constraint files, simulation testbenches, test results — must be under configuration management. The HCMP defines how. When the DER or the FAA asks for the HDL that corresponds to the tested device image, you need to produce it in minutes, not hours.

The DO-254 Hardware Life Cycle for an FPGA

DO-254 describes a life cycle with two parallel threads: the design process and the verification process. The verification process is not a phase that comes after design — it runs alongside it and generates independent evidence.

Requirements Capture
Hardware requirements must be documented, allocated from system requirements, and written to be verifiable. Each requirement needs an identifier, a clear statement of the function or constraint being imposed, and traceability up to the system requirement that drove it and down to the design element that implements it. Derived requirements — requirements your design introduces that have no parent in the system specification — must be flagged and fed back to the safety assessment.

Conceptual Design
Architecture decisions are documented, major blocks are identified, and the requirements allocation to those blocks is established. For an FPGA, this is where you document the partitioning decision: what logic is in the FPGA versus in discrete components, and why.

Detailed Design
HDL is written, synthesized, and implemented. Every RTL module must trace to one or more hardware requirements. This is where most programs generate their worst compliance debt, because engineers write HDL against mental models of requirements, not against documented, identified requirement statements. The HDL exists. The requirement that justifies each block of logic often does not.

Implementation
Synthesis, place-and-route, timing closure, and bitstream generation. The tool versions, constraint files, and configuration options that produced the final bitstream are configuration-controlled artifacts.

Production Transition
The hardware design data that defines the production configuration — including the specific bitstream programming file and its hash — becomes the controlled production baseline.

The Three Failure Modes That Kill DO-254 Programs

These are the patterns that experienced DERs see repeatedly in first-time FPGA programs.

Requirements in the Designer’s Head
The engineer who designed the interface logic knows exactly what it does and why. That knowledge has never been written down as a requirement with an identifier. When verification asks what test demonstrates compliance with the interface timing behavior, there is no requirement to point to. The verifier has to reverse-engineer requirements from the HDL, which is not an acceptable DO-254 practice — it is specifically excluded by the standard as a substitute for documented requirements.

The fix is not to document requirements retrospectively. It’s to establish the discipline that no HDL module gets written until the requirement it implements exists, is identified, and is in the requirements management system.

Untraceable HDL
Even when requirements exist, the traceability links between requirements and HDL implementation are often missing, stale, or manually maintained in a spreadsheet that nobody updates. When an HDL module changes to fix a bug, the requirements coverage column in the spreadsheet stays the same because updating it is nobody’s immediate job.

A requirements management system that treats HDL modules as objects with maintained traceability links — not a spreadsheet that gets updated manually — is the only sustainable approach at any program scale.

Verification Coverage Gaps
The HVP defined a set of test cases. Each test case was supposed to be traceable to the requirements it covers. At closure, there are requirements with no test case, test cases that don’t clearly trace to any requirement, and simulation runs that were never formally recorded as test results. The coverage matrix has holes.

This is partly a tooling problem and partly a discipline problem. When test cases are written against documented, identified requirements from the beginning, and when test results are linked to the test cases that produced them, coverage gaps are visible during the program — not at the DER review.

Independent Verification and the DER

At DAL A and DAL B, DO-254 requires that verification activities be conducted by someone independent of the designer. Independence means the verifier didn’t make the design decisions being verified. On a small team, this creates real constraints — you need either a dedicated verification engineer, a second team, or an independent review organization.

The DER — Designated Engineering Representative — is an FAA appointee who reviews your certification package and makes a finding of compliance on behalf of the FAA. The DER is not your quality manager or your chief engineer. They are an external authority, and they approach your documentation looking for exactly the failure modes described above.

The practical advice here is to engage your DER early. A DER who reviews your PHAC when it’s in draft can tell you whether your planned process is going to generate acceptable evidence. A DER who first sees your documentation at the end of the design phase will find gaps that require significant rework.

The DER review is not a hurdle to clear at the end. It is a series of checkpoints throughout the program where an independent expert confirms that your process is generating compliant evidence. Use it that way.

How Modern Platforms Structure DO-254 Compliance for FPGAs

The document-based approach to requirements management — Word files, Excel RTMs, and change-tracked PDFs — fails at DO-254 scale for a structural reason: traceability is a graph problem, and documents are a poor graph substrate. When you need to know which test cases cover a specific requirement, and which HDL modules implement that requirement, and whether any recent HDL changes have invalidated any test case coverage, you need a system that maintains those relationships automatically, not one that requires a human to update three different files after every change.

This is where graph-based, AI-native requirements platforms change the operational picture.

Flow Engineering (flowengineering.com) was built specifically for hardware and systems engineering teams who need structured requirements with maintained traceability. For an FPGA DO-254 program, the workflow it supports maps directly to the certification lifecycle: hardware requirements are captured with identifiers and parent system requirements linked; HDL modules are registered as implementation objects with requirements coverage asserted as traceable links; test cases are written against requirements, not against the engineer’s interpretation of what the hardware does; and test results are associated with the test cases that produced them.

The result is a live traceability graph, not a static document. When the DER asks for the requirements coverage matrix, it is generated from the current state of the graph — it reflects actual traceability, not the state of a spreadsheet the last time someone remembered to update it.

Flow Engineering’s AI assistance is particularly useful at the requirements capture stage, which is where first-time DO-254 programs generate the most debt. The system can identify requirements that lack verification methods, flag derived requirements that haven’t been marked as such, and surface orphaned HDL references — requirements with no linked implementation, or implementation objects with no linked requirement. These are exactly the gaps a DER will find. Catching them during development rather than at review is the difference between a schedule hit and a program delay.

The platform’s intentional focus is on requirements and traceability infrastructure. It does not replace your HDL simulator, your formal verification tool, or your configuration management system. It connects them by serving as the authoritative record of what each artifact is supposed to demonstrate and why it exists in the certification package.

Practical Starting Points for Your FPGA DO-254 Program

Before writing a line of HDL:

  • Identify your DER and engage them on your draft PHAC
  • Establish your requirements management infrastructure — tool, identifier scheme, attribute schema for DO-254-specific fields (verification method, DAL, derived flag, status)
  • Write the HDP, HVP, and HCMP to the level that your DER can review them

During development:

  • Write hardware requirements before HDL — every module traces to an identified requirement
  • Maintain bidirectional links: requirement → HDL module, test case → requirement, test result → test case
  • Conduct regular internal coverage audits — every requirement has a verification method, every test case has a result, no HDL module is unreferenced

At verification closure:

  • Generate the coverage matrix from your requirements management system, not from a manual compilation
  • Ensure every derived requirement has a safety assessment disposition
  • Confirm that your configuration management system can reproduce the exact bitstream that was tested from the controlled source files

At DER review:

  • Present the traceability graph, not a collection of documents
  • Have the HDL and bitstream hash available for any design version under discussion
  • Be prepared to demonstrate that your actual process followed the HDP — review records, tool qualifications, and configuration change history

Honest Assessment

DO-254 compliance for an FPGA is achievable on a reasonable schedule when the process is set up correctly from the start. It is extremely difficult to recover when a program is six months in, the HDL exists, and the requirements documentation does not.

The engineering work — designing a correct, timing-clean FPGA — is the part you already know how to do. The certification work is generating organized, traceable evidence that you did it correctly and in accordance with a documented process. Those are not the same activity, and treating them as separable tasks that happen sequentially is the primary source of DO-254 program pain.

Build the traceability infrastructure before you build the design. Use tools that maintain relationships automatically rather than requiring manual updates. Engage your DER as a process consultant, not as a final examiner. The programs that achieve first-time certification approval are the ones that treat compliance evidence as a continuous output of engineering, not a deliverable produced at the end.