Stress-Relief for Requirements-Based Verification

If 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 5^th 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?

How do I manage traceability and create traceability matrices?

What are the differences between the requirements baseline from SOI#2 and the requirements baseline from SOI#3?

What design and verification elements are impacted due to a requirement change?

These questions might sound scary to anyone new to DO-254, however they can be answered simply by understanding the primary processes involved and by having a well-defined set of deliverables. The processes and deliverables for requirements-based verification are: Requirements Capture and Allocation, Requirements Review and Validation, Test Planning and Management, Traceability, Defect Management and Coverage Analysis. For the rest of this article, visit the Aldec Design and Verification Blog.

Tags: aviation, coverage, design, do-254, DO-254 Guidance, FPGA, HDL Design, Impact Analysis, Requirements-Based Verification, safety-critical, Testbench, Traceability, Validation, verification

Category: Requirements Management

This entry was posted on Wednesday, July 16th, 2014 at 9:17 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.