Closing “quality gap” in functional verification !!!

Recently i came across a white paper on a new EDA tool certitude which is used to close the ”quality gap” in functional verification using mutation techniques. The tool introduces mutations in the RTL code and then subjects the mutated RTL to the verification team's test bench and checks if the verification environment has been able to detect, activate and propagate the mutations. If the verification environment is able to catch the mutations, then the verification is probably complete and there is a reasonable certainty that no bugs are left. If not, there could be serious weaknesses in the test bench and it needs to be reworked. Put simply, if the verification testbench cannot detect the mutations (or bugs) introduced, chances are there that other bugs are also left out.


Another way to see the situation is that after introducing mutations, we have two versions of the RTL code, one original and one mutated (say, bugs) and the verification environment is passing both. Clearly then there is a weakness in the verification environment which needs to be fixed.

The tool works with all the major simulators available in the market and works with all languages C, System C, System Verilog, Specman e, Vera.

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.

Another verification methodology UVM !!!

Recently through one of my friends i came to know about the development of a new verification methodology UVM.The UVM ( Universal verification methodology ) is being standardized by Accellera Technical Subcommittee (TSC) and claims to solve the system verilog cross methodology interoperability problem. This methodology is being suppored by all the 3 major EDA vendors synopsys, cadence and mentor. The advantage of switching to this methodology (when it is available) is portability of the methodology across different vendors. The base code for this methodology will be from OVM version 2.0.3.The base classes for UVM methodology is expected by Q1 2010.


It is still not clear about the backward compatability of this methodology with OVM. To me backward compatibility with VMM is out of question as the base code for this methodology is from OVM.

Functional coverage in RVM /VMM !!!

The conventional way of collecting functional coverage for a transaction class in RVM/VMM is through RVM/VMM callback and it generally reports the functional coverage on the random transaction generated by the generator, The functional coverage point hit or miss is purely dependent on the generated random values there is no real check if that scenario was hit in the RTL or not, meaning if you disconnect the RTL completely from the verification environment and run the test the functional converge point will still be hit.


Ideal way is to have a passive monitor hooked up to the RTL which will collect functional coverage, the idea is like sampling the values from the RTL through the passive monitor and unpacking the bytes to a transaction class object and from the transaction class object we can easily collect functional coverage. By having such an arrangement we make sure that the functional coverage point is only hit when the scenario is hit in the RTL. I know this approach requires more effort but we can be absolutely sure that the functional coverage hit will happen only if the scenario happens in the RTL. More over your functional coverage code will be isolated from rest of the verification environment code. In case of VIP development, this is the right approach to group you functional coverage model with a passive monitor.



Some of the drawbacks to this approach are the latest coverage convergence technology might not work well with this approach. You might not be able to tune or bias your constraint solver to achieve your functional coverage convergence automatically. Especially when you collect the functional coverage from RTL nodes you need to update your test bench whenever there is a change in the RTL code which affects the way functional coverage is collected.


one more reason for choosing this approach is if you have more than one way of verifying the design and we want the functional coverage monitor to collect functional coverage irrespective of the way of generating the stimulus this approach will work perfectly well.

RVM/VMM Scenario generator !!!

RVM/VMM ships with some pretty useful built-in components and applications. RVM/VMM's Atomic Generator is probably one of the most powerful ones, yet it's pretty basic. It can definitely help you generate a flow of random items but it was not intended for generation of sequences. A sequence (scenario) is a set of items that have some sort of correlation between them. For example - consider a set of 6 transactions where the transaction 4 depends on the previous transactions say transaction 2. Atomic generator can not generate this kind of sequence, RVM/VMM addresses the need for smart scenarios with the "RVM/VMM Scenario Generator"

Since we can not anticipate the future enhancement in the verification environment it is better that we provide the flexibility in the verification environment for generating scenarios. Selecting scenario generator will be the right step.

The deployment of scenario generator in the verification environment is slightly complex that deploying an atomic generator, but we can have the complete controllability on the micro transactions in a sequence using scenario generators. Deploying a scenario generator in the verification environment will help you in the longer run, also you can randomize between scenarios.

Infact coverage convergence tool !!!

To start with infact tools features; infact is a graph based tool which generates the random values and traverse through the various predefined paths through graph algorithm. It uses a complimentary technology to a constraint solver (i.e) a graph algorithm. The tool has to be inputted with graph rules which will be processed by the tool to generate all possible combination of the rules. There are no redundant values or combinations generated. The unique value is generated across multiple parallel runs on server farm. We need to provide the tool with all possible combinations. The tool can work with any language say verilog, vhdl, vera, ntb, specmen, system verilog & C++ . Infact tool communicates with simulator through a PLI call. Existing constraint random code needs to be represented as a graph rule and the infact tool will generate the random values.

Joy of doing ASIC verification!!!

Verification is often treated as the step-child of design. Decade back verification was considered less critical task than design by some companies and fresher’s where often pushed in to verification It’s not surprising, then, that most of the verification engineers want to be designers. But now verification is more lucrative career option than design and many experience people now hold on to verification without moving to design. It is generally estimated that 70% of ASIC design cycle is spend on functional verification. The ratio of verification engineers to design engineers is approximately 3:1. Job switching for verification engineers is easy when compared to the designers provided they have the right skill set. The advancements happen in verification at a very fast rate that design.

Earlier verification job was looked down, as the design is what is getting taped out and moves in to mass production stage not the test bench. But verification requires lot more effort and skills, example, to test a 100 line state machine we need to develop testbench which will have atleast 500 lines of code and draft a test plan which covers all the possible scenarios. VIP development companies get their revenues from their testbench which is licensed and shipped as a product.

Reasonably experienced person will know that building a re-useable system level verification environment and verifying the design without any post silicon bugs is more difficult than adding a glue logic in the design.

Do you still believe verification is a less critical task and requires lesser expertise that design?