six reasons why you should use system verilog for verification !!!

1) System verilog is an IEEE standard supported by multiple vendors, your code is portable across simulators.You are not tied to a single vendor, which is the case if you are using HVL like VERA/NTB/SPECMAN.

2) Free open source standard verification methodologys like VMM & OVM are available which can be used with system verilog.

3) Simulation speed will improve,if you are an HVL user using VERA/SPECMAN for verification.

4) Most of the VIP vendors support system verilog, building verification environment for SOC will not be an issue.

5) System verilog interoperability layers are available, you can re-use you VERA/NTB code from system verilog,similar arrangement is available for specman user too.

6) System verilog supports most of the constructs supported by HVL ( VERA/NTB/SPECMAN) , migration to sytem verilog for HVL users will not be an issue.

Learning curve for a verification engineer !!!

For a verification engineer, which of following work environment gives him maximum learning opportunity ?


1) IP verification
2) SOC verification
3) Verification IP developement
4) Verification consultancy

I will try to evaluate each of these work environment.

According to me,the skill you accuire on doing your day to day activities at your work place should match the requirements of the industry and should be portable across companies. (i.e) Assume you are doing an assembly level verification for a processor design using internal tools of that company, the methodology and tool knowledge is limited to that particular company and skill is not portable between companies, then the skill you accuired is not marketable, hence the learing curve is minimum in this case.

We can find our self in above scenario in verification consultancy work environment where we have very little control of job nature , implementation flexibily is also minimal in this case. One good thing about this work enviroment is you will get your hands dirty on different type of projects and you will rarely find your self struck with the same project. In comparitive scale verification consultancy work enviroment gives verification engineer moderate learning curve.

Verification IP developement requirement and process are different from RTL developement and verification. In this kind of work environment we have very good learning curve on the new verification methodology , we can improve our knowledge on different languages as VIP are developed in single language but controlled through different languages like VERA/NTB/VERILOG/SYSTEM VERILOG /C. you can gain good protocol knowledge by developing the VIP and stay updated on the developements in the protocol. One of the draw backs in VIP developement work environment is your initial learning curve will be steep, after few years most of you work will be just bug fixes and some times VIP enhancements. In comparitive scale VIP developement work enviroment gives verification engineer moderate learning curve.

SOC verification work environment is different, as the verification is done on proven design IP,finer points in protocol are generally ignored. One good thing in SOC verification is we end up working on different type of protocol and interfaces. In comparitive scale SOC verification work enviroment gives verification engineer good learning curve provided he works on different interfaces every project.

In case of IP developement work environment , your learning curve on the protocol will be good.The test plan and implementation will touch the finer points in protocol verification. In comparitive scale IP verification work enviroment gives verification engineer good learning curve provided his company has migrated to system verilog or HVL based verification.

The best scenario is to have at least a few years of experience in all the type work environments, so that you can get good experience in verification methodology, verification tools,languages & different protocols.

VMM Planner

So what is VMM planner ? VMM planner is a tool which can atomatically annotate the functional coverage and code coverage from regression runs and present the data in a XLS or XML format. It associates the test plan to the test result automatically. The planner can be used for managing verification effort for any project. The basic requirement for using VMM planner is we need to have complete test plan mapped to a functional coverage model. Once we have the plan as an XML or HVP document we can automaticlly annotate the test result using HVP commands. Some of the user provided metrics like bug count , test pass/fail count can be provided to planner tool using the userdata command .We can use VMM planner to report verification status to top level management.

Coverage convergence technology (CCT)

CCT automates the process of going between coverage goals and determining what constraints to modify, then modifying the constraint to achive the functional coverage goal. CCT also has a provision to automatically generate functional coverage groups from the VERA/NTB/System verilog code based on the constraints specified.

The automatically generated functional coverage code can be used as the starting point for writing the functional coverage model and can be integrated with the DV enviroment. CCT also allows parallel test runs with each test run targetting different coverage points without having any overlap between them. parallel test runs without overlapping random values is achived by providing the tool with a bias file which is generated by the tool based on the functional coverage data base.

Streaming operators --- System verilog

In VERA/NTB we have vera_pack & vera_unpack methods to pack a class object to bit stream or unpack a bit stream to a class object. System verilog does not have a pack or unpack methods the replacement for this methods are the Streaming operators << , >>. These operaters have the same functionality as the pack/unpack methods. We frequently see the usage of pack and unpack methods while extending the RVM/VMM classes like rvm_data/vmm_data.

Following is an example on the usage of Streaming operators

byte stream[$]; // byte stream

class Packet
rand int header;
rand int len;
rand byte payload[];
int crc;
constraint G { len > 1; payload.size == len ; }
function void post_randomize; crc = payload.sum; endfunction
endclass
...

send: begin // Create random packer and transmit
byte q[$];
Packet p = new;
void’(p.randomize());
q = {<< byte{p.header, p.len, p.payload, p.crc}}; // pack
stream = {stream, q}; // append to stream
end
...

receive: begin // Receive packet, unpack, and remove
byte q[$];
Packet p = new;
{<< byte{ p.header, p.len, p.payload with [0 +: p.len], p.crc }} = stream;
stream = stream[ $bits(p) / 8 : $ ]; // remove packet
end

Automated coverage closure

Nusym tool does automated coverage closure. It automatically directs the random constraints so as to target coverage points.It automates the process of going between coverage goals and determining what constraints to modify, then modifying the constraint to achive the coverage goal. When we hit bug in random scenario we generally re-play the sequence to fix the bug , but with Nusym's verification tool the same bug is reproduced just at the point of bug , the long sequence of random transaction need not be reproduced to hit the bug. The tool supports both VERA and Systemverilog languages for automatic coverage closure.

Randomization of scalar variables -- System Verilog

In VERA/NTB to randomize a set of variables we need to have variables in the class add constraints/ in-line constraints to randomize the variables. More over the variables have to be of type rand or randc Assume we have a requirement to randomize a set of variables outside a class with a set of constraints. We have the option of using random(),urandom() or urandom_range() and randomize the variables separately. When we use the above listed random methods we can not randomize a variable based on another variable.

System verilog has an option of randomizing scalar variables out side a class with constraints.

Example

integer a,b,c;
void'( std::randomize(a,b,c) with { a==b;b>0;c==10; } );

The above construct generates random values for a,b,c the constraint is provided in line. The variables a,b,c are out side the class scope.