Category Archives: uvm

UVM-OVM: Yet another compare issue…

Hi guys, recently we discovered one more bug in UVM and OVM build in compare methods. Previously, I discussed about UVM-OVM: Compare method bugs which was about associative array, this post is related to different object types.

Recently the committee has reported/resolved one more bug in UVM/OVM built-in compare method. Note that the following applies to all the UVM and OVM based simulations.

Continue reading →

UVM: Forcing signals in UVM style

Apologies for a late post… Today I would like to mention about some of the useful HDL signal manipulation methods in UVM.

Have you ever wondered about how the backdoor accesses work in RAL?  We provide a string context path to our RAL based register class and we call some peek/poke API to hierarchically access the signal/register in DUT.

How can we do it in SystemVerilog? Providing a string based path and depositing/reading value based on hierarchical access. This seems to be very difficult using plain SystemVerilog. But this is a game played by something called as DPI/VPI.

UVM provides the backdoor access sub-routines for force/release or read/deposit some vale on any hierarchical path provided in the argument. These functions acts as an interface between SystemVerilog and C code to perform various operations. These functions can not only be used for backdoor accesses, but also for forcing some value in any RTL modules.

Continue reading →

SystemVerilog: Use of non-blocking while driving stimulus

This post is about a generally seen practice in any testbench driver. Ever thought that why it is better to use Non-Blocking Assignments (NBA’s) in driver? Let’s see what difference does it create.

As we know that every simulation in Verilog/SV executes according to a pre-defined set of steps known as stratified event queues. These steps are repeated for each an every entity and every time stamp. Let’s first understand the term known as simulation time and time stamp/time slot.

The term simulation time is used to refer to the time value maintained by the simulator to model the actual time it would take for the system description being simulated. The term time is used interchangeably with simulation time.

A time slot encompasses all simulation activity that is processed in the event regions for each simulation time.

Following are the event regions that are executed in each timestamp:

Continue reading →

UVM-OVM: Compare method bugs

Hi all this post mainly focusing on exercising a caution while using UVM/OVM built-in compare methods using field utility macros. We have seen many folks discouraging about the usage of field utility macros due to their overhead and complexity. But there seems more to it…

Recently while doing some conversion from OVM to UVM, I came across a bug in OVM while using “compare” method for associative arrays. The array was registered with factory with “OVM_NOPRINT” attribute. So I used “UVM_NOPRINT” as a UVM counterpart. But the testcase failed in UVM while it passed in OVM.

Continue reading →

UVM: How TLM ports work? (The straightforward way)

Continuing from my previous post about “UVM: How the TLM ports work?“, here I am presenting an easy way to understand the mystery. Today we will develop a simple infrastructure in SystemVerilog for the same put port. One can implement a get port in a similar fashion just by changing the direction of argument to the tasks.

Ports are nothing but the lightweight intermediate classes that calls specific tasks from one class to another. We will implement following infrastructure in this example:

Continue reading →

UVM: How TLM ports work? (The arduous way)

Wondering how uvm_ports work? One calls an API (let’s say put task) in some class and it can invoke the API in some other class and that too without creating object of other component! Recently I was studying UVM source code for the same and created a uvm_port type infrastructure in pure SV. Basically it is just a matter of passing handles through associative array. Thought of sharing this to make the understanding simple.

We will develop a put port in SV and believe me the other ports are just different flavors of this port. Here is the infrastructure that we are going to develop:

Blocking put port to implementation port connection

uvm_tlm_if_base // –> abstract class
uvm_port base extends uvm_tlm_if_base //–> Main connection takes place here
uvm_blocking_put_port extends uvm_port_base

object extends void
producer extends object
consumer extends object

env has producer and consumer
ENV: producer.port.connect(consumer.imp_port)

Continue reading →

UVM: Enigmatic gambits

Hello friends,

From now onwards, I shall be sharing some day-to-day tricks about UVM methodology. These tricks maybe as simple as explaining about a UVM function usage or can be somewhat trickier creating user-defined APIs.

Following is a list of tricks unrevealed so far:

  1. Tests without Sequence : Executing simple tests without creating sequence.
  2. Drop All Objections : Dropping ALL the raised objections from all components.

accelera uvm

Hope these might be helpful while actual creation of a UVM based testbench. More things to be posted soon.

UVM: Drop All Objections

In continuation with my previous post about Tests without sequence, today I would like to share another situational post about UVM that I came across recently.

The test requirement is framed like this: Whenever a timer (let’s say interrupt timer) gets expired, move out from run_phase and proceed with remaining phases like extract_phase, report_phase etc. In short, whenever timer expires, the sequence should stop execution and simulation should continue to next phases. Something like follows:

// In test
task run_phase(uvm_phase phase);

// In test extract_phase
function extract_phase(uvm_phase phase);
// Check packets, if timer is not expired.
// Else, check whether expiry of timer was valid or not.

// In some other component
task run_phase(uvm_phase phase);
interrupt_timer(); // interrupt timer based on clock pulse count
Continue reading →

UVM: Tests without sequence

This post is regarding an unadorned alternative for some straightforward tests in UVM. Lets begin talking about a recent scenario that I faced in a simple UVM test.

The test basically had multiple scenarios and scenario selection was randomized. Each scenario executes a single data traffic sequence and generates a different pulse on different interfaces.

Traditionally, in UVM, we would start the data traffic sequence and then some testcase specific sequence based on selected scenario. Some engineers would also prefer to add a selection/switching logic (bit or something) to testcase specific sequence itself.

The testcase specific sequence will eventually manipulate some fields in transaction class (in randomize with) and generate the required packet. Commonly, something like the following code would do the job.
Continue reading →

Demo to check that your analysis imports are connected or not..

  • It is very Time consuming to check all the analysis port connections manually.There is very easy solution to this and it’s shown below.
  • There are two methods called get_connected_to and get_provided_to in uvm_port_base class.

get_connected_to :  For an port or export type, this function fills ~list~ with all of the  ports, exports and implementations that this port is connected to

get_provided_toFor an implementation or export type, this function fills ~list~ with all of the ports, exports and implementations that this port is  provides its implementation to.

  • Below is a link of EDAPlayground , This example has a scoreboard with two analysis ports (good_xp and bad_xp). The good_xp is connected, while the bad_xp fails the connection check.

LINK : EXAMPLE for Analysis port connection check

More to come….



%d bloggers like this: