Verification methodology provides a framework for easing implementation of coverage driven constrained random verification environments. Verification methodology by itself will not do any functional verification. It’s just an enabler.

Purpose

Verification methodology’s primary purpose is to make the adoption of best-known practices of verification easier. The verification environments built according to the methodology provides the consistency in building verification environments.  Verification methodologies restrict the verification environments architecture to certain standard patterns. This restriction allows consistency and standardization when used right.

Verification methodology also improves the portability. Consistency and portability makes the adoption of the third party vendor solutions easy. Third party BFM usage is one such example.

Principles

Modern verification methodology like UVM are built around principles of transaction based verification environments. Note that “transaction” in current context does not always mean the transactions of the communication protocols.

Transaction is the unit of information packaged together in a class and passed around to the processing elements. Different functional partitions are modeled as processing elements. These processing elements communicate with each other using the transactions.

Transaction based methodology enables modeling transactions, processing elements, transaction communication channels, and synchronization between the processing elements.

Scope

Transaction based framework is foundation of methodology. Flexibility of this framework is improved by using object oriented concepts like inheritance, polymorphism, parameterized classes and static classes. Test simulation time is also managed by methodologies primarily dividing them into pre-test, test-run and post-test phases.  Along with this methodology also provides some of the commonly used utility functionality. Some of the examples of utility functionality are logging, register abstraction layer(RAL) modeling, memory address management(MAM) etc.

Deployment

Good part of methodology is it does not stay just in documents. It comes out and plays role hands on. UVM, the current popular verification methodology is deployed through set of the base classes and utility classes implemented in the SystemVerilog. The framework and functionality common across multiple test benches is packaged in these base classes. UVM is used for building user test bench by extending base classes or by using composition of utility classes. In the extended classes, user test bench specific functionality is implemented.

Case study

UVM is a transaction driven test bench model. Let’s look at how some of the generic concepts introduced above are implemented in UVM.

Sequence items are used for modeling transaction. Components act as processing elements. TLM ports are used as communication channel between the components.

Sequence base class is used for the building the reusable sequences using the sequence items. Sequences are run on the sequencers. Sequencers essentially route the sequence items to right driver. Driver is like BFM, which will drive the sequence item to physical interface.

Through the phasing mechanism the synchronization of the construction and starting up of the components is implemented.

Environment is placeholder for all the components. All the components are instanced and integrated in the environment. It provides the global space such as resource and configuration databases for sharing the information across the components and the external world to environment.

Tests are implemented extending a UVM test base class. Test instances the environment and uses the sequence or sequence items to create the stimulus. Test can obtain handle of any objects, which provide services to test through the config or resource db. These services can also be used for finding out the state of the components for synchronization of the stimulus generation.

Conclusion

To conclude verification methodology is pre-established framework for building verification environments. It’s like empty shell of the apartment where the pillars, floors and mechanism to move across the floors is set up.

Verification engineer will need to understand the requirements of his DUT verification, understand the framework provided by methodology and see how to fit things together. Everything may not fit together, in that one can consider the custom extension the methodology provided functionality as well.

Verification is a mold. HVLs and methodologies are the metal that should be melted to fit into the mold. Without understanding mold you cannot mold anything.