Object Oriented Checkers as a First Step Towards Coverage Driven Verification in DO-254 Design Assurance

ASIC devices deployed in avionics systems continue to grow in complexity presenting verification challenges that must be addressed to ensure safe deployment. DO-254 recommends a requirements driven verification approach for these ASIC devices under test (DUTs). One of the simplest., and most obvious implementations of this recommendation is the construction of directed testcase libraries with each testcase corresponding to a specific ASIC design requirement. The one to one correspondence between testcases and design requirements makes the testcases easy to track in requirements based projects. However, this intentional one to one mapping between testcases and requirements buries much of the inherent value of the testcase library. While multiple requirements are usually exercised in each testcase, only one is intentionally checked. Bugs in the exercised secondary design requirements will not be detected if they do not impact operation of the primary requirement addressed by the test case. The one to one correspondence between testcases and requirements may also hide bugs that are caused by (perhaps unintended) interactions between two or more design requirements. Constrained random coverage driven verification, (CRCDV), a widely adopted verification methodology, addresses these and other shortcomings of directed testing by exercising and checking multiple design features in parallel. CRCDV consists of three steps: 1. Randomizing stimulus, including internal configuration parameters as well as external inputs, to the DUT; 2. constructing checkers-decoupled from the stimulus generation in step 1-used to detect errors in the DUT's functionality by observing only the inputs and outputs of the DUT; and 3. Cataloging, through functional coverage, the randomly generated stimulus, (again decoupled from the stimulus generation of step 1)., applied to the DUT to ensure that it covers a sufficient portion of the DUT's stimulus space. While CRCDV is a powerful and valuable methodology, making the move to this approach all at once can be a daunting and expensive prospect. What might not be immediately apparent is that there is unexploited randomness built into even pure directed testing verification environments. This randomness is inherent because various secondary device features are utilized in testing the primary feature of a test case. This randomness, however, typically remains hidden-its value not leveraged-because while the secondary features are exercised in ways that were perhaps not emphasized in the test cases where the secondary feature was the primary focus., in typical directed test suites., there are no checks for the correct operation of these secondary features. This paper outlines a small, but very valuable first step in the move to CRCDV: transferring existing directed testing checks into an object oriented, (OO), memory cloud where they can be independently utilized by all existing testcases. Because the methodology described requires no changes to existing testcases it enables changing to a more powerful verification technique without sacrificing existing verification intellectual property. At the same time, the hidden value inherent in testing multi-requirement interactions is realized. The methodology presented can be briefly summarized as follows. Standalone SystemVerilog objects encapsulating protocol monitors are implemented, and interfaced to the each of the DUT buses. These monitors create both read and write transaction objects describing traffic on these buses. The transaction objects are broadcast by analysis ports that can be subscribed to by any other object supporting the same port interface. All testcase checks corresponding to a single feature are collected into a single class corresponding to that feature; these classes will be instantiated as the OO checkers. In the most simplistic implementation these checkers filter bus transactions looking for the exact conditions created in their associated directed testcases. When these conditions are detected, the check is performed. More generic implementations can be constructed to check the feature under all conditions. Finally, the testbench environment is modified so that checker objects defined by these classes are instantiated, attached to the appropriate bus monitors via their associated analysis ports, and execute their checks. Because the modifications are performed in the testbench environment that serves as a framework for the entire testcase library, these object-oriented checks function transparently during every simulation with no modifications required to the existing testcase code. Tracking OO verification checks as primary artifacts derived from design requirements instead of verification testcases will also be discussed as a topic for further study.