Verification environment architecture !!!

Architecting a verification environment with a dynamically changing requirement is a real challenge, when the entire requirement is known upfront you can fit your problem statement perfectly in to methodology. But if you get requirements in bit and pieces then you make an architectural decision based on the know requirements, when more requirements trickle in you find that decision you did earlier was not right. Option you have on hand is to re-write the code and correct your mistake or patch up the code and deviate it from the methodology recommendations resulting in less reusability. This is a typical problem that happens when overall picture of the problem statement is not understood by the architect. Another problem is due to the attitude that let us get the basic stuff working first, then incrementally fit the requirements in to the basic architecture.Typical project flow when requirements are not know upfront will be like this ( Just for humor !!! ).

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

First look at UVM Methodology !!!

I have been a RVM/VMM user for many years following advancements that come in VMM in every release; I try to use the new features whenever i get a chance. Recently i had a chance to take a first look at the UVM methodology. I was fully aware that UVM is based on the OVM methodology, with register package derived from VMM (RAL). Now how easy or difficult is it for a person with VMM background to pick up UVM with the fact that he does not have an OVM knowledge. From my experience I felt that this can be done very quickly in a matter of few days. As i started reading the UVM methodology and exploring the features of the methodology, I did see a lot of similarities between UVM and VMM. People who had a chance to use VMM 1.2 can make this switch even faster. I went through all the basic features UVM had to offer, looks very interesting. Then i decided i should explore UVM features in detail.

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.

Formal verification !!!

Recently i had a chance to know what formal verification is all about. My first impression on formal verification, it uses white box techniques to verify design against the black box approach used in constraint random verification. If your assertions or property definitions is accurate, formal tool can hit bugs faster than regular simulation effort. Ramp up on the formal tool takes little bit of time for people who are new to the formal verification world, debugging failures requires little bit of ramp up time as well. we need to debug failures without timing information by tracing schematics. When you get through the initial hiccups, you will definitely enjoy doing formal verification. Formal tool takes system Verilog or PSL assertions and tries to prove that your assertion can be violated by generating all possible stimuli.

uni-directional, bi-directional constraint & functions in constraints !!!

Consider a simple constraint example a == b + c;

Now if you constraint any of the 2 values of a,b,c the third value gets generated automatically due to the bi-directional nature of the constraint.

Now modify the constraint void (a) == b+ C;

Value of a gets generated first based on which b and c are generated. Generating a based on b and c is not possible. The same functionality can be achieved by using a solve before constraint as follows.

a== b+c;
solve a before b; solve a before c;

Functions can be used in constraints for reusability between constraints, but important point to note is the constraints will become uni-directional when used in a function.

function integer sum (integer b, integer c);
sum=b+c;
end function

Constraint sum_constraint { a==sum(b,c); }

Randomization of floating point or Real variable !!!

What are the application areas of floating point numbers ?

1) Floating point numbers are used in PLL configuration were fractional values are required.
2) Processor,image processing & graphics applications mostly work on floating point numbers.

Vera/ NTB does not even have a real or a floating point type; forget about randomizing a floating point number. The workaround for this is to write your own floating point class, randomize the class and use it. System verilog has a real type which is used to represents a floating point number, but a real type cannot be randomized. The LRM does not support the randomization of real data types. Some time back when i was discussing about this with one of my friend he was telling me that system verilog committee was working on this, not sure how true this information is.