System verilog 2009 new features !!!

Following are some of the new features of system verilog 2009 standard that caught my attention.

1)`begin_keyword `end_keyword

The above defines can be used between any section of code to maintain backward compatibility with verilog or system verilog 2005, very useful if you are migrating your testbench or design to system verilog, you might come across system verilog keywords used in your verilog design which can cause compile to fail. With system verilog 2009 just wrap the code with `begin_keyword and `end_keyword to get past the error without modifying your code.

2) Let construct substitute to macros ?

Package example_package;
Let expand_operation (a,b) = assert ( !a & b)
end package;

module test ( …);
import example_package::*;

always @ ( …) begin
expand_operation (read,write); // expands to assert(!read & write)
end

end module


3) Pure constraints

virtual class example;
pure constraint valid;
endclass

Allows you to declare pure constraint in the abstract class,just the declaration alone without implementation. The implementation of this constraint is provided in the extended class with the same constraint name.

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.