Abstract

This paper is the second in a series describing an incremental methodology for adopting coverage driven verification using constrained random stimulus into digital development projects including FPGAs and ASICs. In the first paper we discussed moving checkers from directed testcases to an object oriented environment simulating along with the device under test (DUT)so that each checker could be leveraged across an entire test suite rather than remaining siloed in the single testcase it was originally created for. In this paper we introduce functional coverage, a technique that takes a look backward at our first paper, and a look forward to the next paper in the series regarding constrained random stimulus. Looking back, object oriented checkers leverage common checking code across more testcases, but leave auditors with a looming question, “How do we know the checkers were exercised?” As a project moves away from directed testcases, auditors and other stakeholders can feel that they are losing a stalwart of the DO-2S4 requirements tracing methodology: the easily auditable, and easily traceable-to-requirements directed testcase list. With checkers essentially floating in the simulation environment, unmoored from testcases, how can verification stakeholders be sure the device requirements were both exercised and checked? Looking forward to the next part in our series-constrained random stimulus-a similar question emerges, “How can stakeholders be certain that device features corresponding to DO-2S4 requirements were exercised by a randomized stimulus stream?” The answer to both these questions presented here is the same, functional coverage records-indicating when the stimulus specific to a given design feature has been detected-are recorded with every passing testcase. This paper describes how functional coverage is used as part of an auditable system-also including testcase pass/fail results, design anomaly reports, and the more familiar to DO-254 concept of code coverage-that can be traced back to DO-254 design requirements, enabling the gains provided by coverage driven verification while maintaining the security and easy-traceability/auditability of perhaps more familiar verification environments using suites of directed testcases.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call