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.

Gate level simulation !!!

One of time-consuming task in functional verification life cycle is gate level simulation. Gate level simulation can be broadly broken down into

1) Gate level simulation after synthesis to check equivalence with the RTL.

2) Gate level simulation with SDF on the post routed netlist.

A common question that is asked by many fokes is why step 2 is required. The netlist before P & R is compared with the netlist after P & R using formal tools for logic equivalence. Timing after P & R is checked with STA for all possible corners and configuration. It looks like an SDF simulation on post routed netlist is redundant.

Assume now a designer by mistake has place timing exception like false path and multi cycle path, the above condition goes undetected in the STA. Dynamic functional gate level simulation with SDF on post routed netlist is counter check for STA and catches if the designer has made mistakes on placing an timing exception.

Code coverage !!!

Coverage closure be it functional coverage or code coverage is one of the time consuming task in functional verification life cycle. With respect to functional coverage automatic coverage closure tools are available in the market. When it comes to code coverage it is very tedious and manual process to measure and close coverage, Code coverage number (Line, condition, fsm , toggle) of 95% is unacceptable in many places. The remaining 5 % coverage holes need to be completely analyzed and closed. More perfection requires more time and resource . Generally code coverage analysis is done by verification engineers who have relatively less knowledge in design this impacts the overall efficiency of the task execution. Why is code coverage important especially when we have functional coverage ? missing test cases are captured easily by code coverage which seems to have slipped through the functional coverage plan.

It is good idea to not include the register package test for code coverage as this test would give a false pass on the register coverage. We generally expect the register to be covered using functional tests, by including register package test we will end up covering registers by just doing a read and write to all the bits which is not our intent.

What make a verification team great !!!

Move with the industry trend

Verification keeps moving at a very fast pace, great verification teams move with the advancements very fast and implement those in the projects to reap the benefits. Ordinary teams stay with the old ways of doing things.

Knowledge sharing

The most important aspect for a verification team to become a great team is to share the knowledge they gained with the entire team improving the overall efficiency of the team.

Take the entire team with you

Most important aspect in managing and staging advance verification techniques in the project is the ability of the members to take the entire team with them. Ordinary teams follow the decision of the most powerful person in the team; great teams take a collaborative decision.

Risk taking

To implement or adopt new verification trends the team should be able to take calculated risk. If the risk taking ability is not there then it points to an ordinary team.

Expect the unexpected

One of the attributes of the great verification team is to expect the unexpected result during an adoption to a new trend and successfully overcome it. Ordinary verification teams back out when the unexpected behavior happens.