DO-254 Compliance

RTCA/DO-254 is a means of compliance for the development of airborne electronic hardware containing FPGAs, PLDs and ASICs. FPGA design and verification under DO-254 guidelines is a rigorous undertaking and requires special features and capabilities from design, simulation and hardware verification tools. The Federal Aviation Administration (FAA)and other international certification authorities recognize the use of commonly used tools for FPGA design and verification such as RTL Simulator, Synthesis, Place & Route and Static Timing Analysis. For DAL A and B FPGAs, the FAA also recognizes other tools that improve design, verification, traceability and project management including Requirements Management, Traceability, Tests Management, Design Rule Checker, Clock Domain Crossings (CDC) Analysis, Code Coverage and FPGA Physical Test Systems.

Aldec’s specialized tools for design and verification of FPGAs boost productivity and help applicants achieve DO-254 compliance: Spec-TRACER, ALINT-PRO, Active-HDL and DO-254/CTS. Aldec’s tools have been implemented and deployed by several major avionics companies, accepted by certification authorities, and proven to decrease the FPGA design and verification cycle from months to weeks.

Sie sehen gerade einen Platzhalterinhalt von Standard. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf den Button unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Weitere Informationen

HDL Coding Standards

HDL Coding Standards (Safety-Critical Designs)

In order to prevent potentially unsafe attributes of HDL code from leading to unsafe design issues, the use of HDL coding standards is required by various safety-critical industries such as DO-254. The HDL coding standards must be defined, reviewed and documented. ALINT-PRO™ is a fully automated design rule checker equipped with industry-proven VHDL/Verilog standards and provides an automated code review. The VHDL/Verilog standards included cover essential areas in HDL coding such as coding style, readability, simulation, clock/reset management, design reuse, coding for safe synthesis and implementation, clock domain crossings (CDC) and design for test (DFT).

It is not possible to specify all design requirements by using HDL code only. The SDC format is used for describing various requirements and ALINT-PRO supports an essential subset of SDC commands for more accurate linting results. In addition, block-level constraints mechanism and constrained built-in vendor libraries ensure that even design with black-boxes is fully constrained for a complete analysis.

ALINT-PRO™ also provides robust documentation features beneficial to reporting, audits and reviews. ALINT-PRO™ features a Violation Viewer for detected violations and Waivers mechanism that allows associating “irrelevant” violations with the appropriate justification comments. Being tightly integrated with the coding standard violation analysis and reporting interfaces, these features enable push-button reporting and facilitate the desirable practice of creating quality design artefacts essential to obtaining compliance with the requirements outlined in the various safety-critical design assurance standards.

HDL Coding Standards

Additionally, Clock Domain Crossing issues like non-synchronized CDC transfers, convergence/divergence, combinational logic on CDC paths and incorrect synchronizer structures detected during linting process can be easily investigate by using dedicated windows like CDC Viewer, CDC Schematic and RTL Schematic.

Usage & Benefits:

  • Reduces cost of review vs. manual labor
  • Based on comprehensive knowledge base of industry best practices and design expertise
  • Code is more consistent and efficient vs. manual review approach
  • Reviews can be performed more often, a good match with DO-254 philosophy
  • Integrated debug environment for efficient design analysis and documentation

Tool Assessment and Qualification Process

The purpose of tool assessment and qualification in DO-254 is to ensure that the tool is capable of performing the particular design or verification activity to an acceptable level of confidence for which the tool will be used. Before using any tools in DO-254 for any design and verification activities, a tool assessment should be performed. If necessary, a basic tool qualification should be documented and recorded.

Aldec has done the due diligence to rigorously test its tools according to the stringent process defined in RTCA/DO-254 Section 11.4 Tool Assessment and Qualification Process. Whenever feasible, Aldec recommends manual review of the verification results in order to claim independent assessment. If manual review is not feasible, then Aldec provides specific Tool Qualification Data Packages for specific Aldec DO-254 tools.

DO-254 Independent Assessment

DO-254/CTS™ Tool Qualification Data Package

