Sv Ovm Paper Part1

System Verilog + OVM: Mitigating Verification Challenges & Maximizing Reusability

1


Authors Parag Goel [[email protected]]

Pushkar Naik [[email protected]]

mailto:[email protected]:[email protected]


2

Abstract Verification has been becoming a nightmare for engineers with the increasing requirements and complexity of the design. Mitigating the complexity of a verification environment with the increasing complexity of design verification can be re-defined as a CHALLENGE. System Verilog along with its library of classes OVM, provides a platform to face this CHALLENGE. This paper explains how, in our endeavor to accomplish an ideal verification platform for our designs using System Verilog and a standard methodology(OVM) plus some in-house ideas over it, helped us to make a more practical and easy to use verification environment. The challenges spanned right from configuring the components, injecting the transactions to create various test scenarios, phasing of the test cases till the end of report generation etc. This paper also explains how SV & OVM has simplified a whole lot in controlling the messaging policy, sequences & sequencers layering, OOPs data patterning to fit certain environment architecture requirements, barrier mechanism to overcome OVM phasing limitations and ready-made harness system for the sub-system integration, making things simpler & organized. It also explains how the addition of a thin layer between the OVM Methodology classes and our projects base classes helped us in shielding our projects from any changes in upcoming OVM releases as well as served to provide a place holder for any additional functionality in our base classes, without even touching the OVM source code as such. Towards the end, some points to ponder have been summarized based on our experience with OVM and some enhancements in Questasim / OVM are suggested.


3

Table of Contents

Contents

1 Introduction -------------------------------------------------------------------------------------------------------------------------------- 4

2 OOPs Design Patterns (Singleton Instantiating One Object) --------------------------------------------------------- 4

3 Use of Parameterized Interface(s) in a Package ------------------------------------------------------------------------------ 7

4 Harness- a Complete Sub-system definition ----------------------------------------------------------------------------------- 8

5 Sequencer Layering -------------------------------------------------------------------------------------------------------------------- 13

6 Single Class / Multiple Analysis ports --------------------------------------------------------------------------------------------- 15

7 SV world to C world - Host Communication ---------------------------------------------------------------------------------- 18

Code References Code 1 Example for Singleton Statistics collector ........................................................................................ 5 Code 2 Example for Singleton memory implementation ............................................................................... 6 Code 3 Example for Singleton memory usage ............................................................................................. 7 Code 4 DUT definition ................................................................................................................................. 10 Code 5 SVTB Interfaces definition .............................................................................................................. 10 Code 6 Virtual Interface packages .............................................................................................................. 10 Code 7 Connection module - AXI ............................................................................................................... 11 Code 8 Connection module - USB .............................................................................................................. 12 Code 9 Testbench Top ................................................................................................................................ 12 Code 10 Monitors to be connected to score-board ..................................................................................... 16 Code 11 Agent code showing monitor & scoreboard connection ............................................................... 16 Code 12 Score-board showing implementation .......................................................................................... 17

List of Figures Figure 1 Singleton pattern Statistics Collector ........................................................................................... 5 Figure 2 Singleton Pattern Memory Modelling & Sharing .......................................................................... 6 Figure 3 Parameterized Interface(s) in a package ........................................................................................ 8 Figure 4 Verification Setup Requirement ...................................................................................................... 9 Figure 5 Typical Setup Todays Scenario .................................................................................................. 9 Figure 6 Harness The Solution ................................................................................................................ 10 Figure 7 Completely integrated testbench Harness Approach ................................................................ 11 Figure 8 Sequence layering OVM recommended way ............................................................................ 13 Figure 9 Sequence Layering Using Sequencer layering ......................................................................... 14 Figure 10 Analysis FIFO connection model monitor & score-board ........................................................ 15 Figure 11 Host Communication module-level setup ................................................................................ 19 Figure 12 Host communication module/SoC setup ................................................................................. 20


4

1 Introduction

Seventy percent of project time is consumed in verification and still there are Bug(s) in the design that are revealed after tape-out or at the customer end, that raises question(s) on the ability & the sincerity of the verification engineer and overall credibility of the organization as such. But the real question that needs to be raised is Do we have enough technology available to create all possible stimuli to the DUT and gauge the amount of verification performed so far, quantitatively, in order to confidently say that the DUT has been satisfactorily verified? Is the verification environment available to the tester, providing him/her, enough flexibility to exercise the required test scenarios without modifying the golden test bench? The Methodology we developed at AMCC tried to answer several such above questions utilizing the OVM/SV combination and some in-house ideas as mentioned before. This paper is broadly divided into the following sub-sections:

