vmm_broadcast and vmm_scheduler !!!

Channels are point-to-point data transfer mechanisms. If multiple consumers had to extract same transaction descriptors from a channel then vmm_broadcast should be used. vmm_broadcast broadcasts transaction from one source channel to multiple output channels. Copy of the transaction from the source channel is forwarded to the output channels. Assume if you have multiple interfaces having different signal level protocol transmitting the same transaction at the same time a VMM broadcast can be used in this scenario. Unified generator is connected to the source channel of the vmm_broadcast and output channels of the broadcast are connected to the drivers of the interfaces.

Vmm_scheduler directs the transaction from different input channels to single output channel based on a scheduling algorithm. The default scheduling algorithm is round robin mode, by adjusting the constraint you can also have a random scheduling implemented. If you need custom scheduling you can implement the same in the vmm_scheduler_election class. Scheduler can be used if you need to schedule transactions based on some timing information.

Verification environment architecture !!!

Architecting a verification environment with a dynamically changing requirement is a real challenge, when the entire requirement is known upfront you can fit your problem statement perfectly in to methodology. But if you get requirements in bit and pieces then you make an architectural decision based on the know requirements, when more requirements trickle in you find that decision you did earlier was not right. Option you have on hand is to re-write the code and correct your mistake or patch up the code and deviate it from the methodology recommendations resulting in less reusability. This is a typical problem that happens when overall picture of the problem statement is not understood by the architect. Another problem is due to the attitude that let us get the basic stuff working first, then incrementally fit the requirements in to the basic architecture.Typical project flow when requirements are not know upfront will be like this ( Just for humor !!! ).

Channel record & playback in VMM !!!

Channel record and playback is useful feature which can be used to reproduce an issue hit at top level environment in a different block level environment. As you know the randomization changes with the change in system Verilog files for the same seed, the same scenario cannot be reproduced with the same seed in a different environment due to the change in the system Verilog files. We need to spend time running random regression with different seeds at block level to reproduce the issue that happened in the top level with a particular sequence. The alternative way to reproduce the issue at block level is to record the transaction at top level which is done using channel record. Then playback the transaction through channel playback from the block level to reproduce the issue.

// Record transaction in top level

gen.out_chan.record("Record_transaction");

// Play back at Block level

gen.out_chan.playback(status,"Record_transaction",tr);

If (!status)

`vmm_error(log,”play back failed \n”);

First look at UVM Methodology !!!

I have been a RVM/VMM user for many years following advancements that come in VMM in every release; I try to use the new features whenever i get a chance. Recently i had a chance to take a first look at the UVM methodology. I was fully aware that UVM is based on the OVM methodology, with register package derived from VMM (RAL). Now how easy or difficult is it for a person with VMM background to pick up UVM with the fact that he does not have an OVM knowledge. From my experience I felt that this can be done very quickly in a matter of few days. As i started reading the UVM methodology and exploring the features of the methodology, I did see a lot of similarities between UVM and VMM. People who had a chance to use VMM 1.2 can make this switch even faster. I went through all the basic features UVM had to offer, looks very interesting. Then i decided i should explore UVM features in detail.

Error injection in VMM environments !!!

There are different approaches in VMM to inject error , each one selects a way which is comfortable for them. But when finalizing on an approach it is good to know the advantages and disadvantages in terms of test bench reuse and code organization.

Error injection in transaction class attributes

Design a transaction class with virtual fields specifying the error types and control the physical fields based on the virtual error types.

This error injection code can be placed with basic transaction class or the error injection code can be a separate class extending the basic transaction class. I would prefer the error injection class to be a separate class extending the basic transaction class as the code become better organized and you don’t end up having one big monolithic transaction class.

Most of the transaction based error injection should be done using this approach. Sequence involving error injection can be easily generated using this approach.

Error injection through call back registered through driver.

Error injection on the signal level protocol controlling the driver attributes should be done through call back registers to the driver. Transaction class error injection should not be handled through driver call backs.

Formal verification !!!

Recently i had a chance to know what formal verification is all about. My first impression on formal verification, it uses white box techniques to verify design against the black box approach used in constraint random verification. If your assertions or property definitions is accurate, formal tool can hit bugs faster than regular simulation effort. Ramp up on the formal tool takes little bit of time for people who are new to the formal verification world, debugging failures requires little bit of ramp up time as well. we need to debug failures without timing information by tracing schematics. When you get through the initial hiccups, you will definitely enjoy doing formal verification. Formal tool takes system Verilog or PSL assertions and tries to prove that your assertion can be violated by generating all possible stimuli.

uni-directional, bi-directional constraint & functions in constraints !!!

Consider a simple constraint example a == b + c;

Now if you constraint any of the 2 values of a,b,c the third value gets generated automatically due to the bi-directional nature of the constraint.

Now modify the constraint void (a) == b+ C;

Value of a gets generated first based on which b and c are generated. Generating a based on b and c is not possible. The same functionality can be achieved by using a solve before constraint as follows.

a== b+c;
solve a before b; solve a before c;

Functions can be used in constraints for reusability between constraints, but important point to note is the constraints will become uni-directional when used in a function.

function integer sum (integer b, integer c);
sum=b+c;
end function

Constraint sum_constraint { a==sum(b,c); }