Includes a comprehensive pre-tool qualification data package that the applicant can easily adapt into their life cycle data. This data package is recommended to be used for design assurance level (DAL) A and B FPGAs where reliance to the tool’s automatic capabilities is critical to testing the target FPGA. Included in the data package are:

Tool Qualification Plan

The tool qualification plan is to show that DO-254/CTS behaves as expected and will not fail to detect any design errors to an acceptable level of confidence. The DO-254/CTS components such as custom CVT software, custom daughter board and COTS mother board will be rigorously tested using the diagnostic design provided by Aldec. The diagnostic design mimics the customer design under test (DUT) in terms of I/O interface and clocking.

Tool Operational Requirements

Specific tool operational and functional requirements have been captured and grouped into 5 categories: Information, Diagnostic, Configuration, Error Detection and Comparison.

Tool Test Plan

Test cases have been captured to verify the specific tool requirements. Each test case includes test description, test procedure, VHDL design, test scripts, input files and expected results. Each test can be repeated by the customer in their lab using the provided test scripts.

Tool Qualification Accomplishment Summary

Documentation of the test results for determining whether test cases passed or failed including the traceability matrix between tool requirements, test cases and test results. Also includes review activity reports for tool requirements, tool test cases and test results. Reviews are conducted by Aldec personnel based on a checklist.

ALINT-PRO™ Design Rule Checker Tool Qualification Package

The customizable tool qualification package includes the comprehensive test suite and documentation required to prove that the design rule checkers available in ALINT-PRO™ behave as intended for a user project. This package is recommended to be used for projects with A and B Design Assurance Level (DAL) where ALINT-PRO™ is used to enforce the HDL coding standard. The qualification package contains:

Qualification Test Suite including HDL source files, scripts and patterns required to verify whether the ALINT-PRO™ tool properly detects design rule violations. The test suite covers all ALINT-PRO™ rules selected by the user to be included in the project. Every rule checker is verified in isolation from other checkers against positive and negative cases.
The user can execute the test suite on the desired environment to get the final report confirming the correct behavior of the tool.
Qualification Document including the tool description, tool operational requirements, qualification test plan along with test descriptions, qualification tests results and traceability between the user’s design standard requirements and ALINT-PRO™ linting rules.

Active-HDL™ and Riviera-PRO™ Code Coverage Tool Qualification Data Package

Currently, the guidance described in RTCA/DO-254 Section 11.4.1 #4 states that when Code Coverage tool is used to satisfy Elemental Analysis, tool qualification is not needed. However, some certification authorities have required Code Coverage to undergo tool qualification for specific DO-254 programs. Aldec has therefore done the due diligence to rigorously test Active-HDL™ and Riviera-PRO™ Code Coverage under stringent tool qualification process defined in RTCA/DO-254 section 11.4. The requirements generated to test Code Coverage are based on the executable constructs of VHDL Language Reference Manual (LRM) from chapter 4, 10 and 11 of IEEE Std 1076™-2008 VHDL LRM. Aldec provides a data package that includes VHDL test cases and extensive documentation containing the tool description, tool operational requirements, qualification test plan along with the test descriptions, and qualification test results. The qualification package proves that the Code Coverage Tool available in Active-HDL™ and Riviera-PRO™ shows accurate branch and statement coverage metrics.

Independent Tool Assessment of HDL Simulator

HDL simulators such as Active-HDL, Riviera-PRO and other 3rd-party HDL simulators can be independently assessed by DO-254/CTS. Since the testbench from RTL simulation can be reused by DO-254/CTS as test vectors during FPGA physical testing, mapping and matching the physical testing and RTL simulation results can be easily accomplished.

FPGA Level In-Target Testing

In compliance with RTCA/DO-254 and FAA AC 20-152, verification of FPGA/PLD level requirements must be done to ensure completeness of testing. DO-254/CTS™ is a fully customized hardware that provides FPGA level verification for the target device. The target FPGA device is isolated in a custom board which is stimulated by the simulation testbench running at full speed allowing a comprehensive and automated functional test for all FPGA level requirements in a single environment.

Target Device Testing and At-Speed Testing

