Get in Toucharrow


DO-254 Verification

Faststream Technologies RTCA DO-254, “Design Assurance Guidance for Airborne Electronic Hardware” is currently recognized by the FAA via FAA AC 20-152 as a means of compliance and guidance for the design assurance of complex electronic hardware such as FPGAs,Pcie, PLDs and ASICs in airborne systems.

PCIe verification for DO-254



Faststream Technologies RTCA DO-254, “Design Assurance Guidance for Airborne Electronic Hardware” is currently recognized by the FAA via FAA AC 20-152 as a means of compliance and guidance for the design assurance of complex electronic hardware such as FPGAs,Pcie, PLDs and ASICs in airborne systems.


The Challenges in Hardware Verification


 Functional verification of digital designs in real hardware has been a serious undertaking when designing under DO-254 standard. Chapter 6.2 Verification Process of DO-254 species that requirements must be preserved and verified from RTL simulation stage to hardware verification stage. In doing this, designers are presented with significant challenges such as:


  • Limited controllability and visibility of FPGA I/Os
  • Ensuring RTL simulation and hardware testing results match
  • Development of test vectors to cover all design requirements
  • Results capturing and documentation
  • Lack of automation in the verification cycle


The Solution


Faststream’s DO-254/CTS is a certiable at-speed in-target testing environment for Level A/B complex designs, and is dedicated to address the stringent guidelines of DO-254 Chapter 6.2 Verification Process.  DO-254/CTS consists of a fully customized hardware and software package designed to replay RTL simulation during hardware testing without any changes to the DUT and testbench.  It provides a single and automated environment to test all FPGA level requirements ideal for DO-254 hardware verification.  

The components of DO-254/CTS are:


  • COTS Motherboard- PCIe-PCIe  Interface
  • Custom Daughter Board
  • Custom Software Package


Top Features


  • At-Speed Design Verification in Target Devices
  • Automatic Test Vector Generation for Target Devices
  • Auto-Capture and Analysis of results at all Design Stages
  • Easy Design Requirements Traceability
  • Independent EDA Tool Assessment
  • Significantly shortens Device Verification Time


KEY Benefits


PCIe Level In-Hardware Verification


In compliance with the document FAA AC 20-152, verification at the PCIelevel must be done to ensure completeness of testing.  PCIe level verification is performed before system level verification.  All FPGA level requirements verified using DO-254/CTS do not have to be verified again at the system level per RTCA/DO-254 specification.


Running at Required Operational Speed in excess of 250 MHz


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.  DO-254/CTS is equipped with a utility that converts the test bench within minutes into test vectors to be used for hardware testing.


Hardware Testing Results Visualization with Waveform Viewer


Allows capturing and visualization of results using the simulator’s standard waveform viewer, providing storage for waveform les of up to 16TB and capturing of results immediately after simulation.


Single-Environment to Verify all FPGA Level Requirements


It consists of custom hardware with PCIe interface and software providing a single-environment to test all FPGA level requirements, specifically designed to avoid manual bypasses of cables and wires which are typically prone to errors and bugs.


Automated In-Hardware Testing


DO-254/CTS is a “push-button” automated in-hardware testing environment to test all FPGA level requirements.  It is equipped with a utility to automati-cally compare RTL simulation results with hardware testing results.  The utility displays either a PASS or FAIL message in which results can be further investi-gated using a standard waveform viewer.


Target Device Testing


The design must be tested in the target device per RTCA/DO-254 specification sections 1.1 and 6.3.1.  DO-254/CTS consists of a custom daughter board that contains the specific family/package or part number of the FPGA/PLD device .From vendors such as Altera, Lattice, Microsemi (Actel) and Xilinx.

RTL Code Functional Verification For DO-254



The development of a design is typically 80 percent reuse of existing RTL code from a previous project with 20 percent new development. The variability of the reused and new design code styles and quality can greatly affect usability and maintainability as well as cause unintended issues not found until the verification or synthesis processes. Sample quality issues include: over- or under- specified sensitivity lists, dead-end states in state machines, and blocking versus non-blocking assignments. These issues can change the results between verification and synthesis. While these problems might be discovered later in the design process, it is harder to fix them and design flow iterations will be required. It is more efficient to check for issues at the RTL reuse and coding stage; fixing any violations at that time is most cost-effective.

Faststream Technologies is implementing an automated method to measure RTL to a company standard improves overall productivity by eliminating variability in design code quality. For example, defining a weighted set of linter rules that the designer can run at any time during RTL development augments manual code inspections within the assurance process. In turn, this process presents a documented method for RTL code validation that increases the DER’s confidence level for DO-254 approval.

Importantly, there is no need to alter any of the test vectors as doing so would break traceability with the RTL test bench, as derived from the original requirements. Indeed, DO-254 certification relies on information gathered from the project conception, planning, design creation, implementation and testing stages; and states that the requirements validated during RTL simulation must be validated again during hardware verification.


Verification process assurance:


