do_copy() , do_compare(), do_byte_pack() , do_is_vaild() , do_allocate() & do_byte_unpack() !!!

do_*  methods overrides the default implementation of the vmm_data methods that is created by the shorthand macros. If the do_* methods are defined, this method is used instead of the default implementation. do_* methods are very useful can work well with short hand macros example you can just override the default implementation of  byte_pack() & byte_unpack() methods using do_byte_pack and do_byte_unpack and rest of the vmm_data methods can be auto generated by short hand macros.

Factory services in VMM !!!

Factory in VMM was implemented by assigning different blueprints to factory place holders like randomize_obj and scenario_set[] for atomic generator and scenario generator respectively. With the introduction of factory services from VMM1.1 replacing any type of object say a transaction or transactor can be done easily using methods like override_with_new() or override_with_copy(). We can replace one particular instance of an object with the derived object or we can replace all the instances of the object with the derived object.

Following are the steps one has to follow to use VMM factory services.

1. Use the macro `vmm_class_factory(class_name) to register the class to factory services
2. Use create_instance() to create an object instead of using new()
3. Use override_with_new() or override_with_copy() to replace and existing object with a derived object.
4. Use pattern matching to replace all the instance of the class or a particular instance of the class.

Accessing class attributes bottom up !!!

Accessing a property of a class top down is done through hierarchical access through dot operator which is very common in the HVL world. Accessing class properties bottom up through multiple levels is also a requirement we come across in verification which is little bit tricky to implement.

Following is an example on how we could do a bottom up access of a class property.

class top;
int flag;
level_1 obj;

function new();
obj=new(this);
endfunction

endclass

class level_1;
top parent_of_the_class;

function new ( top parent_of_the_class);
this.parent_of_the_class=parent_of_the_class;
endfunction

task run();
if(parent_of_the_class.flag==1)
begin
$display(" Flag set \n");
end
else
begin
$display(" Flag not set \n");
end
endtask

endclass

Constraint solver performance !!!

Debugging constraint solver performance issues is a real challenge; even a small mistake in a constraint can impact constraint solver performance . Common mistake people do which results in constrain solver performance degradation is to constraint the data payload to a predictable pattern to enable designers to debug RTL faster. When predictable data pattern is constrained for every transaction the number of bidirectional constraints solved increases exponentially resulting in constraint solver performance degradation. The problem would be magnified further when a scenario generator is used to randomize sequence of transactions.

The solution to this is if you would require a predictable data pattern to be used in the data payload override the random value with predictable pattern in post_randomize() method instead of going for a constraint, this would improve the runtime performance of your simulation.

Using vmm_opts to configure the test bench !!!

Traditionally plusargs switch is used in verification environments to configure attributes of the verification environment from the command line, like configuring timeout value of the test environment, configuring no of packets to be generated by the generator and setting error limits for the test to exit simulation. More compact and robust implementation of configuration mechanism in VMM is through vmm_opts. vmm_opts class has methods like get_object_bit(), get_object_int() to receive the runtime values in the environment. We can set different values to different instances from the command line. Example you can use the same configuration attribute for configuring no of packets for both TX as well as RX transactions and hierarchically set different values for TX and RX from the command line. Configuring global values like the test bench timeout does not require hierarchical access. The values can also be overridden from the test case using set_int () and set_bit() methods in place of a command line override.

Configurability of test bench from command line is a must have feature especially to abstract your test bench complexity from the consumers in this case a RTL designer , test case development team or release management team.

Register Automation using VMM/UVM RAL

VMM RAL had been around for a long time is a very powerful feature to verify your hardware registers it provides the user with features like name based register access, mirroring registers, back door access, functional coverage and the predefined tests .The same set of VMM RAL features are available in UVM as well. One of the features which i was impressed with was auto mirror update feature which updates the RAL mirror on register changes through backdoor, this feature is handy when you do your register read/write through an embedded processor instead of regular front door access and you want to synchronize your test bench based on the value of register mirrors.

Accellera has come up with standards like IPXACT and system RDL to define your registers, this enables vendor independence to the users and most of generator tools are converging on these standards. The ideal way of automating your register is to define the registers using the standards and use generators from vendors to auto generate the RTL, firmware code, documentation and system Verilog RAL classes.

Quick survey on the tools supporting the standards indicated that there are many players in this space. One aspect which did not sink into my head was why the entire register solution can’t be packaged with the simulator itself, so that the user does not have to make additional investment on another tool. May be it might be on the product road map for the simulators.

With VMM RAL being adopted in UVM, definitely the user base for RAL is going to increase.

Downside of being the “guinea pig” for adopting the latest buzz words in verification !!!

Adopting the latest’s verification methods and trends is my hobby right from the year 2002 and I have been continuing this till date. Adoption includes adopting new feature in the tool/methodology or construct in a language to adopting a new method of verification which could potentially improve the productivity, results in finding more bugs and improve the maintenance of the test bench. The upside of this hobby is you keep yourself updated with new trends in the market and become the early bird in adopting a trend. Evaluating the down side of this hobby did not come to my mind till one of my friends put an insight into my mind, adopting all the marketing buzz words can become fatal.

His words of wisdom made me rewind my thoughts on all the possible trends I tried to adopt over years. Few common trends i observed in each of the adoption are as follows

1) New code development is only 10% rest of the effort is making enhancements to the current environment. Tool vendors do not take this equation and end up facing gaps in the feature offering.

2) Being the first one to adopt a new verification trend, be prepared to face tool bugs, and sometimes even showstopper bugs.

3) Not all people have the practice of updating themselves to the latest trend and are more than happy to implement things with outdated technology. These people find it difficult to adapt to changes, we have to carry this type of people with us.

There have been feature or tools i have adopted early with became highly popular over years and some features i adopted early don’t even exist now.