This tool consists of custom hardware that contains the specific family/package or part number of the FPGA/PLD device from vendors such as Altera, Microsemi (Actel) and Xilinx. It allows streaming of test vectors through the FPGA inputs at the required operational speed using real clocks in excess of 250 MHz. If the required simulation time is 500ms, then hardware testing completes within 500ms. Additional features to vary the frequency and voltage to +-10% can also be used for robustness.

Automatic Generation of Test Vectors for Hardware Testing

Development of test vectors for hardware testing for an average Level A/B design normally takes 6-12 months manual engineering time. This tool is equipped with a utility that converts the testbench within minutes into test vectors to be used for hardware testing. This ensures the same requirements that are verified in the RTL simulation are verified again for in-hardware verification. Therefore, FPGA level requirements are preserved and verified from RTL simulation to hardware testing per RTCA/DO-254 specification section 6.2. No changes to the testbench are necessary.

Single-Environment to Verify all FPGA Level Requirements

Traditionally, multiple sets of testing environment must be created to verify multiple sets of FPGA requirements, and this usually entails manual connections/bypasses of wires and cables which are prone to errors and bugs. One of the primary goals of this tool is to prevent such cases. This tool consists of custom hardware (PCIe interface) and software providing a single environment to test all FPGA level requirements.

Automated In-Hardware Testing

This tool is a %22push-button%22 automated in-hardware testing environment to test all FPGA level requirements. It is equipped with a utility to automatically compare RTL simulation results with hardware testing results. The utility displays either a PASS or FAIL message in which results can be further investigated using a standard waveform viewer.

Hardware Testing Results Visualization with Waveform Viewer

The capabilities for capturing/recording and visualization of hardware testing results using Logic Analyzers and Digital Oscilloscopes are limited. This tool allows capturing and visualization of results using the simulator’s standard waveform viewer, providing storage for waveform files of up to 16TB and capturing of results immediately after simulation. Comparison between RTL simulation and hardware testing results is also possible.

Integration with 3rd Party HDL Simulator, Synthesis and P&R Tools

This tool can be used with any 3rd party HDL Simulator, Synthesis and P&R tools.

HDL Detailed Design and Verification

HDL development and verification under DO-254 guidelines is a rigorous undertaking and requires special features and capabilities from HDL design and simulation tools. Active-HDL™ or Riviera-PRO™ provides features for graphical design creation, verification, management, and documentation facilitating a flexible and seamless design and verification platform.

HDL Graphical Entry: Block Diagram Editor and State Machine Editor

The Block Diagram Editor is a tool for graphical entry of VHDL, Verilog and EDIF designs. If the HDL design is in large part structural, it may be easier to enter its description graphically as a block diagram, rather than typing hundreds of source code lines.

The State Diagram Editor is a tool designed for the graphical editing of state diagrams of synchronous and asynchronous machines. Drawing a state diagram is an alternative approach to the modelling of a sequential device. Instead of writing the HDL code manually, the designer can enter the description of a logic block as a graphical state diagram.

HDL Code To Graphics Converter

The code to graphics converter is a tool designed for automatic translation of VHDL or Verilog source code into block and state diagrams. It analyzes VHDL, Verilog, or EDIF source files and generates one or more block diagram files depending on the number of design entities, modules, or cells found in the analyzed file. The resulting block diagram files can be automatically attached to a design.

VHDL 2019 Simulation

The latest IEEE Std 1076-2019 standard brings long-awaited improvements and new testbench-related features such as the mode views for composite types and subtypes, inferring signal and variable subtype constraints from an initial value, conditional assignments of initial values, conditional subprogram return statement, conditional analysis directives, garbage collection, etc. Since VHDL is still considered to be safer than Verilog or SystemC, these new testbench-related features, together with OSVVM and UVVM VHDL verification libraries, are significant enhancements for the widely used VHDL 2008 standard. For better compatibility, VHDL 2008 is the default mode for simulation. The user can switch to the newest VHDL 2019 version as well as to the previous 2002 or 1993 versions.

Verilog/SystemVerilog and System C Simulation

