Top 6 verification misconceptions!!!

1)This is a silicon proven IP no need to do rigorous testing and coverage – Hold on are you sure if all the feature crosses are validated by the IP vendor in the silicon.

2)RTL is the one that is taped out and converted to a product no need to review verification environment, test plan review is sufficient --- 70 % of time is spend on verification out of which considerable amount of time is spend on developing test bench, re-usable and well architected test bench helps you to achieve your verification objectives in less time and in maintenance of your code in longer run.

3)This is a working legacy code keep it --- Legacy code with defect in the architecture is difficult to maintain and doing an enhancement on the code is a nightmare. Consider re-coding sections of the legacy code when you have to do an enhancement in the code to support a new feature.

4)Start the implementation and study the protocol as you go. We want you to be productive from day1 --- A big no!! You cannot architect an environment without understanding the protocol completely and you will always end up with a situation were you were not informed about a requirement.

5)Good verification engineer is the one who hit lot of bugs – Hold on you can have a bad designer who can make many mistakes, making ordinary verification engineer look exceptional.


6)No need to have an architecture document for a verification environment --- Reverse engineering a code to find out the verification environment architecture is not an easy job. It is a pain to understand the architecture of an environment after reverse engineering a code. Always document the architecture of your verification environment if possible document a class diagram.

Checker for complex constraints spanning multiple transaction !!!

It is hard to debug the constraint failures spanning multiple transactions say sequence of ten to fifteen transaction were the constraints on each atomic transaction is dependent on the other. Manual debug on such failures are time consuming.We can use a procedural checker to check the randomization of the scenario which is an array of transaction objects. In RVM/VMM the procedural checker can be placed in the post_scenario_gen callback of the RVM/VMM scenario generator. The post_scenario_gen has drop bit which can be set from the callback to stop the transactions from being pushed in to the channel.The checker is active at all times and flags an error if there is an error in the randomization across transaction.

System verilog 2009 new features !!!

Following are some of the new features of system verilog 2009 standard that caught my attention.

1)`begin_keyword `end_keyword

The above defines can be used between any section of code to maintain backward compatibility with verilog or system verilog 2005, very useful if you are migrating your testbench or design to system verilog, you might come across system verilog keywords used in your verilog design which can cause compile to fail. With system verilog 2009 just wrap the code with `begin_keyword and `end_keyword to get past the error without modifying your code.

2) Let construct substitute to macros ?

Package example_package;
Let expand_operation (a,b) = assert ( !a & b)
end package;

module test ( …);
import example_package::*;

always @ ( …) begin
expand_operation (read,write); // expands to assert(!read & write)
end

end module


3) Pure constraints

virtual class example;
pure constraint valid;
endclass

Allows you to declare pure constraint in the abstract class,just the declaration alone without implementation. The implementation of this constraint is provided in the extended class with the same constraint name.