Tips to improve constraint solver performance !!!

Performance issues are very hard to debug, especially to find the root cause of the issue. If the constraint solving time is at unacceptable limits, the first area to debug is the bidirectional nature of the constraint implemented. quickly review the constrains that does not require bi-directional functionality and convert constraints from bidirectional to unidirectional using void termination or solve before, also reduce the number of constraints solved at a single point of time to improve performance.

Structures and union in system verilog !!!

VERA/NTB users migrating to system verilog have a tendency of not using structures and union construct in system verilog when architecting or implementing a system verilog verification environment. The reason being, this constructs are not available in VERA/NTB. Struct is pretty useful construct to group fields which are logically related to each other. It helps to organize you code. The union construct is very similar to a structure, but only one of the fields will be valid at a given point of time. Using packed struct and packed unions helps to organize fields in the memory without gaps, which in turn results in faster access to memory and results in faster simulation time.

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.

ASIC verification tasks verification engineers dislike the most !!!

I was having a friendly discussion with few of my fellow verification engineers, we were discussing about the verification tasks they dislike the most. The conclusion from the discussion was they disliked verification tasks which were laborious, which requires manual effort and had very little learning opportunity. The verification task they disliked are as follows.


1)Language migration without the help of a commercial language conversion tool
2)Code coverage analysis and identification of code coverage exclusions.
3) “X” tracing while debugging gate level simulation.
4)Release management ( Tagging the release code ,Triggering regression and debug of regression results ,becomes messy when more that 25 people are involved and release management is handled by a single person)
5)Working on outdated technology which is away from the verification market movement.

Top 6 verification misconceptions!!!

1)This is a silicon proven IP no need to do rigorous testing and coverage – Hold on are you sure if all the feature crosses are validated by the IP vendor in the silicon.

2)RTL is the one that is taped out and converted to a product no need to review verification environment, test plan review is sufficient --- 70 % of time is spend on verification out of which considerable amount of time is spend on developing test bench, re-usable and well architected test bench helps you to achieve your verification objectives in less time and in maintenance of your code in longer run.

3)This is a working legacy code keep it --- Legacy code with defect in the architecture is difficult to maintain and doing an enhancement on the code is a nightmare. Consider re-coding sections of the legacy code when you have to do an enhancement in the code to support a new feature.

4)Start the implementation and study the protocol as you go. We want you to be productive from day1 --- A big no!! You cannot architect an environment without understanding the protocol completely and you will always end up with a situation were you were not informed about a requirement.

5)Good verification engineer is the one who hit lot of bugs – Hold on you can have a bad designer who can make many mistakes, making ordinary verification engineer look exceptional.


6)No need to have an architecture document for a verification environment --- Reverse engineering a code to find out the verification environment architecture is not an easy job. It is a pain to understand the architecture of an environment after reverse engineering a code. Always document the architecture of your verification environment if possible document a class diagram.

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.