Design Article
DO-254: Increasing verification coverage by test
Louie De Luna, Aldec, and Randall Fulton, FAA
1/9/2013 8:47 AM EST
Robustness testing
The purpose of robustness testing is to demonstrate that the device functions as intended not only under normal operating conditions but also under abnormal operating conditions [8].
Requirements-based tests usually cover test cases for normal conditions, but do not cover test cases for abnormal conditions. That is why applicants are expected to add robustness test cases to the verification plans to ensure the device functions as intended under all foreseeable conditions.
Examples of industry best-practice robustness tests include the following:
• Invalid, interrupted and unexpected inputs
• Invalid input timing (e.g., input that violates setup and hold time)
• Out of range input address bus
• Varying clock frequency and duty cycle within or outside clock tolerance
• Varying input voltage
Note that while test cases for robustness testing may be easy to implement in simulation, they can be quite difficult to implement during device testing.
Traditional device testing
Traditionally, device testing is performed at the Circuit Board Assembly (CBA) level. In some cases, the CBA contains the FPGA device as its primary component with the most complex functions and controls, and possibly even the main Intellectual Property (IP) of the board. The FPGA is also interconnected with other Custom-Off-The-Shelf (COTS) components on the board, whereas visibility and controllability at the FPGA pin level is limited. There are times that the board even contains multiple FPGAs, and verification at the board level without first stabilizing each FPGA individually can lead to many problems and longer project delays.
A simplified example of a CBA is shown in the figure below. The FPGA inputs are connected to a COTS microprocessor, and the FPGA outputs are connected to COTS Digital-To-Analog (D/A) and DDR3 RAM chips. For COTS devices such as microprocessor, D/A and DDR3 RAM, DO-254 is not intended to be applied, and instead alternative processes and methods must be coordinated with the certification authority. For the FPGA device, the DO-254 processes need to be applied at the device level in order to meet the functional and safety requirements of the device. The planning documents, standards, requirements, validation and verification, configuration management and all other life-cycle pertinent data are generated and specific to the FPGA device.
Figure 2: Device testing at the circuit board assembly (CBA)
The purpose of robustness testing is to demonstrate that the device functions as intended not only under normal operating conditions but also under abnormal operating conditions [8].
Requirements-based tests usually cover test cases for normal conditions, but do not cover test cases for abnormal conditions. That is why applicants are expected to add robustness test cases to the verification plans to ensure the device functions as intended under all foreseeable conditions.
Examples of industry best-practice robustness tests include the following:
• Invalid, interrupted and unexpected inputs
• Invalid input timing (e.g., input that violates setup and hold time)
• Out of range input address bus
• Varying clock frequency and duty cycle within or outside clock tolerance
• Varying input voltage
Note that while test cases for robustness testing may be easy to implement in simulation, they can be quite difficult to implement during device testing.
Traditional device testing
Traditionally, device testing is performed at the Circuit Board Assembly (CBA) level. In some cases, the CBA contains the FPGA device as its primary component with the most complex functions and controls, and possibly even the main Intellectual Property (IP) of the board. The FPGA is also interconnected with other Custom-Off-The-Shelf (COTS) components on the board, whereas visibility and controllability at the FPGA pin level is limited. There are times that the board even contains multiple FPGAs, and verification at the board level without first stabilizing each FPGA individually can lead to many problems and longer project delays.
A simplified example of a CBA is shown in the figure below. The FPGA inputs are connected to a COTS microprocessor, and the FPGA outputs are connected to COTS Digital-To-Analog (D/A) and DDR3 RAM chips. For COTS devices such as microprocessor, D/A and DDR3 RAM, DO-254 is not intended to be applied, and instead alternative processes and methods must be coordinated with the certification authority. For the FPGA device, the DO-254 processes need to be applied at the device level in order to meet the functional and safety requirements of the device. The planning documents, standards, requirements, validation and verification, configuration management and all other life-cycle pertinent data are generated and specific to the FPGA device.
Figure 2: Device testing at the circuit board assembly (CBA)
Testing the FPGA device at the board level is quite challenging and present several significant challenges. One of the main challenges is the inability to verify specific requirements by test because testing the FPGA device at the board level provides very low FPGA input control and output access points. This makes it difficult to inject certain signals for normal ranges tests and robustness tests, and as well as verify/capture the results at the pin level.
Common industry challenges in testing the FPGA device at the board level also include the following [9]:
• Limited or no visibility and controllability on the FPGA I/Os
• Development of new test cases and input data for device testing
• Multiple setups of testing environment for different test cases
• Robustness testing at device level is not feasible in most cases
• Documentation of results
Common industry challenges in testing the FPGA device at the board level also include the following [9]:
• Limited or no visibility and controllability on the FPGA I/Os
• Development of new test cases and input data for device testing
• Multiple setups of testing environment for different test cases
• Robustness testing at device level is not feasible in most cases
• Documentation of results
|
|
|
|
|
Navigate to related information