This is a testbench for testing testbench components. Really. Verification components need to be verified.
You can make properties and assertions all day long and if they don't fire, that might mean the design is perfect. And it might mean that the properties are defective and they are not doing what you expected. You will need to test those assertions.
One option is to break the design for each and every one of the assertions you created. If you've ever done that sort of targeted crippling of a design you know how tedious it can be. It can also be quite difficult to orchestrate particular fails by selective breaking. And how do you coordinate that with particular sequences you run?
The testbench shown here contains a sample DPI-C based method for injecting errors in the design solely for the purpose of testing the verification components. Just make a function call to cripple the design in a particular way.
This is a work in progress. The most recent incarnation is on EDAplayground here:
aNoMoreThanOneGrant
. How do we test it in vivo without changing the RTL? One way is to include the C-function Test_aNoMoreThanOneGrant
and matched task forceTooManyGrants
. At any time in any sequence, call Test_aNoMoreThanOneGrant
and the task forceTooManyGrants
in the module some_corruptor
forces an extra grant to be asserted.
Test_Scoreboard_functionCMP
and matched task forceBadCMP
. This ensures that there is at least one instance where the match signal is incorrect. uvm_set_config_int
. One of the functions includes a C-based file read via the DPI, values from which are brought into a sequence as part of the testbench stimulus. The VirtualDSPtestbench also uses signed values in the testbench as well as in the design. It's brand new and in its early stages, but one can insert a digital filter and apply to that filter +/- values from the signal generator.