Posts Tagged ‘spec-tracer’
Tuesday, August 25th, 2015
 You have been developing FPGAs for a long time, and you know your designs from top to bottom. You know every interface protocol, configuration and optimization. You can visualize your timing diagram like you can visualize your upcoming vacation in Hawaii. You can manually write down your memory mapping accurately while under oath. You can pinpoint all CDC paths and emulate metastability in your mind. You are confident that your designs are fault-tolerant and will function as intended. You are the master of your domain.
But… can you bet your life on it?
Are you willing to bet your life on your designs? What about the lives of the thousands of passengers sitting on the airplanes where your FPGA design is installed? How certain are you that it won’t fail in the field? If it were to fail, can it resume normal operation safely and timely? Not just MOST of the time, but EVERY time?
(more…)
Tags: Aldec, do-254, DO-254 Compliance, do-254/cts, FPGA Design, FPGAs, Requirements Management, safety-critical, spec-tracer, Traceability
No Comments »
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 »
Tuesday, January 21st, 2014
 Smart engineers work smart by using tools that are readily available and that they know how to use. Wise engineers work wisely by first evaluating the options, analyzing the results and making a strategic decision not only for the current project but, more importantly, for upcoming projects as well.
Recently, a customer developing avionics systems came to us with their frustrations in managing FPGA requirements. They managed higher level requirements, such as line replaceable unit (LRU) and circuit card assembly (CCA) requirements, in IBM DOORS. The FPGA requirements, test cases and their traceability to HDL design, testbench and simulation results were managed using Word and Excel. Since DOORS lacked the capability to trace to FPGA design and verification elements necessary for DO-254 compliance, the customer felt they had to choose Word and Excel.
Why? Because Word and Excel are readily available and the team members already know how to use them. But as their projects grew in complexity increasing the number of requirements to be managed, they found that Word and Excel have many shortcomings and realized that they are not the right tool when it comes to requirements management and traceability.
For the rest of this article, visit the Aldec Design and Verification Blog.
Tags: Aldec, cca, circuit card assembly requirements, do-254, DO-254 Compliance, FPGA, FPGA Design, HDL Design, higher level requirements, ibm doors, line replaceable unit, lru, managing fpga requirements, spec-tracer, Traceability, traceability with excel, verification elements
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 »
Tuesday, June 11th, 2013
Functional Verification Insights from Austin
I just returned back to the office from the 50th Design Automation Conference (DAC) which took place in Austin, TX, on June 2—6. As I began compiling my trip report, I thought that I might share some of my observations, especially for those who couldn’t attend this industry event but still wanted to gain some insight.
Conference itself
One of the reasons I like DAC is that it has always been the main industry event, attracting people from all over the world, and provides participants with the opportunity to meet most of their key customers, ecosystem partners, and competitors in a single location. From an exhibitor’s perspective, DAC is mainly about engaging with attendees on the floor, learning about their current and anticipated challenges, and educating them on how they can innovate and succeed using our product offerings.
(more…)
Tags: cdc, dac, design automation conference, driver software verification, ecosystem partners, fpga-based prototyping, Functional Verification, high level synthesis, hls, hw/sw co-verification, mixed-signal simulation, multimillion gate soc, multiple clock domains, Riviera-PRO, SoC, SoC and ASIC Prototyping, SoC Verification, spec-tracer, system development, system verilog, systemverilog-based uvm, uvm-compliant environments, verification, verification ips, vips
No Comments »
|
You have been developing FPGAs for a long time, and you know your designs from top to bottom. You know every interface protocol, configuration and optimization. You can visualize your timing diagram like you can visualize your upcoming vacation in Hawaii. You can manually write down your memory mapping accurately while under oath. You can pinpoint all CDC paths and emulate metastability in your mind. You are confident that your designs are fault-tolerant and will function as intended. You are the master of your domain.