1. System Verilog concepts making environment simpler a. Usage of Design patterns b. Usage of parameterized interface(s) in package(s) c. Concept of harness for sub-system port mapping

2. Advanced OVM Usage a. Sequence / Sequencer layering b. Single Class / Multiple Analysis Ports Usage c. SV to C world host communication

3. Work done to overcome OVM limitations a. Messaging control in OVCs b. OVM barrier enhanced phasing mechanism

4. Miscellaneous topics a. Sequence initiation methods comparison in OVM b. Some points to ponder c. Questasim / OVM Enhancements moving forward

2 OOPs Design Patterns (Singleton Instantiating One Object)

As per the definition from the book Design Patterns: Elements of Reusable Object-Oriented Software the Singleton design pattern must: Ensure a class only has one instance, and provide a global point of access to it. Usage of this pattern lets you take away control over the object instantiation process from the new operator. This kind of pattern can be used over and above the classes available in the OVM library in cases where one might need to refer one and the same instance of the class across the components and across the hierarchy. To achieve this objective one can use the concept of the Singleton pattern available in OOPs. The two very common applications that can be thought for a VC based on System Verilog are as described below. 1. Statistics Collector class (Refer to Figure 1) There are situations where you require to display

a summary of information at the end of the simulation which actually helps in deducing the inferences for a given test case. This may broadly consists of ,

1. The Statistical collection - a summary of injected/collected transactions across the score-board.

2. Error counters transaction related errors.


5

3. Count of Compares/Mis-Compares of transaction elements etc. can be added to the scoreboard by the user.

Figure 1 Singleton pattern Statistics Collector

This block will necessarily be a singleton class that will contain all the properties related to the above mentioned points. These properties shall be populated & updated from several components sitting in the VIP environment, and at the end of simulation it will display the complete information collected in a simple & easy to understand manner. Needless to mention, how OVM also aids in such scenario, by providing certain in-built methods for printing messages uniformly in the report phase etc. Lets understand how it works from the code perspective [Refer to Code 1]:

Code 1 Example for Singleton Statistics collector

VIP components populating the properties of a single class.

Statistics Collector

Bus Monitor Driver Scoreboard

class report_handler extends ovm_object;

//Properties to collect statistics

int Total_Transfers;

int Read_Transfers ;

int Write_Transfers;

//Register to get built-in methods ready-made

òvm_object_utils_begin(report_handler)

òvm_field_int(Total_Transfers , OVM_ALL_ON)

òvm_field_int(Read_Transfers , OVM_ALL_ON)

òvm_field_int(Write_Transfers , OVM_ALL_ON)

òvm_object_utils_end

// object that is created only once

static *_report_handler single[*];

function new();

endfunction

// method to get object

static function report_handler get_instance(int id);

//call the constructor for the first time, if the object has been

//created already return reference to that object else create new one

if(!single.exists(id)) begin //{

// constructor that is called only once

single[id] = new;

end //}

// return the reference to already created object

return single[id];

endfunction

endclass


6

2. Lets take a look at the next application, where one requires modeling a memory with parameterized address and data width which can be used across classes/models, still referring to a single memory array. As shown in the figure below (Refer to Figure 2), a memory is being accessed for reads/writes by the DUT through a Protocol BFM as well as it can be accessed via. a backdoor path accessing the read/write functions written in the memory. [Code : 2,3]

Figure 2 Singleton Pattern Memory Modelling & Sharing

Code 2 Example for Singleton memory implementation

DUT

Test sequence includes

initialization + traffic

Memory model

Protocol BFM

Backdoor Path

class slave_memory #(ADDR_WIDTH = 36,DATA_WIDTH = 128);

//declaration of assoc array for memory

bit [DATA_WIDTH-1:0] memory[*];

static slave_memory#(ADDR_WIDTH,DATA_WIDTH) single[*];

. . . . . . . . .

// method to get singleton object

static function slave_memory #(ADDR_WIDTH,DATA_WIDTH) get_instance(int

