UVM. It’s Organized and Systematic.

One of the reasons I like using UVM is its tendency toward an organized structure and uniformity. Some may find it annoying to adhere to such a strict format in UVM, but I think it’s a good way to keep the basics of UVM engrained in your brain. You always want a good foundation and development of strong fundamentals in any endeavor. Verification is no different and UVM hammers the fundamentals home.

UVM has a great structure and organization paradigm. I consider there to be two distinct and fundamental elements in the UVM structure: Components and Objects. Now this characterization isn’t strictly correct because uvm_components are extended from uvm_objects, but I think they are used in such a way that warrants the distinction. I consider it similar to the idea of trucks and cars. In my view, trucks are also cars, but it’s useful to note the difference.

1. Components

Generally, the components make up the static parts of the UVM structure. I like to think about components as the walls and rooms of a house. They divide the home into different parts with different purposes. Similarly, components divide the verification process into different roles. Doors allow passage from one room to the next just as the ports of components allow for information transfer between components.

Components consist of common methods similar to how many different rooms in a house contain similar features: lights, windows, or outlets. Many of the shared major parts or methods among UVM components are:

• Factory registration and handler instantiations
• Constructors
• Build_phases
• Connect_phases
• Run_phases

Factory Registration and handler instantiations

When you register something with the factory using the `uvm_component_utils() macro, you are entering it into a lookup table where you will be able to access it later. Using this registration functionality makes it possible to override components in the future when developing advanced tests, but that is beyond the scope of what I am discussing here.

Handlers are needed to hold the instantiations of components and are typically created after the factory registration.

Fig. 1: Generic factory registration with handler instantiations for an analysis port, driver, monitor, and sequencer.

Constructors

A staple of object-oriented programming, these are methods to create instantiations of classes.

Build_phases

The build phase is where the walls and rooms of the house are erected. In this phase, the components are being built and the house is taking shape.

Fig. 2: A sample agent build_phase function

For the rest of this article, visit the Aldec Design and Verification Blog.

Tags: debugging, resources, systemverilog, training, uvm, verification

Category: Functional Verification

This entry was posted on Wednesday, February 10th, 2016 at 9:53 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.