Tests

Tests are are the top most layer of verification environment. Tests create the scenarios to verify if the DUT meets the requirement specification. Tests utilize the interface provided by the test bench to achieve the test objective. Common reusable code across tests should be part of the test bench.

In a constrained random test bench most of the checks are handled by the test bench itself. Highly test specific checks are implemented in the tests. Check implementation within the test should be minimized.

Tests use reusable stimulus generation sequences provided by the test bench. They constrain the stimulus generators and hooks provided by the test bench to achieve any synchronization required for the complex scenario generation.

Tests should be written in programmable way. Single feature verification for single configuration is a simple problem. Reality is never simple.  Most tests have to deal with the multiple features and multiple configurations. Tests organization becomes important to optimize the number of tests to cover all of them. We cannot just cover everything under a single constrained random test. Even though its constrained random features have to be spread out across multiple tests with the ability to enable and disable features and program certain specific configurations. This is done in order to manage the complexity.

Tests should be written such that they can be organized as tree. For example in simple communication interface verification, leaf nodes can be transmit only test, receive only test with node above them can be  transmit & receive concurrent test. A single test could meet all three requirements but it should allow controls to do all three. Doing this type of upfront planning will help reduce the total the files created for the tests. Hence the maintenance effort.

Tests either by themselves or through the reusable sequences have to take care of completion of the stimulus generation.

Before starting on the test plan execution it’s important to asses which tests have commonality between them. These tests can be combined into single test with the provision to select the test specific code. This way the code reuse across the tests can be improved.

Once the tests are coded. Real verification execution starts. This is the major activity and most valuable activity of any verification project. All the test bench is built to see this day. Tests will have to be exercised in different configurations. It may be possible that different configurations of DUT are implemented as  different test benches. Care needs to be exercised to execute the tests in all applicable test bench areas. For constrained random tests based on the state space they are targeting the number of seeds with which it needs to be run is decided.

If the design does contain low power support through clock gating and multiple power domains, special low power simulations has to be exercised. Tests which do activate these low power sequences have to be selected for the execution under low power simulation.

If there are multiple instances of the design test has to take care of stimulating all the instances of it.

A test has to consider creating scenario of interest by stimulating combinations of concurrent interfaces, asynchronous events, getting to right state, right mix of the data stimulus generation and control stimulus generations coupled with the right combinations of features applicable. This has to be exercised across various functional configurations, structural configurations, multiple instances and low power simulations. Based on the state space it additionally needs to be seeded.

Bottom line every test has primary focus on specific scenario or feature but it has to be covered in lot of secondary variables which have effect on it. Covering the secondary variables has to be achieved through controlling the test variations by programming it or through adding random seeds of the same test.