Elemental Analysis of Requirements-based Verification

For DO-254 Level A/B FPGA Designs

Louie de Luna, Aldec DO-254 Program Manager
Like(1)  Comments  (0)

Levels A and B airborne hardware are critical to the safety of the aircraft and its passengers.  For both Levels A and B hardware the FAA recommends that designers follow an appropriate design assurance method described in RTCA/DO-254 Appendix B. Elemental Analysis is one of them and it is the most commonly used method of design assurance for FPGAs/PLDs. Mainly because of the fact that there is already a well-known tool that can help – it’s called Code Coverage and it is a standard feature of Active-HDL.

Elemental Analysis measures the effectiveness and completeness of requirements-based verification.  It is a method in which a system is separated into lower level elements and then analyzed at that level.  In the case of FPGAs/PLDs, the definition of an element can be lines of HDL code or outputs of combinatorial logics.  The job of the applicant is to prove that the requirements-based testbench covers the HDL design as defined in the requirement and the verification plan.  Uncovered HDL lines or functions need to be justified or removed from the design to avoid unexpected behavior.

Code Coverage analysis provides several different types of information related to the verification coverage of the design.  Active-HDL offers the following coverage tools:

  • Statement Coverage gives detailed information on statements that are executed during the design simulation. It examines each executable statement and checks how many times it has been executed. This information provides feedback on which parts of the design were verified and which are untested. It also helps to locate dead code.
    • Branch Coverage examines branches of the if or case statement and checks how many times a true or false condition was met by each branch during the simulation. Branch Coverage also collects statistics for VHDL selected and conditional signal assignment statements.
  • Path Coverage is similar to Branch Coverage, however this type of analysis allows checking not only whether a condition was met and in consequence a particular branch of a statement was examined, but it also collects information about consecutive statements which have been executed, branches which have been examined, and how they evaluated (to true or false) during simulation. Sequences of statement executions and condition evaluations form unique combinations of program execution referred to as paths. A path is the subject to analyze by Path Coverage.
  • Expression Coverage and Condition Coverage factorize all or conditional logical expressions used in statements and monitor them during simulation.
  • Toggle Coverage measures design activity in terms of changes in signal logic values.
  • Functional Coverage shows statistics for OVA, PSL, and SystemVerilog assertions and cover statements. It shows how many assertions started to evaluate during simulation, how many failed, and how many succeeded. For the cover statements, the statistics show the number of "matches".

X-trace, what is elemental analysis, how to do elemental analysisIt is significant that the Code Coverage tool goes through Tool Assessment and Qualification Process to ensure that it provides accurate coverage counts and results. Aldec has done its due dilligence to prove that Active-HDL Code Coverage provides accurate coverage counts as expected, and provides a package of VHDL test cases and extensive documentation (Tool Operational Requirements, Tool Test Plan, Tool Qualification Accomplishment Summary and Test Analysis Documentation) proving that Code Coverage: Branch and Statement Coverage show accurate coverage counts as expected.

To learn more about Active-HDL Code Coverage Tool Qualification, download www.aldec.com/en/support/resources/documentation/?type=2&submit=Browse&category=&products=6.

Louie de Luna 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 Acceleration, Emulation, Co-Verification and Prototyping, and he has held a wide range of engineering positions that include FPGA Design Engineer, Applications Engineer, Product Manager and Project Manager.

  • Products:
  • DO-254/CTS
  • FPGAテスト・システム


Ask Us a Question
Ask Us a Question
Captcha ImageReload Captcha
Incorrect data entered.
Thank you! Your question has been submitted. Please allow 1-3 business days for someone to respond to your question.
Internal error occurred. Your question was not submitted. Please contact us using Feedback form.
We use cookies to ensure we give you the best user experience and to provide you with content we believe will be of relevance to you. If you continue to use our site, you consent to our use of cookies. A detailed overview on the use of cookies and other website information is located in our Privacy Policy.