UVM dissection – Why it’s needed?
Universal verification methodology(UVM) has become ubiquitous with functional verification but it’s not the complete picture of the functional verification. It’s hard to find any recent verification…
Universal verification methodology(UVM) has become ubiquitous with functional verification but it’s not the complete picture of the functional verification. It’s hard to find any recent verification environment built without using Universal verification methodology(UVM).
Most verification engineers have seen UVM as told by others. I mean through the documentation, tutorials and examples. Very few engineers really take a peek at the UVM source code. UVM source code exploration may not be possible to beginners but it’s required to grow into an advanced user.
Good part of UVM is that it’s source code is readily available. One can argue that I am not a UVM developer, I am just a user and why should I look into the source code?
To answer this question we need to understand the code reuse models. See where UVM code reuse fits in and what are requirements of effective code reuse.
Code reuse paradigm can be divided broadly into three types. There is also mix of these possible.
- Reuse the code as a Product
- Reuse the code as a Service
- Reuse the code as a Framework
Code reuse model as product
Code reuse model as product is using the code as a complete application. Not in bits and pieces. When we use the code as a product we just care about the user interface it offers.
For example, consider a photo viewer application. All we care about is how we can open and navigate the photos. We don’t even care about the programming language in which it’s implemented.
In the reuse model as product, user enters the product and product takes care of user’s requirements. User does not have to worry much about it.
Code reuse model as service
Code reuse model as service is using the services offered by the reusable code in different user applications. Typically the “service provider” code is integrated in the “service user” to create an end application.
In order to integrate service provider, user has to understand the services offered, interface, language of implementation, performance and its compatibility with user development platform. For example, consider simple utility algorithms library. Let’s consider a simple service as sorting numbers. User may have to choose between algorithms offered based on its memory and compute time tradeoffs.
Service provider is entering the end application user is building. So user will have to take care of correct integration. In code reuse model as service, user needs to look deeper into service provider code than the code reused in product reuse model.
Code reuse model as framework
Code reuse model as framework is reusing the code skeleton for building applications of certain types. Framework reuse mainly offers the streamlining of application structure.
Frameworks are customizable. User of framework needs to understand various frameworks available, it’s fit for the problem, language of its implementation, and its compatibility with user development platform.
In framework reuse model, user code enters into the framework. Framework is customized to fit application requirements. Framework reuses are tougher than the first two-reuse models. More than the code reuse framework reuse is about incorporating the best-known practices.
Code reuse model for UVM is…
UVM is a framework reuse model.
UVM offers framework for building clean and maintainable verification environments quickly. UVM by itself does not do any verification but it’s just enabler for building test benches.
In order to use UVM effectively dissection is necessary. Some aids are needed to help with this dissection. Lets look at those aids in next few posts.
Aiding dissection:
- UVM dissection – class statistics – What do I get when I include uvm_pkg?
- UVM dissection – class hierarchy – A complete UVM class hierarchy