Category: UVM

UVM is primarily based on a framework reuse model.

Effective use of Universal verification methodology (UVM) requires understanding of effective framework reuse requirements.

Effective framework reuse requires user to do bit of deep diving. Effective framework reuse cannot be achieved by just reading the documentation of it or playing around with the examples. They are necessary but not sufficient. Framework reuse model to be effective, certain level of familiarity with the framework source code is required.

The user needs to understand the verification problem to be solved clearly. Framework is one of the possible solutions. Solution offered by framework is not complete on its own. It is a partial solution. It’s a guiding skeleton, user needs to customize and populate it with the application specific code to make it a complete solution.
(more…)

UVM code reuse is predominantly a framework reuse model. It’s effective application requires certain level of source code exposure as discussed in the “UVM dissection – Why it’s needed?“

In order to dissect the UVM source code certain aids were thought to be useful. First one was the number of files and classes present in UVM. It was discussed in the UVM deep dive – statistics.

There are 311 System Verilog classes in UVM 1.2 implementation. Not all of them are user-exposed classes. Now to make any sense of these many classes a complete class hierarchy would be useful. This would serve as navigation map for browsing the code.

UVM class reference does provide the individual class hierarchy but all the class hierarchy in a single picture is missing. This is important to understand the bigger picture.

Although there have been some pictures of class hierarchy beyond single class as part of UVM presentations but most of them are focused on certain classes under discussion. For instance one of the popular class, which has more complete hierarchy available is uvm_object. Have you wondered why is the uvm_object a popular one? Because its second highest fertile class with 39 children and its parent to some important classes.

What is benefit of bigger picture? Just see one for yourself. UVM phasing is one of tricky concepts. Which phases are bottom up? Which phases are top down? What are the total phases? Following picture shows that. The string in the parenthesis is the directory in which the class is located in the source code.

Mind map is a great tool for viewing and analyzing the hierarchical information. A UVM class hierarchy mind map showing all UVM class relations in single snapshot is shown below. On the left side of this mind map are UVM classes that are not derived from any other classes. Right side of the mind map is classes that are derived from different base classes. Following one is snapshot of mind map(save the image and zoom in). Interactive mind map can be accessed online here. It has limited capabilities supported by vendor mindmup.

Best mind map browsing experience is with the mind map tool on your machine with all capabilities. Searching and filtering can make it easy to find the information you are looking for. Freemind is one of the freeware for browsing mind maps. Email me , I can send you the Freemind mind map(uvm_head_on.mm) file.

Please comment or email if you think any other way of viewing UVM class information can aid your dissection better.

Happy deep dive, see you on other side !

UVM code reuse is predominantly a framework reuse model. It’s effective application requires certain level of source code exposure as discussed in the  “UVM dissection – Why it’s needed?“

First level of dissection is some vanity statistics. Statistics provides the idea about the scale. When the magic “uvm_pkg” is imported in verification environment, what do I get? Has this question ever crossed your mind? One can say why do I care? It’s tradition, we just include and move on with the business of verification.

The reason we need to care is there is price to be paid. UVM source code may be free. But simulator licenses are not free. Compute farms where the simulations are being run are not free. I can enumerate many others that are not free but let’s just stop here. Point is UVM also needs to be compiled and simulated too. That costs simulator licenses and computer farms.

UVM uses the DPI written in C/C++. I am not including the DPI details here at the moment. Lets focus from the System Verilog part of it. When you include the magic uvm_pkg, as of UVM 1.2 implementation you are getting 121 files and 311 classes. Your verification environment may have 10 files and 20 classes but just by including the uvm_pkg your class count would be shot up by 311. Note that UVM needs compilation. See your compile log file. When the simulation is started these classes will have to be loaded. Look at the class hierarchy shown in the interactive debuggers.

Don’t worry about it. With the growth in the compute power, Focus has been on the human effort minimization and not the computer resource optimization as a first priority. But the point is, since you are paying price by including uvm_pkg make it count by extracting the best productivity boost out of it.

Next level of dissection is all UVM dissection – class hierarchy.

 

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