Posts Tagged ‘test results’
Wednesday, December 10th, 2014
 In response to user feedback, Aldec has developed a direct integration between IBM® Rational ® DOORS ® and our requirements management tool, Spec-TRACER™, to enable users to extend the traceability data in DOORS to FPGA design and verification elements.
Aldec has a strong 30-year+ history of asking and listening to the engineering community and we’re proud to say, thanks to your requests, that Spec-TRACER 2014.12 featuring direct integration with DOORS… is now available to test drive.
Below you’ll find an overview of the Spec-TRACER/DOORS tool flow. DOORS remains the main source and environment for managing board requirements and other higher level requirements, while Spec-TRACER remains the main source and environment for managing FPGA requirements, conceptual design data, detailed design data, test cases, test procedures, test results, traceability data and review activities. Spec-TRACER also remains the main source for generating all the pertinent reports for the FPGA project such as requirements documents, verification procedures, test results, impact analysis reports and project status reports.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: Aldec, conceptual design data, detailed design data, environment for managing fpga requirements, FPGA Design, fpga project, ibm rational doors, impact analysis reports, managing board requirements, managing higher level requirements, project status reports, requirements documents, review activities, spec-tracer, test cases, test procedures, test results, traceability data, verification elements, verification procedures
No Comments »
Monday, September 23rd, 2013
 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.
(more…)
Tags: Aldec, cca, circuit card assembly, conceptual design, detailed design, do-254, FPGA, fpga requirements, hardware design process, hardware requirements, HDL Design, implementation, individual system requirements, requirements capture, spec-tracer, test results, Traceability, verification results, verification test cases
No Comments »
Monday, June 17th, 2013
 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.
(more…)
Tags: device development life cycle, downstream traceability, FPGA, HDL Design, hdl functions, Impact Analysis, post-layout design, spec-tracer, suspect links, test results, Testbench, Traceability, upstream traceability, verification test cases
No Comments »
|
In response to user feedback, Aldec has developed a direct integration between IBM® Rational ® DOORS ® and our requirements management tool, Spec-TRACER™, to enable users to extend the traceability data in DOORS to FPGA design and verification elements.