id);

if(!single.exists(id)) begin //{

// constructor that is called only once

single[id] = new;

end //}

// return the reference to already created object

return single[id]; endfunction

//This task will write the data to a memory using backdoor access.

task mem_write(bit[ADDR_WIDTH-1:0] address, bit[DATA_WIDTH-1:0] data,

bit[DATA_WIDTH-1:0] mask = 'hf);

bit[DATA_WIDTH-1:0] read_data;

if(memory.exists(address)) begin //{

mem_read(address, read_data);

end //}

memory[address] = ((data & mask) | read_data);

endtask

//This task will read the data from a memory using backdoor access

task mem_read(bit[ADDR_WIDTH-1:0] address, output bit[DATA_WIDTH-1:0]

data);

data = memory[address];

endtask

endclass : slave_memory


7

Now, lets see what goes into the user side. The steps are as follows:

Code 3 Example for Singleton memory usage

To summarize, using this pattern, one can refer to the same instance anywhere within ones environment. The examples discussed were, when one wants to collect the statistics from all the VIP components and display the same as the final report at the end of simulation, and when a single instance of memory is used across environment that is accessed for read/writes by several VIP components. Singleton applies to has_a kind of relationship. Now lets see when the class being treated as Singleton has child classes leading to is_a kind of relationship as well. To achieve the same we can make the constructor protected, so that various subclasses get to inherit the same constructor. But as a general thumb rule, Singleton and subclassing should not be mixed to keep things simpler. Disadvantages:

1. It creates an object in a given namespace, and the whole idea of namespace defies the OOPs objective to remove the clutter of namespaces

2. Having only one such global object at a particular time doesnt mean another one cant be created inadvertently in another namespace, giving you some very hard to debug issues.

3 Use of Parameterized Interface(s) in a Package

Classes are dynamic in nature while interfaces are static in nature and hence cannot be directly instantiated in a class. So, typically, a real interface instance is created in the top module (or program block) and virtual interface instances are created in various classes where there is a need to access the interface. But we need to connect the various virtual interfaces to the equivalent real interface somewhere. One of the not so elegant ways is to hierarchically pass a virtual interface instance down the layers. OVM suggests a cleaner solution to this, for OVC development. Define a virtual interface package and instantiate a virtual interface for each of the real interface(s) instantiated in the top module or program block[Refer to Figure 5]. Then in the top module or program block, import the virtual interface package and connect the packages virtual interface(s) to the corresponding real interface(s) there. In the various classes where interface access is required, define local instances of the required virtual interface(s). Then import the virtual interface package in each of these classes and connect the local virtual interface instance(s) to the corresponding ones in the imported package.

//declaring the handle of memory with parameters

axi_slave_memory #(ADDR_WIDTH,WRITE_DATA_BUS_WIDTH)mem;

//getting singleton handle to memory

mem = mem.get_instance(id);

//memory backdoor read function

mem.mem_read(address, data);

//memory backdoor write function

mem.mem_write(address, data, mask);


8

Figure 3 Parameterized Interface(s) in a package

But what if these interfaces are parameterized, how do we plan to pass parameters across packages, SV doesnt provide a provision for the same. One way to tackle this is to move the interface to config class and refer from there instead of package. But still packages provide a better global visibility. So, the other solution can be a parameterized class inside the package that contains the parameterized interface instance. Even simpler solution would be to make a package of global defines containing `defines, enums and parameters, and import this package in various other component packages where these are required to refer.

4 Harness- a Complete Sub-system definition

A typical verification setup is shown in Figure 4, wherein, various Test Bench Subsystem definitions should be able to take care of the respective interfaces defined in the DUT. An SV interface and associated Class hierarchy together define a Test bench Subsystem. OVM has a well-defined class hierarchy definition to take care of required functions, but the associated interface and its port mapping is still done in the top module (or program block) (Refer to Figure 5). This can make the top messy. Also if a user is integrating this functional entity into a test bench, he/she needs to know the interface of this functional entity in details in order to integrate. This is not what is desired, as the integrator is only interested in integrating the functional entity into rest of test bench, the details of that entitys interface are really to be known by the module owner. This can be avoided if the module owner defines a connection module for that class hierarchy in which all port mappings to the corresponding DUT interface are already taken care of, while this connection module gets simply instantiated in the top by the integrator without knowing the intricacies of that interface. This connection module along-with the related class hierarchy defines a self-sufficient functional entity and is termed a Harness (Refer to Figure 6).

Connection package (pkg)

Virtual Interface (vif)

DUT

Connection Module

TESTBENCH

Real Interface (rif)

pkg::vif = rif

Driver

Monitor

vif

vif

Global defines package

`defines enums parameters


9

Figure 4 Verification Setup Requirement

So, as shown in the above requirement setup (Refer to Figure 4), the DUT has two interfaces AXI and USB. Thus we need two TB subsystems that can drive and receive from these two interfaces. The two module owners define the OVM based class hierarchies for these two subsystems as shown below.

Figure 5 Typical Setup Todays Scenario

Now, along-with the class hierarchies, its this individual module owners responsibility to define their connection modules as well that port map to the respective DUT interface [Refer to Figure 6].

TESTBENCH SV INTERFACE

S

DUT

module top(); //USB Port Map .................. .................. .................. //AXI Port map .................. .................. .................. .................. endmodule

USB Driver

USB Sequenc

er

USB Monitor

USB Agent

AXI Driver

AXI Sequenc

er

AXI Monitor

AXI Agent

AXI

US BB

USB/AXI Class Hierarchies

DUT

TEST BENCH

AXI TB Subsystem

USB TB Subsystem

AXI

USB

DUT PORTS


10

Figure 6 Harness The Solution

Now, once the above two subsystems are ready, a third person integrating these two subsystems merely instantiates the respective agents in the environments and instantiates the connection modules in the top without understanding the interfaces of these two subsystems in details as shown below. [Refer to Figure 7][Code: 4, 5, 6, 7, 8, 9]

Code 4 DUT definition

Code 5 SVTB Interfaces definition

Code 6 Virtual Interface packages

USB Connection

Module

USB

Driver

USB

Sequencer

USB

Monitor

USB

Agent AXI

Agent

AXI

Driver

AXI

Sequencer

AXI

Monitor

AXI Connection

Module

USB Harness AXI Harness

interface axi_intf(input clk);

logic Reset;

logic [31:0] wrAddr;

logic [63:0] rdData;

endinterface

interface usb_intf (input

clk);

logic reset;

logic txready;

logic [15:0] datain;

logic [15:0] dataout;

logic txvalid;

endinterface

module Dut ( clk, reset,

//USB Intf

txready,

datain,

. . . .

dataout,

txvalid,

//AXI Intf

Reset,

wrAddr,

. . . .

rdData);

input clk;

input reset;

//USB

input txready;

input [15:0]datain;

output [15:0]dataout;

output txvalid;

//AXI

input Reset;

input [31:0] wrAddr;

output[63:0] rdData;

endmodule

package axi_vif_pkg;

virtual axi_intf axi_vif;

endpackage

package usb_vif_pkg;

virtual usb_intf usb_vif;

endpackage


11

Figure 7 Completely integrated testbench Harness Approach

Code 7 Connection module - AXI

USB Connection

Module

Top Module

Test cases

Test Environment

USB Driver

USB Sequencer

USB Monitor

USB Agent

AXI Agent

AXI Driver

AXI Sequencer

AXI Monitor

AXI Connection

Module

import axi_vif_pkg::*;

module axi_connect(input clk, reset);

//make real interface instance

axi_intf axi_rif(clk);

//port map corresponding dut signals

always @ (posedge clk) begin

axi_rif.Reset = reset;

//DUT Inputs

top.dut_inst.reset = axi_rif.Reset;

top.dut_inst.wrAddr = axi_rif. wrAddr;

//DUT Outputs

axi_rif.rdData = top.dut_inst.rdData;

end

//Map the floating Virtual Interface instance in the

package to the real interface instance

initial begin

axi_vif_pkg::axi_vif = axi_rif;

end

endmodule


12

Code 8 Connection module - USB

Code 9 Testbench Top

module top();

bit clk = 0;

bit reset = 0;

initial begin

forever clk = #TP ~clk;

end

initial begin

@ (posedge clk);

reset = 1b1;

repeat (5) @ (posedge clk);

reset = 1b0;

end

//instantiate axi connection module

axi_connect axi_connect_inst(clk, reset);

//instantiate usb connection module

usb_connect usb_connect_inst(clk, reset);

//instantiate dut

Dut dut_inst;

endmodule

import usb_vif_pkg::*;

module usb_connect(input clk, reset);

//make real interface instance

usb_intf usb_rif(clk);

//port map corresponding dut signals

always @ (posedge clk) begin

usb_rif.reset = reset;

//DUT Inputs

top.dut_inst.reset = usb_rif.reset;

top.dut_inst.txready = usb_rif.txready;

top.dut_inst.datain = usb_rif.datain;

//DUT Outputs

usb_rif.dataout = top.dut_inst.dataout;

usb_rif.txvalid = top.dut_inst.txvalid;

end

//Map the floating Virtual Interface instance in

the package to the real interface instance

initial begin

usb_vif_pkg::usb_vif = usb_rif;

end

endmodule


13

5 Sequencer Layering

OVM allows layering of the Sequences, hierarchically, to achieve any complex functionality. But the Sequencer, on which these sequences or hierarchy of sequences is started, expects a given type of ovm_sequence_item derivative, as specified in the Sequencer definition. There can be a requirement in a Verification Environment that few Sequences work on one type of ovm_sequence_item derivative and the output of these Sequences is required to be fed to another type of ovm_sequence_item derivative. Thus a translation is required in between, to convert one type of ovm_sequence_item derivative to another, before the Sequencer and Driver configured to accept second ovm_sequence_item derivative, can consume it. OVM suggested way to handle this would be to arrange these two processing logic in a hierarchical Sequence fashion, as shown below (Refer to Figure 8). But the problem here is that the Translation Sequence not only has to translate between the Trans1 and Trans2, but also has to implement complex arbitration logic to arbitrate between Sequences 1, 2 & 3.

Figure 8 Sequence layering OVM recommended way

Here we suggest an OVM reusable approach, where Sequencers Arbitration Logic can be reused in achieving the above objective [Refer to Figure 9].

Driver

Sequencer

Seq1

Seq2

Seq3

Seq6

Translation Sequence

Seq4

Indicates a conversion sequence to convert the Trans1 from Seq1,2,3 to Trans2 as required by Sequencer. Arbitration logic implemented in

sequence by user

Transaction (Trans1)


Sequencer

arbitration


14

Figure 9 Sequence Layering Using Sequencer layering

Sequences 1, 2 & 3 as well as Sequencer1 work on ovm_sequence_item derivative type Trans1. Sequencer1s internal arbitration logic (provided by OVM) is used to arbitrate between these Sequences. Now, the output of Sequencer1 needs to be fed to a Translation Sequence as shown. This Translation Sequence is started on Sequencer2 along with Sequences 4 & 5 and all these work on ovm_sequence_item derivative type Trans2. Thus the incoming transaction Trans1 need to be converted into Trans2. Once again, Sequencer2s internal arbitration logic (provided by OVM) is used to arbitrate between Sequences 4,5 & Translation Sequence The point to be noted here is that, we need a path to send the Trans 1 out of Sequencer1 and be received by Translation Sequence. The problem is, Sequences being derived from ovm_sequence and ultimately ovm_object, does not support TLM channel declarations. One way to achieve this would be to define the required TLM channels (user_req_port & user_rsp_export) in Sequencer2 with which Translation Sequence is associated already. As the Translation Sequence has a readymade m_sequencer handle from OVM to access the associated Sequencer2, Translation Sequence simply has to say m_sequencer.user_req_port.get() to get the transactions from Sequencer1. One care that needs to be taken for the response path to work in the above scenario is that the respective seq_id, transaction_id and m_sequencer/p_sequencer fields of Trans1 & Trans2 need to be separately maintained without intermixing them, so that during the translation, only user fields get translated. For this, one way is to maintain extra set of seq_id, transaction_id and

Driver

Seq1

Seq2

Seq3

Seq6

Translation Sequence

Seq4

Indicates a conversion sequence to convert the Trans1 from Sequencer1 to Trans2 as required by Sequencer2. Uses m_sequencer.user_req_port.get() to get the transaction from the Sequencer1



Sequencer2

arbitration

Sequencer2

arbitration

Sequencer2 user_req_port user_rsp_export

Sequencer1 seq_item_port

rsp_port


15

m_sequencer/p_sequencer fields in Trans2 for Trans1 so that the response received can be properly co-related to the correct sequence and transaction numbers. Another way would be to maintain a req queue in the Trans2 so that when the response is received, it can be matched wih the reqs in the local queue and then co-related to the correct sequence and transaction numbers.

6 Single Class / Multiple Analysis ports

In a typical Scoreboard, we are required to connect two or more monitors. In OVM, this is done using analysis imports. Now, the Scoreboard will require to provide the write() function implementation for every analysis import instantiated. But a class cannot have two or more functions with same signature. This can be resolved by using an analysis FIFO after the analysis import so that the write() function implementation is provided by the analysis FIFO instance as shown below. (Refer to Figure 10) (Code 10, 11, 12)

Figure 10 Analysis FIFO connection model monitor & score-board

But, at times there is a requirement to provide a write() function implementation by the user, customized to take care of some project requirements. Thus we need a solution to have multiple write() functions defined in the same Scoreboard class. OVM provides a macro to do this, known as `ovm_analysis_imp_decl(). User passes a string name to the macro that he/she wishes to have appended. This basically provides:

1. An import class with a ovm_analysis_imp as its signature 2. It also provides a signature to a write function with write () as its name.

User simply instantiates above import and connects to the respective monitor. Also, user codes the above function that gets called whenever the connected monitor writes to its analysis port. This function is coded by user as per his/her project requirements. Note that though monitor simply calls its port.write() function, in turn the connected subscribers import.write() function gets called automatically.

SCOREBOARD

Write Monitor

Read Monitor

Score-boarding

Logic

write()

write()

fifo.get()

fifo.get()

tlm_analysis_fifo

ovm_analysis_port

ovm_analysis_export

fifo.analysis_export


16

Code 10 Monitors to be connected to score-board

Code 11 Agent code showing monitor & scoreboard connection

class MyReadMonitor extends

ovm_monitor;

ovm_analysis_port #(MyTrans1) ap;

task run();

MyTrans1 Tr;

//Monitor logic

----

----

ap.write(Tr);

endtask

endclass: MyReadMonitor

class MyWriteMonitor extends

ovm_monitor;

ovm_analysis_port #(MyTrans1) ap;

task run();

MyTrans1 Tr;

//Monitor logic

----

----

ap.write(Tr);

endtask

endclass: MyWriteMonitor

class MyAgent extends ovm_agent;

MyWriteMonitor wrMon;

MyReadMonitor rdMon;

MyScoreboard scbd;

function void connect();

wrMon.ap.connect(scbd.userWrData_imp);

rdMon.ap.connect(scbd.userRdData_imp);

endfunction

endclass: MyAgent


17

Code 12 Score-board showing implementation

`ovm_analysis_imp_decl(_UserWrData)

`ovm_analysis_imp_decl(_UserRdData)

class MyScoreboard extends ovm_scoreboard;

ovm_analysis_imp_UserWrData #(MyTrans1, MyScoreboard) userWrData_imp;

ovm_analysis_imp_UserRdData #(MyTrans1, MyScoreboard) userRdData_imp;

MyTrans2 WrTransQue[$];

MyTrans2 RdTransQue[$];

function void write_UserWrData (MyTrans1 uWrTrans);

MyTrans2 WrTrans2;

//Convert uWrTrans to WrTrans2

------

------

WrTransQue.push_back(WrTrans2);

endfunction : write_UserWrData

function void write_UserRdData (MyTrans1 uRdTrans);

MyTrans2 RdTrans2;

//Convert uRdTrans to RdTrans2

------

------

RdTransQue.push_back(RdTrans2);

endfunction : write_UserRdData

task void run ();

MyTrans2 WrTrans2;

MyTrans2 RdTrans2;

fork

begin

forever begin

if(WrTransQue.size() > 0) begin

WrTrans2 = WrTransQue.pop_front();

//Process Write Trans

------

------

end

end

end

begin

forever begin

if(RdTransQue.size() > 0) begin

RdTrans2 = RdTransQue.pop_front();

//Process Read Trans

------

------

end

end

end

endtask : run

endclass: MyScoreboard


18

7 SV world to C world - Host Communication

In case of SOC projects, often there is a need to communicate across from SV World to C World and back, to accomplish a particular test scenario. Now, in case of Module Level Verification Environments, where embedded host processor is typically absent, SV to C communication and back can simply be SV DPI Calls. But when embedded host processor is in place at Chip Level Verification Environment, shared memory is one way to achieve the communication between the SV and C Worlds. Typically, we randomize the control parameters in the SV World as per the constraints specified in the test-case/sequence/transfer class, but the programming of DUT registers for DUT initialization has to be performed by the embedded processor only, as per the real world SOC requirement. The idea here is to reuse the C code written at Module Level Verification into the Chip Level Verification. Thus there is a need to send across the randomized set of data from SV World to the C World. Once the C program executes on the embedded processor (or through DPI call at Module Level) and utilizes the data that came from SV World, it now has some programming sequence data ready to program the DUT registers. But to actually perform this programming, this data has to be brought back from the C World to the SV World where some SV module can drive the DUT Register Programming interface using the data received from the C World. To accomplish the above communication, reusable verification blocks can be defined to be used across various project modules. One of the proposed definitions of these blocks is that we define a Host Adapter block and a Host Requester block. [Refer to figure 11] There will be a Singleton instance of Host Adapter in a project at any given time. Every SV Module that wishes to send data to the C World first extends the host requester block for customizing the data to be sent across as per that modules requirement and then connects to the singleton Host Adapter instance using a host requester channel (TLM Channel). A generic data structure can be defined that is interpreted by any Host Requester and Host Adapter. This data structure can contain following fields: block_id, task_id, data[], control[]. The contents of data [] and control[] can be customized by the individual modules as per their requirement. Every Module Level Verification Environment provides a C file containing the tasks required to execute to achieve that Modules DUT Register Programming. Also, in that file, it provides a host task table consisting of entries of task string name and corresponding function pointer. When a Host Requester sends a request in the form of a structure defined above, to the Host Adapter, it gets stored in the Adapters in-built Queue (FIFO). The various barriers defined in Adapter like the init_barrier, run_barrier, check_barrier etc pops out the request from Queue one-by-one at the appropriate barrier timing and calls the Host Adapter Generic C function process requests() for handling the requests. In case of Module Level Verification Environment, as discussed before, this will be purely a DPI-C call. In case of Chip Level Verification Environment, this will be through a shared memory so that the Adapter Generic C function(s) running on embedded host processor can pick up the request through shared memory and execute it.[ Refer to figure 12] This Generic C function looks at the block_id from the request and figures out which host task table to look into. Then it uses the task_id in the form of a string from the request to lookup for this function in this table. Once it finds it, it simply calls the mapping function pointer in the found entry


19

with the data [] and control[] as arguments else flags a fatal error. This User C function called by the Generic C function may result in a call, back to SV World. Again in case of Module Level Verification Environment, this will simply be a DPI SV call to the SV Adapter exported function(s). In case of Chip Level Verification Environment, this will be through a shared memory so that some Adapter SV process waiting for the C side to setup data in shared memory gets kicked off seeing the data there and then executes the associated tasks in the DUT Register Programming module in the SV domain to get the appropriate DUT Registers programmed. In a similar fashion, interrupts handling can be taken care of in the Module Level Verification Environments where actual host processor is missing, so the ISR routine gets called through the DPI C calls. At Chip Level, there will be actual processor to handle the interrupts anyways.

Figure 11 Host Communication module-level setup

Host Requester

Host Adaptor

Host Master Agent

Host Sequence

Block C Routines

Block Test bench

Block Environment

Host Requestor Channel

Host Environment

DPI


20

Figure 12 Host communication module/SoC setup

To be continued..........

PCIe

SATA

USB

PCIe Host Requestor

SATA Host Requestor

USB Host Requestor

PCIe user C functions & func table

SATA user C functions & func table

USB user C functions & func table

Host Adaptor Generic C code

Singleton Host Adaptor

DUT Programming

Interface/Module

DUT

Host Requestor

Channel

DPI/Shared Memory

communication

IntroductionOOPs Design Patterns (Singleton Instantiating One Object)Use of Parameterized Interface(s) in a PackageHarness- a Complete Sub-system definitionSequencer LayeringSingle Class / Multiple Analysis portsSV world to C world - Host Communication

Documents

Sv Ovm Paper Part1