Open verification methodology

BY SHAIK MOHAMMED NAWAZ SOCtronics technologies.

Introduction to Methodologies
What is a Methodology?
Methodology is a systematic way of doing things with a rich set of standard rules and guidelines. Methodology provides the necessary infrastructure to build a robust, reliable and complete Verification environment.

Why do we go for Verification Methodology?

Methodology is basically set of base class library which we can use to build our test benches.

Continued..!!!
Just for an example consider transaction class.
Common functions you will require here is display, compare, copy transactions..etc.

Now what you will do is, you will keep these

common functions in some common area and you will access them through out the design. So this common area is nothing but your 'methodology'.

Continued..!!!
So the verification giants have already defined such common classes and functions which we will mostly require to build test benches and have formed one library. That's it; they call this base class library a methodology

why 'base' class library?

Well you can extend these classes to function it as per your requirement.

Methodologies have following advantages

Methodology Based verification includes:

List of verification Methodologies

AVM Advanced Verification Methodology (System C & Systemverilog) by Mentor Graphics

RVM Reference Verification Methodology (open Vera) by Synopsys

OVM Open verification Methodology (systemverilog) by Mentor Graphics VMM Verification Methodology Manual (systemverilog) by Synopsys UVM Universal Verification Methodology (systemverilog) by Mentor Graphics+Cadence

OVM is explored in this presentation.

OVM VERIFICATION ENVIRONMENT

The OVM Verification environment consist of
OVM components like
OVM Transactor OVM Sequencer OVM sequence OVM Driver OVM Monitor OVM Scoreboard

OVM Transaction
A transaction is data item which is eventually or directly processed by the DUT.
packets, instructions, pixels are data items.

In ovm, transactions are extended from

ovm_transactions class or ovm_sequence_item class.

Continued ..!!!
Transactions are extended from ovm_transaction if randomization is not done in sequence and transactions are extended from ovm_sequence_item if the randomization is done in sequence.

Example(Transaction)
class alu_item extends ovm_sequence_item; //This Example uses the sequencer hence the transaction class must be derived from //ovm_sequence_item class, which is child class of ovm_transaction. rand reg [ 7:0] data_in1 ; rand reg [ 7:0] data_in2 ; rand reg [ 2:0] select; rand bit reset_N; constraint rest_c1{reset_N == 1'b1;} `ovm_object_utils_begin (alu_item) `ovm_field_int(data_in1 , OVM_ALL_ON) `ovm_field_int(data_in2 , OVM_ALL_ON) `ovm_field_int(select , OVM_ALL_ON) `ovm_field_int(reset_N , OVM_ALL_ON) `ovm_object_utils_end

Example continued..!!!
// new constructor
//constructor new is passed a string used to build //unique instance name of transaction.
function new (string name = "alu transaction instant") ; super.new(name); endfunction
endclass

Continued...!!!
As transactions are created we need to copy, compare, print, pack, and unpack those transactions is done automatically by inbuilt ovm macros as shown below.
`ovm_object_utils_begin (alu_item) `ovm_field_int(data_in1 , OVM_ALL_ON) `ovm_field_int(data_in2 , OVM_ALL_ON) `ovm_field_int(select , OVM_ALL_ON)

`ovm_field_int(reset_N , OVM_ALL_ON)
`ovm_object_utils_end

The flag OVM_ALL_ON indicates that the given field should be

copied printed, included in any comparison for equality between two transactions, and so on.

OVM sequence.
A sequence is a series of transaction. User can define the complex stimulus. sequences can be reused, extended, randomized, and combined sequentially and hierarchically in various ways.
A complete sequence generation requires following 4 classes. 1- Sequence item(Transaction). 2- Sequence 3- Sequencer 4- Driver

sequence:
User should extend ovm_sequence class and define the construction of sequence of transactions. These transactions can be directed, constrained randomized or fully randomized
//example class ovm_sequence #(

type REQ = ovm_sequence_item, type RSP = REQ

)

Sequencer:
sequencer is responsible for the coordination between sequence and driver.

Sequencer sends the transaction to driver and gets the response from the driver.
The response transaction from the driver is optional.

When multiple sequences are running in parallel, then sequencer is responsible for arbitrating between the parallel sequences. There are two types of sequencers : ovm_sequencer
and ovm_push_sequencer

Continued..!!!
//example for sequencer
class ovm_sequencer #( type REQ = ovm_sequence_item,

type RSP = REQ

) //example for push sequencer

class ovm_push_sequencer #( type REQ = ovm_sequence_item, type RSP = REQ )

Driver :
User should extend ovm_driver class to define driver component. ovm driver is a component that initiate requests for new transactions and drives it to lower level components. There are two types of drivers:
ovm_driver and ovm_push_driver.

