OOP method to access variables of the derived class !!!

We typically use virtual set_() and get_() methods to access the variables added in the extended class from the base class. class handles are created using the base class and type and instance factory overrides are used to replace the class handles respectively. Any reference to the derived class variable from base class is done using virtual set_() and get_() methods which are just empty methods in the base class. At runtime the derived class virtual methods are linked and variables are written or read using set and get methods after a type or instance override.

Base class library specific to product on top of RVM/VMM/OVM/UVM !!!

RVM/VMM/OVM/UVM provides rich set of features that can be used to develop a sophisticated test bench. Extending your Driven/monitor/scoreboard/sequence directly from the methodology may not be an ideal solution with respect to product specific requirement. The ideal way is have a set of base class extending from the methodology class which adds specific requirement which will be product line specific. Having company/product specific base class helps in better reuse and isolates the users from the changes introduced  due to new releases in the methodology. When ever specific base class is changed it can be qualified with the supported version of tool,methodology and VIP. This approach also helps to incrementally move towards the latest releases of the methodology ensuring current development effort is not stalled.

System verilog 2012 features !!!

I recently came across a paper presented at DVcon 2012 which summarized the proposed features of system verilog 2012 standard. The feature that  first grabbed my attention was multiple inheritance  support in system verilog similar to Java. This feature will ease the test bench development effort in future. The current methodology based on system verilog will potentially leverage this feature when it is available. Other feature which is also a good addition is the soft constraints which allow the constraints to be overridden without creating a conflict , currently we have to turn of the conflicting constraints using constraint mode to override a constraint. another interesting addition is the unique constraint to generate unique values across a list of variable or array elements , currently most of the users use custom logic or algorithm to generate unique values.

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.

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.

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.

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”);

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.

Test end condition using vmm_consensus !!!

VMM provides the vmm_consensus class as a voting mechanism, which is used to determine when the test could be terminated. Earlier before the introduction of vmm_consensus class end of test condition was determined by some condition like score board empty condition or a timeout. The test end condition was tied to a specific environment and was not reusable across environments.

With the introduction of vmm_consensus class various elements such as channels, notification, and transactors play the role of voter and all voters have to agree for a consensus. Even if one voter opposes there will be no consensus. The vmm_consensus has a wait_for_consensus ( ) method which will be called in vmm_env’s wait_for_end ( ) method. The wait_for_consensus ( ) method will block till all voters consent.


How to use vmm_consensus to determine when the test should end ?

1) Add vmm_consensus::wait_for_consensus ( ) method to vmm_env::wait_for_end () method

2) Register voters in the vmm_env::build ( ) using end_vote.register_* () method, where end_vote is the instance of vmm_consensus defined in vmm.sv

3) Each of the sub environment instance has a single vote, it can consent or oppose.

4) We have options such as consensus_force_thru() which can be used by a particular subenv or a VMM components to force consensus through even though other components oppose the decision.

5) As usual we have methods that can be used to monitor the status of consensus, which components oppose and which components consent.

Scoreboard for checking interrupts !!!

Architecting a good interrupt monitor and an interrupt scoreboard is very essential to hit bugs and close coverage on the interrupt logic of the design.The architecture is very simple, you need to have a shadow register for your interrupt status register and predict the interrupt by writing in to this register, the predication should be done in the transactor based on the transaction class attributes for a regular transaction, error condition ect .. The interrupt scoreboard should reside on the passive interrupt monitor which reads the shadow register as well as the original hardware register and the mask and makes a comparison on the expected interrupts and flags an error if the interrupt is mismatching. The monitor should have options to clear the interrupt when it is available or accumulate interrupt and clear it when it is required. At end of the simulation a comparison of shadow register and real interrupt status register needs to be done to check if all the expected interrupts have arrived and flag appropriate error messages.

Interfacing CRV environment with procedural environments !!!

One of interesting challenges in verification is building constraint random verification environment on top of an existing code which is a procedural code.The challenges are unique to each of the environments; simplest solution is wrapping the procedural code in a transactor which is connected to a channel which interfaces with the constraint random generators. Transaction object attributes are mapped to different functionality in the procedural code.

Factory replacement in the scenario generator scenario using ‘.using’ gotcha !!!

When you want to do a factory replacement of a transaction class in your scenario,we assign the factory to .using.

Scenario.using=transaction_factory;

The gotcha in this factory replacement is we need to implement the allocate() and copy() methods in the extended class for the factory replacement to work.


Many times i have seen people including myself spending time debugging their code when using “.using” for factory replacement as they are not aware of the gotcha.Maybe the RVM/VMM documentation should have this requirement highlighted so that the user can easily understand this requirement.

Atomic generator using allocate() !!!

RVM/VMM atomic and scenario generator randomizes a blueprint pattern which is assigned with the extended class (factory) , the copy of the randomized blueprint is pushed into the channel. Most of the RVM/VMM users use this approch in there custom generators. Is there a different way of implementing your atomic generator without using a copy() method ?. The answer is yes, following method can be used to generate atomic transaction without using copy().




For the above code to work you need to implement the allocate method in your extended class. The extended class is assigned to the factory before the start_xactor() method is called.

Checker for complex constraints spanning multiple transaction !!!

It is hard to debug the constraint failures spanning multiple transactions say sequence of ten to fifteen transaction were the constraints on each atomic transaction is dependent on the other. Manual debug on such failures are time consuming.We can use a procedural checker to check the randomization of the scenario which is an array of transaction objects. In RVM/VMM the procedural checker can be placed in the post_scenario_gen callback of the RVM/VMM scenario generator. The post_scenario_gen has drop bit which can be set from the callback to stop the transactions from being pushed in to the channel.The checker is active at all times and flags an error if there is an error in the randomization across transaction.

VMM 1.2 tutorial !!!

I was looking out for a nice tutorial on the new features of VMM 1.2. I came across this 2 hr video tutorial on VMM 1.2 features on the VMM central web site (http://www.vmmcentral.org ). Nicely composed video covers all aspects of VMM 1.2 release from implicit phasing, analysis ports, transport & factory. Definitely useful for VMM 1.1 users migrating to VMM 1.2.