Execution and Closure of the error injection verification

Execution and closure of error injection verification is the last step. Ordering the execution of the verification plan with the following tips can help improve the effectiveness of execution.

If you have reached this step it means, you have followed the “Error injection scenario enumeration thought process”. The scenarios have been prioritized as per the “Definition of the sensible error handling verification plan”. The BFM selected meets the “Error injection capabilities of bus functional models”. The tests have been written following guidelines of “Structuring the error injection tests”.

It’s assumed that normal operation verification has achieved certain level of stability before starting the error injection verification.

Test execution closure

Error injection tests execution should start with the directed tests. Directed tests are simpler to bring up and debug. It’s generally a good idea to go with “width first” approach unless and until there are specific demands. Width first means exercise all the error injection types in directed mode before jumping in to exercising it in the constrained random mode. Width first allows catching many issues and gives enough time for designers to fix the issues. Constrained random will take longer duration of time to exercise and clean it up. Its goes deeper into each of the error injection types.

After the directed tests are clean it’s then advisable to jump into the constrained random tests exercising.  The numbers of seeds have to be decided differently based on the error injection type. Finding bugs can drive the number of seeds selection initially but it can later settle down to minimum seeds to achieve the desired functional coverage.

Functional coverage closure

Basic functional coverage for error injection has to be driven by the error configuration. Error injection types have to cover for both the single and multiple error injections simultaneously. Corruption variations per field and sequence will have to be separately covered.

Cross coverage has to be defined for the following:

• Error types, which are applicable to multiple protocol data unit types. These have to be covered with the right type of cross coverage between the error injection type and protocol data unit type
• Error types, which are applicable to both transmit and receive side. So those have to be covered by crossing the direction with the error type

Be cautious with the cross creations. It’s easy to create the cross but difficult to cover. So keep the cross restricted to relevant error injections.

Error configuration error type coverage can be met by the directed error injection tests. Whereas the variations of the corruptions and cross coverage is best covered using the constrained random tests.

Summary

Ideal order for the error injection test execution is following:

• Independently for transmit and receive side
• Directed tests exercising single error for all the selected error injection types
• Constrained random tests exercising single error for all the selected error injection types independently for transmit and receive side
• Directed tests exercising selected multiple error combinations independently for transmit and receive side
• Constrained random tests exercising selected multiple error combinations independently for transmit and receive side
• Simultaneous error injection on both transmit and receive side  
• Constrained random tests exercising single error for all the selected error injection types independently for transmit and receive side
• Constrained random tests exercising selected multiple error combinations independently for transmit and receive side