Continued..!!!
class ovm_driver #( type REQ = ovm_sequence_item, type RSP = REQ ) class ovm_push_driver #( type REQ = ovm_sequence_item, type RSP = REQ ) In pull mode , ovm_sequencer is connected to ovm_driver , in push mode ovm_push_sequencer is connectd to ovm_push_driver.

Continued..!!!
Ovm_sequencer and ovm_driver are parameterized components with request and response transaction types. REQ and RSP types by default are ovm_sequence_type types. User can specify REQ and RSP of different transaction types.
If user specifies only REQ type, then RSP will be REQ type.

Driver And Sequencer Connectivity:

Driver and sequencer are connected using TLM. Ovm_driver has seq_item_port which is used to get the transaction from ovm sequencer. This port is connected to ovm_sequencer seq_item_export Using
<driver>.seq_item_port.connect(<sequencer>.seq_item_export);

driver and sequencer can be connected. Simillarly "res_port" of driver which is used to send response from driver to sequencer is connected to "res_export" of the sequencer using
<driver>.res_port.connect(<sequencer>.res_export);

Continued..!!!

Sequence And Driver Communication:

Continued..!!!

Simple Example
//simple instruction example with //PUSH_A,PUSH_B,ADD,SUB,MUL,DIV and POP_C. Sequence item code:

class instruction extends ovm_sequence_item; typedef enum {PUSH_A,PUSH_B,ADD,SUB,MUL,DIV,POP_C} inst_t; rand inst_t inst;
`ovm_object_utils_begin(instruction) `ovm_field_enum(inst_t,inst, OVM_ALL_ON) `ovm_object_utils_end function new (string name = "instruction"); super.new(name); endfunction endclass

Sequence code class operation_addition extends ovm_sequence #(instruction); instruction req; function new(string name="operation_addition"); super.new(name); endfunction `ovm_sequence_utils(operation_addition, instruction_sequencer)

virtual task body(); req = instruction::type_id::create("req"); wait_for_grant(); assert(req.randomize() with { inst == instruction::PUSH_A; }); send_request(req); wait_for_item_done(); //get_response(res); This is optional. Not using in this example.

req = instruction::type_id::create("req"); wait_for_grant(); req.inst = instruction::PUSH_B; send_request(req); wait_for_item_done(); //get_response(res); req = instruction::type_id::create("req"); wait_for_grant(); req.inst = instruction::ADD; send_request(req); wait_for_item_done(); //get_response(res); req = instruction::type_id::create("req"); wait_for_grant(); req.inst = instruction::POP_C; send_request(req); wait_for_item_done(); //get_response(res); endtask endclass

Sequencer Code; class instruction_sequencer extends ovm_sequencer #(instruction); function new (string name, ovm_component parent); super.new(name, parent);

`ovm_update_sequence_lib_and_item(instruction)
endfunction `ovm_sequencer_utils(instruction_sequencer)

endclass

Driver:
This driver is used in pull mode. Pull mode means, driver pulls the transaction from the sequencer when it requires. Ovm driver has 2 TLM ports. 1) Seq_item_port: To get a item from sequencer, driver uses this port. Driver can also send response back using this port. 2) Rsp_port : This can also be used to send response back to sequencer.

Seq_item_port methods:

class instruction_driver extends ovm_driver #(instruction); // Provide implementations of virtual methods such as get_type_name and create `ovm_component_utils(instruction_driver)

// Constructor function new (string name, ovm_component parent); super.new(name, parent); endfunction
task run (); forever begin seq_item_port.get_next_item(req); $display("%0d: Driving Instruction %s",$time,req.inst.name()); #10; // rsp.set_id_info(req); These two steps are required only if // seq_item_port.put(rsp); responce needs to be sent back to sequence seq_item_port.item_done(); end endtask endclass

Testcase Code: module test; instruction_sequencer sequencer; instruction_driver driver; initial begin set_config_string("sequencer", "default_sequence", "operation_addition"); sequencer = new("sequencer", null); sequencer.build(); driver = new("driver", null); driver.build(); driver.seq_item_port.connect(sequencer.seq_item_export); sequencer.print(); fork begin run_test(); sequencer.start_default_sequence(); end #2000 global_stop_request(); join end endmodule

Log file Output

OVM_INFO @ 0 [RNTST] Running test ... 0: Driving Instruction PUSH_A 10: Driving Instruction PUSH_B 20: Driving Instruction ADD 30: Driving Instruction POP_C

References:
www.systemverilog.in
www.asicguru.com

www.testbench.in
www.verificationacademy.com

THANK U