Following the Roadmap to Successful Traceability

If DO-254 is both the mission and the map required to achieve compliance, then traceability represents the roads on that map. Consider this.

• • Roads connect two or more places on a map; traceability connects two or more elements in a project (such as functions, requirements, concept, design, verification data and test results). 
  • Road names help identify specific places that are linked to it; traceability names help identify specific project elements that are linked to it.
  • In the absence of roads, reaching your destination is practically impossible;  in the absence of traceability achieving compliance is also practically impossible.

According to DO-254 guidance, traceability is the correlation between the individual system requirements, hardware requirements, conceptual design, detailed design, implementation and verification results. Traceability entails that all system functions are traceable all the way down to the FPGA requirements, verification test cases and test results. This ensures that the development process for the system and FPGA is requirements-based.

While you will find only a brief description of traceability in Section 10.4.1 Traceability Data of the RTCA/DO-254 document, traceability activities are inherently associated to the development lifecycle activities listed in Section 5 Hardware Design Process and Section 6 Validation and Verification Process.  In working through the different stages of the FPGA development life cycle, I’m listing several examples of traceability activities below.

Requirements Capture

• • Link each FPGA requirement to the related Circuit Card Assembly (CCA) requirement it covers. 
  • Generate a downstream traceability report and ensure every CCA function has been allocated to the FPGA and captured as an FPGA requirement. 
  • Generate an upstream traceability report and ensure that each FPGA requirement traces up to the appropriate CCA requirement. Each FPGA requirement that does not trace up to a CCA requirement may be considered as a derived requirement and must go through the validation process. 
  • Baseline or record the trace data between CCA requirements and FPGA requirements.

Conceptual Design

• • Link each conceptual design data to the related FPGA requirement it covers. 
  • Generate a downstream traceability report to ensure that each FPGA requirement is covered by a conceptual design data.  
  • Generate an upstream traceability to expose unnecessary conceptual design data.
  • Baseline or record the trace data between FPGA requirements and conceptual design data.

Detailed Design and Implementation

• • Link the specific lines of the HDL design source (single line or multiple lines of code) to the related FPGA requirement it covers. 
  • Generate a downstream traceability to ensure that each FPGA requirement is fully implemented by an HDL function.  FPGA designers must create additional functions as needed to fully implement each FPGA requirement. 
  • Generate an upstream traceability to expose unused HDL design functions.  Unused functions of the HDL code may lead to unexpected behavior of the device, and must be removed or updated.
  • Ensure that the post-synthesis and post-layout design meet the specified constraints.
  • Baseline or record the trace data between FPGA requirements and HDL design data.

Verification

• • Link each verification test scenario to the related FPGA requirement it covers.  Test scenarios are created based on the FPGA requirements, and they are reviewed for suitability and completeness to cover the related FPGA requirement.  Test scenarios define how each FPGA requirement will be verified, and includes the appropriate input conditions, test sequence and expected results.
  • Generate a downstream traceability to ensure each FPGA requirement is covered by a test scenario.
  • Generate an upstream traceability to expose unnecessary test scenarios. 
  • Baseline or record the trace data between FPGA requirements and test scenarios.
  • Link the specific lines of the testbench (single line or multiple lines of code)  to the related test scenario it covers. 
  • Generate a downstream traceability to ensure that each test scenario is fully implemented by the testbench.  Verification engineers must create the testbench with the appropriate test inputs, sequence and expected results as defined in the test scenarios. 
  • Generate an upstream traceability to expose unused functions or code of the testbench that needs to be removed or updated.
  • Baseline or record the trace data between test scenarios and testbench.
  • Link the specific simulation results to the related test scenario it covers.  Simulation results are a combination of simulation logs, waveforms and coverage data. These results are analyzed and reviewed for correctness. 

Clearly, traceability activities play a large role in FPGA development lifecycle activities. The outputs of all traceability activities are the traceability reports showing the correlation between the project elements.  Traceability reports are reviewed for correctness internally within organizations, and audited by certification authorities.

An example of a traceability report from Aldec’s Spec-TRACER™ is shown below.  The report shows traceability of all project elements from CCA all the way down to the simulation log files and waveforms.  With this type of traceability data, you will be able to show to the certification authority that your design and verification process is requirements-based.

For more details on DO-254 traceability, download the related White Paper: DO-254 Requirements Traceability.

For more information on a Spec-TRACER and a free evaluation, visit www.aldec.com/products/spec-tracer.