Design verification is the cornerstone of any our commitment to producing a quality product. Designs continue to grow in functionality at an incredible rate, and verification of these designs can no longer be performed through standard techniques such as directed vector tests. The number of possible states in a given design can well exceed the number of atoms in the universe. This gives rise to the challenges of implementing an effective verification methodology to ensure that the design has been completely verified for every possible state that it might find itself in. Verification also  needs to uncover corner cases such as unintentional “sneak paths” for enabling or disabling critical systems. In short, the company must present a process that proves design verification is complete. The only way to approach this requirement is to employ Advanced Verification Methodology (AVM).


AVM requires the use of existing RTL such as Verilog and VHDL and new languages such as SystemVerilog and SystemC in combination with commercial verification tools. AVM includes utilizing formal verification, constrained random verification techniques, advanced clock-domain crossing detection for meta- stability, assertions, and cover groups to implement a complete verification process. Combining AVM with the ability to track the verification requirements to closure ensures that the verification process of the company is assured.



 Design documentation:


As defined in the DO-254 standard, an artifact is any document, report, or result that is created or produced as part of the FPGA or ASIC design process. Faststream’s design process progressively transforms a written requirement document through the creation of RTL code and ultimately to a programming bit stream or a GDS II file. The quantity of design documentation, or artifacts, produced by this process is typically large. In addition, DO-254 requires the creation of several mandatory documents in sup- port of the standard. Teams constantly review artifacts, and DERs examine the documents and design review results.

FPGA Board Verification for DO-254

The verification of complex FPGA designs is becoming increasingly challenging for safety-critical applications within many sectors – such as aerospace, automotive and medical and for mission-critical applications within the defense sector. Also, verification must be inherent throughout the entire development lifecycle, from requirements spec’ to final hardware.

FPGA implementation at Faststream Technologies is typically verified through RTL simulation, to validate design intent, and code coverage analysis to ensure 100% coverage of all possible input signal combinations across a series of applied tests. However, while simulation results can be easily visualized, analyzed, compared and requirements traceability easily maintained, the design behavior in real hardware cannot be easily traced back to simulation because it is simply not possible to achieve 100% spec’ coverage once the FPGA is physically mounted onto a circuit board.


This presents quite a problem in light of industry standard DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) which requires that safety- and mission-critical designs be verified on the real hardware for certification purposes.


Hardware verification tends to be performed at the board-level; and the FPGA will probably contain most of the board’s primary functions (certainly the time-critical ones). The FPGA will also typically connect with a host of other board-mounted components such as micros, DSPs and memory.


To have full traceability you need to be able to compare the behavior of the physical outputs of the device with their corresponding RTL simulation results. However, you seldom if ever have a means of physically driving the hardware with all combinations of stimuli (as per the ones used for code coverage within your RTL simulation); and even for the inputs you can drive the creation of test vectors is an intensive, time-consuming manual task.


Moreover, there will be multiple testing environments (needed to verify different sets of test cases) the implementation of which will typically require the temporary disconnection or addition of links on the board; activities which are prone to human error.


Accordingly, performing verification (to satisfy DO-254) at the board-level is not only challenging and risky, it is sometimes just not feasible within project timescales; which is why engineers are increasingly adopting a so-called in-hardware verification methodology.

It is based on the use of a bit-accurate, in-hardware verification environment that can verify and trace the same FPGA-level requirements from RTL right through to the target device, at speed. 


The Compliance Software (application) then controls the in-hardware verification process by feeding the Input Vectors to the FPGA pins at full speed using real clocks. Moreover, the process is completed automatically without adding any wrappers to the vector set; which would otherwise adversely affect requirements traceability under DO-254.

The results obtained during in-hardware verification are then sampled at-speed and recorded in a waveform file. The Compliance Software then automatically compares the in-hardware verification results (i.e. Output Vectors) with the Golden Vectors (i.e. RTL simulation results).

Running the target FPGA as described above ensures it performs its intended functions, in isolation, at the required operational speed and on the real target hardware.

Note: this approach has a clear advantage over hardware accelerators, which just run a mapping of the design on test bench clocks and are limited to the simulator’s top speed.

As discussed, FPGA-level in-hardware verification is of paramount importance for safety- and mission-critical applications. Testing the physical target FPGA in isolation, and at-speed, before board-level testing assures the device is bug-free and stable.


Errors that can be detected this way include: any caused by synthesis and place and route tools; Simultaneous Switching Output (SSO) problems, which can lead to signal integrity (crosstalk) issues; differences between simulation models and net lists; clocking and resetting errors; plus general limitations/requirements of the FPGA that are simply not visible during simulation (e.g. clock connected to regular I/O instead of clock pin.)

In addition, re-using the test bench as test vectors for hardware testing provides assurance that the same FPGA-level requirements are verified independently from RTL through to the target device. The same number of tests can be run on the target device as in the RTL simulator. Hence, 100% can be easily assured and automatically implemented.