Open side-bar Menu
 Aldec Design and Verification

Posts Tagged ‘HDL Design’

Stress-Relief for Requirements-Based Verification

Wednesday, July 16th, 2014

DO-254-RequirementsIf they’re being honest, anyone who has verified an FPGA under strict DO-254 guidance will tell you that it is stressful. Show me an engineer on their first DO-254 project – and I’ll show you someone pulling out their hair and downing what is probably their 5th cup of coffee while these important questions weigh heavy on their minds:

Have we reviewed all FPGA requirements and validated derived FPGA requirements? Do we have a good record of the review activities?

Do I have a test for each functional FPGA requirement? What’s the status of the tests? How do I track the progress and document the results?

(more…)

See the Future with Impact Analysis

Wednesday, April 9th, 2014

Imagine if you could look into the future…

–   See the impact of requirements changes before they occur.

–   Know with certainty which lines of code in an HDL design or testbench file needed to be re-evaluated based on a change request.

–   Understand how a requirement change impacts the project schedule to help plan and allocate resources effectively.

Impact Analysis Defined

Seeing the future is possible with Impact Analysis, a practice within the change control process of product development. Impact Analysis provides information on what design and verification elements, artifacts, hardware components and materials, personnel, assets or activities that may be affected due to a requirement change. Armed with Impact Analysis data, you can then determine which elements to re-evaluate, modify, and even re-create if necessary.

(more…)

Still managing FPGA requirements with Word and Excel?

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.

 

Following the Roadmap to Successful Traceability

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…)

Demystifying Traceability

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…)

DownStream: Solutions for Post Processing PCB Designs
Verific: SystemVerilog & VHDL Parsers
TrueCircuits: UltraPLL



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