Despite most of the DO-254 projects adopting VHDL as the primary design language, SystemVerilog and SystemC become more popular for verification activities. Active-HDL and Riviera-PRO are mixed language simulators with Verilog/SystemVerilog and SystemC support including the latest verification libraries like UVM and OVM.

HDL Debugging and Post-Simulation Debug

Aldec simulators offer a number of features to effectively debug errors and verify the behaviour of the design. Active-HDL interactive debugging features include Source Code Tracing, Breakpoints Insertion, Block Diagram Graphical Debugging and State Machine Graphical Debugging. Multiple windows to view simulation results are also available from Active-HDL including List (Delta) Viewer, Watch Window, Processes Window, Waveform Viewer, Dataflow Window and Call Stack Window. Riviera-PRO is an advanced verification platform offering debugging capabilities at different levels of abstraction. The tool features UVM Toolbox, UVM Graph, Class Viewer, Transaction Streams, Plot and Image Viewers for debugging at higher level of abstraction and interactive debugging tools like Code Tracing, Waveform, Dataflow, FSM Window, Coverage, Assertions, Memory Visualization Capabilities for the lower level abstraction.
Post Simulation Debug is a very useful feature that allows debugging a project in the %22off-line%22 mode (without a connection to the simulator). The engineer can perform only one regular simulation to collect the post-simulation data and then analyze the design as many times as needed in the post-simulation mode. Moreover, the engineer can share the results of the simulation with others as well as use post-simulation files prepared by anyone on a different computer.

Waveform Viewer/Editor and Tracing Unknown Values

Waveform Viewer is a tool designed to display simulation results in the form of graphical waveforms. During simulation, the simulation kernel outputs waveforms for selected signals and variables in the Waveform Viewer/Editor window. Waveform Viewer/Editor includes a number of useful features like Cursors, Virtual Objects, Transactions, Assertions, Analog Representation, Comparison and Signal Navigator. Waveforms can be re-applied as test vectors to signals and nets during subsequent simulation runs. Comments and marks can be inserted into the waveforms and then can be printed or exported into a PDF or HTML for documentation purpose.

Unknown and uninitialized values (%22x%22, %22w%22, -, etc.) can be a source of an unexpected behavior on output ports of a tested entity/module. XTrace is a command-line utility that allows detection and reporting of unknown values when they first appear and before they are propagated through a design. It allows stopping the simulation when an unknown value is assigned to any of monitored signals. Corresponding messages about unexpected values, signals and the time when those values were detected are also displayed in the console window.

Assertion Based Verification

Assertions can be used both for detecting errors in a design and for verifying and describing complex sequences of events. Assertions can be used to verify requirements. Assertions can be encapsulated in reusable units with parameterized verification rules, providing the possibility to create independent checkers, specialized for user-defined or universal protocols frequently used in designs. PSL and System Verilog Assertions are supported.

Code Coverage and Toggle Coverage

Code Coverage is a debugging tool that aids the verification process. Code Coverage is also used to support Elemental Analysis, an advanced verification approach described in RTCA/DO-254 Appendix B 3.3.1. Aldec simulators allow verifying source code with the following coverage tools:

Statement Coverage shows execution branches for each HDL statement. This information provides feedback on which parts of the design were verified and which are untested. It also helps to locate dead code.

Branch Coverage collects execution branches for the “if” and “case” constructs, as well as VHDL, selected and conditional signal assignment statements.

Expression Coverage factorizes logical expressions and monitors them during simulation.

Condition Coverage is an extension of Expression Coverage that monitors and factorizes logical expressions used in conditional statements. This type of coverage monitors expressions that occur as a condition within constructs such as “if then”, “while”, and so on.

FSM Coverage allows the user to identify not visited states and not evaluated transitions.

Path Coverage collects information about the program execution and analyzes whether all combinations of program sequences (program paths) are verified by a testbench. A program path is a sequence of statement executions performed in a particular order. The tool also collects information about how the consecutive statements are executed, the examined branches, and how logical conditions are evaluated during simulation.

