For DO-254 Compliance, Hardware Flies Not Simulations

How to Increase Verification Coverage by Test

DO-254 defines 3 types of verification methods: Analysis, Test and Review. In order to satisfy the verification objectives defined in DO-254, applicants must formulate a requirements-based verification plan that employs a combination of the three methods.

Analysis vs. Test

A computerized simulation of the hardware item is considered an Analysis. Test is a method that confirms the actual hardware item correctly responds to a series of stimuli. Any inability to verify specific requirements by Test on the device itself must be justified and alternative means of verification must be provided. In DO-254, the hardware test is far more important than the simulation. Certification authorities favor verification by test for official verification credits because of the simple fact that hardware flies, not simulation models. Requirements describing pin-level behavior of the device must be verified by hardware test.

Defining the Problem

Testing the FPGA device at the board level provides very low FPGA input control making it difficult to inject certain signals for normal range and robustness tests. Frequently as a result, applicants are left with the option to verify the requirements only by simulation. But simulation is insufficient and in many cases unable to expose errors that may impact safety and reliability of the device under test. Verification of requirements by hardware test during final board testing is challenging and not feasible in most cases.

How to Increase Verification Coverage by Test

The list of recommendations proposes a methodology that can leverage the same test cases and test inputs for simulation and device testing allowing for a much stronger argument of verification fidelity and validity to the certification authority.

(1) Capture

Requirements

Write the requirements such that they are verifiable at the FPGA pin level.

This ensures that the inputs are controllable and the outputs are observable so that each requirement can be verified by test at the FPGA pin level.

(2) Develop Test Cases

Create test cases based on the requirements, not based on the design.

Test cases describe how to verify the requirements. They define the initial setup conditions, the input conditions and the expected results for outputs and the pass/fail criteria. In addition to normal range tests, robustness tests for abnormal inputs should also be added.

(3) Develop Testbench

Create the HDL testbench to implement the test cases for simulation.

The inputs from the test case are applied to the HDL design and outputs are collected via waveforms. Self-checking testbenches can also be employed to automate checking for PASS/FAIL results. Ensure that any tool qualification issues are addressed for automated verification tools.

(4) Functional Simulation Code Coverage

The testbench can be used for functional simulation and code coverage analysis.

The same test vectors are used for functional simulation, functional simulation with coverage metrics, post-layout timing simulation and for device testing.

(5) Timing Simulation

Use the test vectors for MIN/TYP/MAX post-layout timing simulation of the design.

(6) Device Testing with DO-254/CTS

Test the target device in isolation, at-speed, with the test vectors as test inputs.

Ensure that the hardware testing setup provides 100% input controllability and output observability, so that the same test cases used for simulation are used for hardware test. Collect the results via waveforms and compare them against the functional simulation waveforms.

(7) Final Board Testing

After testing the target device in isolation, proceed to final board testing.

Use flight configuration of the board to verify board level functions, components interfaces and environmental requirements.

DO-254/CTS™ can help facilitate the recommendations provided and significantly increase verification coverage by hardware test. DO-254/CTS can leverage the same test cases and testbench from simulation during device testing. Test vectors can be generated during functional simulation and reused as test vectors for device testing. DO-254/CTS provides 100% FPGA input control and outputs access points so that requirements are easily verifiable by test for normal range and robustness tests. DO-254/CTS consists of custom hardware specific to the target device and design utilizing real clocks to enable at-speed testing.

Louie is responsible for FPGA level in-target testing technology and requirements lifecycle management for DO-254 and other safety-critical industry standards. He received his B.S. in Computer Engineering from University of Nevada in 2001. His practical engineering experience includes areas in Acceleration, Emulation, Co-Verification and Prototyping, and he has held a wide range of engineering positions that include FPGA Design Engineer, Applications Engineer, Product Manager and Project Manager.