If you’re designing with FPGAs under DO-254 guidance, these guidelines are a must.

Requirements Traceability is a well-proven software development practice that’s improved software project management, enabling software teams to deliver high-quality applications on time and within budget. However, while already widely accepted and adopted by software engineers, Requirements Traceability is still a relatively new concept in the FPGA domain.

Commercial aviation FPGA teams have started to adopt Requirements Traceability out of necessity to achieve DO-254 Compliance. FPGA teams working on DO-254 programs must provide proof that the final FPGA device has been designed and tested based on the requirements, and Requirements Traceability is a crucial part of the proof.

In regards to FPGA development, Requirements Traceability is the correlation between the circuit card requirements, FPGA requirements, conceptual design, HDL source code, synthesis and P&R files, verification test cases, test-bench code, simulation scripts, and simulation results (log files, waveforms, and code coverage reports).

While not explicitly defined within DO-254, Requirements Traceability offers significant benefits when done correctly. Establishing traceability improves change management, promotes better project management, and provides an efficient way to organize, connect, and track all of the FPGA design and verification elements.

Here are the top five reasons why you need Requirements Traceability for FPGA development under DO-254 guidance.

1. To expose requirement coverage gaps

During the FPGA requirements capture process, running a downstream traceability from circuit card assembly (CCA) to FPGA requirements exposes CCA requirements that aren’t covered by FPGA requirements. The example shown in Figure 1 shows that neither CCA-002 and CCA-007 are covered by any FPGA requirement. This is a result of either: the related FPGA requirements aren’t correctly linked to CCA-002 and CCA-007 requirements, or the CCA-002 and CCA-007 requirements aren’t properly allocated to the FPGA. Either way, proper measures must be taken to correct this coverage gap.

 

 

Likewise, during the rest of the FPGA design life cycle, running downstream traceability exposes FPGA requirements that haven’t been implemented by an HDL function, FPGA requirements that haven’t been covered by a test scenario, and test scenarios that haven’t been implemented by a test-bench. Knowing whether there are coverage gaps or not helps keep track of the project status. Downstream traceability easily exposes requirements coverage gaps during the FPGA development cycle.

2. To expose unused HDL functions

Reusing HDL design sources across multiple projects offers several advantages, but one common disadvantage is the occurrence of unused HDL functions. Running an upstream traceability from the HDL design to the FPGA requirements easily exposes HDL functions that don’t trace up to any FPGA requirement. This results from either: the HDL functions aren’t properly linked to the related FPGA requirements, or the HDL functions aren’t being used at all. Unused functions of the HDL code may lead to unexpected device behavior, and they must be removed or updated.

3. To enable change impact analysis

Changes in the requirements may lead to changes to other project elements such as HDL design, synthesis and place and route files, test cases, test-bench, and test results. Before the change occurs, organizations perform a change impact analysis to evaluate the ripple effect of the change to the rest of the project.

Traceability is an effective way to expose the project elements that are impacted due to a requirement change. An example of impact analysis is shown in Figure 2. A change to the requirement description of CCA-041 impacts 3 FPGA requirements namely:

• FPGA-011
• FPGA-021
• FPGA-022

 

 

These FPGA requirements must be evaluated whether or not they still fully cover CCA-041 (taking the CCA requirement change into consideration). If further modification is needed for any of the impacted FPGA requirement, then the design and verification elements linked to it also need to be evaluated. As shown in Figure 3, a change to FPGA-011 impacts the following design and verification elements, and all of them must also be evaluated and modified if needed.

• HDL_002_interrupt_unit.vhd • HDL_003_interrupt_unit.vhd • HDL_006_interrupt_contr.vhd • TST-003     • TB_003_testbench.vhd

–tag to HDL source code –tag to HDL source code –tag to HDL source code –tag to test case –tag to testbench

 

(Click graphic to zoom)

 

Without an established traceability from CCA down to the FPGA design and verification elements, impact analysis would be difficult to manage and analyze. Since traceability between project elements exists, impact analysis is easily achievable.

4. To improve tests management

A mechanism to measure whether test case results have passed or failed is a key element in determining the verification’s completeness. Establishing traceability between test cases, test-bench, test status, log files and waveforms enables more efficient test management. In addition, with the help of traceability, determining and tracking which test suite achieved the maximum code coverage is also possible. The key is having some type of tool automation such that after each regression, the matrix is automatically populated with the appropriate test results.

5. To help with reviews and audits

During reviews and audits, the requirements traceability matrix can be used as a map to determine the correlation of all FPGA design and verification elements. A requirements traceability matrix can answer the following questions:

• Do we have HDL design source code for each FPGA requirement?
• Do we have a test case and a test-bench for each FPGA requirement?
• Have we verified all FPGA requirements? How many FAILED tests do we have?
• What is the cumulative code coverage for a specific test suite?
• Where and what are the log files and waveforms generated during individual tests and regressions?
• What design and verification elements will be impacted if a specific FPGA requirement needs modification?

With the help of the traceability matrices, both the applicant and certification authority are able to easily reference and correlate all design and verification artifacts back to the requirements.

 

(Click graphic to zoom)

 

Clearly the reasons for requirements traceability are compelling. But remember, traceability can be hard to create and manage without the proper tools. Traceability is an ongoing activity that must be managed and maintained throughout the project’s duration. Small projects with less than 100 requirements may be simple and spreadsheets may be sufficient for managing traceability. But managing traceability using spreadsheets for large projects with hundreds or thousands of requirements can be overwhelming. This provides yet another reason to consider Spec-Tracer to improve change management, promote better project management, and provide an efficient way to organize, connect, and track the FPGA development cycle.

If you’d like to learn more about traceability and best practices for design assurance level A FPGAs, check out this webinar: Best Practices for DO-254 Requirements Traceability. I present with Robert Atkinson of Richland Technologies. We cover topics such as the recommended approach when tracing from FPGA requirements to HDL design sources, and what certification authorities look for when they review the traceability data. More information on DO-254 traceability can be found in the white paper “DO-254 Requirements Traceability.”

Louie De Luna is a DO-254 Program Manager at Aldec. He 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 various engineering positions.