Toggle Coverageis a program that measures a design activity within terms of changes of signal logic values. Toggle Coverage creates a report that provides information: whether monitored signals were initialized, whether monitored signals experienced rising and/or falling edges, and the number of rising and falling edges during the simulation session. The report helps verify the quality of stimulus and locate non-active structures of the design. Signals that were not initialized during the simulation or are not exercised properly by the testbench can be easily identified.

Source Revision Control and Design Documentation Capabilities

Source Revision Control allows operating on subsequent versions and revisions of design source files directly from the HDL simulator environment. In such an environment, it is possible to track the changes in a design and view differences between subsequent versions of files. The Source Revision Control system also makes team work easier as it allows a group of designers to work on the same project. Once the files are archived in a repository, they are available to other team members. Additionally, all changes that have been made to any file are saved with a full history, so you can recover any version of any file at any time. Members of your group can see the latest version of any project, make changes, and save a new version in the Source Revision Control system database.

Design documentation for DO-254 certification is a necessity. Active-HDL consists of powerful documentation features allowing the engineer to create a textual or graphical representation of the workspace or design in HTML or PDF format. All design elements such as design files, waveforms, block diagrams and attached documents can be exported to HTML or PDF documents which can be controlled by various options in the wizard. The resulting documents always preserve the hierarchy of the design which provides easy navigation in complex designs. Export to vector graphics capability maintains the high resolution of schematic files in the generated document.

Integration with 3rd Party Synthesis and P&R Tools

Active-HDL’s Design Flow Manager provides seamless interfaces with 3rd party synthesis and P&R tools and facilitating a unique platform that can be used throughout the FPGA design flow.

DO-254 Templates and Checklists

DO-254 Compliant Templates and Checklists Data Package

Developing PLDs (FPGAs, ASICs and CPLDs) for DO-254 compliance entails that applicants submit extensive professional documents and artifacts to the designated certification authority. It is the applicant’s responsibility to author and create the documents and review them with the highest scrutiny against a high-quality checklist.

Organizations new to DO-254 find it difficult to start a new DO-254 program without a baseline of the required documents and review checklists, and organizations experienced in DO-254 seek to improve their existing baselines due to lessons learned from previous programs. Aldec’s data package developed by an FAA Consultant DER through many years of auditing several DO-254 programs with design assurance level (DAL) A, B, C and D FPGAs provides significant value to both new and experienced DO-254 practitioners.

This data package includes DO-254 templates and review checklists included in Spec-TRACER can be easily adopted by applicants as a starting baseline for generating company standard documents and artifacts Spec-TRACER provides the single environment where multiple stakeholders can capture, manage versions/baselines, conduct reviews and generate reports.


This data package includes 16 templates for creating documents categorized as Hardware Management Plans, Hardware Standards and Hardware Life Cycle Data. Specific sections required in a DO-254 project for PLDs are included in each template. There are also 5 templates (PHAC, HRD, HVVP and TCD) that include specific examples on how to word certain sections of the documents.

DO-254 Templates


Checklist Criteria

This package includes the criteria for performing reviews for compliance to hardware management plans in accordance with DO-254. These are the criteria used to create the review checklists used for verification activities that are typically referenced from the Hardware Verification Plan, Hardware Validation Plan, and/or Hardware Verification & Validation Standards. The complete set of review criteria includes:

DO-254 Review Checklist

The checklists have a set of criteria to be applied in the review of DO-254 PLD hardware life cycle data and documents. These criteria are part of the hardware verification standards. These criteria are part of the hardware verification standards. Each criteria should be applied to the respective document or data. For instance, the “DO-254 PLD Plan for Hardware Aspects of Certification Review Criteria” is used to review a Plan for Hardware Aspects of Certification document.

For documents or data with multiple repeated elements, the criteria in the checklist should be applied to each element of the document. This should be done with the requirements, design, test cases, test benches, test procedures, and test results. In these cases, the criteria can be put in a table across the columns and the identifier of the review item listed in the rows.

The criteria are general and as complete as possible. Each project may have additional review criteria that can easily be added. Additional criteria can come from company standards, experience from other projects, ideas that arise during the course of a project, FAA Issue Papers, EASA CRIs, or criteria from other certification authorities.