Open side-bar Menu
 Aldec Design and Verification
Louie De Luna
Louie De Luna
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 … More »

Demystifying Traceability

June 17th, 2013 by Louie De Luna

For DO-254 Compliant FPGAs and ASICs

I have been getting a lot of questions from our customers about traceability in the context of DO-254 and airborne FPGAs and ASICs.  It seems that there are several new concepts and terminologies associated to traceability that are new to most of us.  So I thought I would shed some light in this blog and explain the basic 5 terminologies. Also I have always liked the word “demystify”, but never had the chance to use it – so here is my chance.

Traceability – Traceability is the activity that maps all of the design and verification elements back to requirements to ensure that what is being built and tested is based on the requirements. Traceability is the correlation between system requirements, FPGA requirements, conceptual design, HDL design, post-layout design, verification test cases, testbench and test results.

Downstream Traceability – A top to bottom reporting activity that shows the mapping or correlation between system requirements, FPGA requirements, HDL design, test case, testbench and test results.  Running a downstream traceability can expose FPGA requirements that are not implemented by any HDL function or not covered by a test case.

Upstream Traceability – A bottom to top reporting activity that shows the mapping or correlation between test results, testbench, test case, HDL design, FPGA requirements and system requirements.  Running an upstream traceability can expose derived FPGA requirements or unused HDL functions.  Tools like Spec-TRACER can also use upstream traceability to expose all of the design and verification elements associated to a FAILED simulation result.

Impact Analysis – Impact analysis exposes all of the design and verification elements that will be impacted prior to a requirement change. Requirements frequently change during the device development life cycle, and impact analysis is key in determining the magnitude and impact of the requirement change before it occurs.  This enables organizations to properly allocate resources and budget before changing a requirement.

Suspect Links – After a requirement has been changed, it is critical to have a mechanism to mark all of the impacted design and verification elements for further evaluation.  This mechanism can be achieved via suspect links.  All of the impacted elements are marked as suspect links so that that impacted elements are properly identified for further evaluation or correction.

For more information, we invite you to view the Recorded Webinar, DO-254 Requirements Traceability.

Related posts:

Tags: , , , , , , , , , , , , ,

Categories: DO-254 Compliance, Requirements Management

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy