Verification environments can be wrong. The testbench itself must be qualified as being up to the task before it can be used to verify anything else. This section describes the scope and limits of this testbench, and what faults are required to be injected by the DUT in order to qualify the testbench itself; yes, the DUT will be crippled on purpose. This is verification, so even the obvious needs to be stated clearly. Below is a checklist general outline. The testbench must:
Behave nicely
[ ] The testbench must not cause a hang (see "Known issues" below),
[ ] The testbench must detect a hang in the DUT and exit gracefully,
[ ] The testbench must report all values correctly,
[ ] The testbench must make all reports as VID's,
[ ] The testbench must build an easy to read summary.
Collect coverage
[ ] The testbench must collect coverage of
[ ] functionality, i.e., all VIDs,
[ ] RTL code. Code coverage will be on in all simulations, directed and random.
Perform directed tests
[ ] The testbench must have a complete suite of correct functional use cases
[ ] of external interface protocols,
[ ] using data records.
[ ] The testbench must have a suite of incorrect use functional cases
[ ] of external interface protocol misuse,
[ ] using data records incorrectly.
Perform constrained random tests
[ ] The testbench must have the capability of generating constrained random tests