VMM Channel methods grab, ungrab, lock, unlock !!!

Assume two different threads feeding a single channel with a sequence of transactions. If the transactions are just put in to the channel without using channel grab() the result would be that the sequence between two threads will be mixed producing unexpected results. Grab() method is used to request for exclusive access to the channel once the grab is activated no other thread can put an object in to the channel. Once the channel is loaded with the sequence of transaction object ungrab() should be used to release the channel for other threads. Is_grabbed () function can be used to know if the channel is grabbed.

Lock () method can be used to lock the channel producer (put ) or channel consumer (get ). Unlock () can be initiated to remove the lock(). Status of the lock can be got using is_locked() method. These methods are useful to control channel from a different location say different block.

Using a verification methodology to solve a verification problem !!!

Few problems that i always come across with verification methodology users is limited knowledge on what the methodology can offer and lack of effort on their side to update them self on the new features of the methodology. Once they are presented a verification problem to be solved using a verification methodology they come up with a solution based on their limited knowledge of the methodology. The solution they come up is exactly not the best solution that the methodology can offer. User manual / reference guide of a methodology can only educate you on the features the methodology can offer. Ultimately taking a decision on what features to use under what circumstance is totally left to the users of the methodology. This is where I find many people making mistakes starting from a simple noncompliance to a major architectural mistake. Once such types of mistakes are done the code eventually becomes an excess baggage that needs to be carried and maintained for the rest of the project life span.

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.