birdhit detection using ovm

Verification Academy

http://verificationacademy.com

Cookbook

Online Methodology Documentation from the

Mentor Graphics Verification Methodology Team

Contact [email protected]

Table of ContentsArticles

Ovm/Testbench/Build 1

Datestamp:- This document is a snapshot of dynamic content from the Online Methodology Cookbook

- Created from http://verificationacademy.com/uvm-ovm on Tue, 08 Jan 2013 06:48:12 UTC


UVM/OVM Documentation - Copyright (c) 2012 Mentor Graphics Corporation - http://verificationacademy.com/uvm-ovm

Ovm/Testbench/BuildThe first phase of an OVMtestbench is thebuild phase. During this phase theovm_component classes that make up thetestbench hierarchy are constructed intoobjects. The construction process workstop-downwith each level of the hierarchybeing constructed before the next level isconfigured and constructed. This approach toconstruction is referred to as deferredconstruction.

The OVM testbench is is activated when therun_test() method is called inan initial blockin the top level test module. This method is anOVM static method, and it takes a stringargument or a string passed in from the+OVM_TESTNAME plusarg that defines the test to be run and constructs it via the factory. The +OVM_TESTNAMEtakes precedence over a string argument passed into run_test(). Then the OVM infrastructure starts the build phase bycalling the test classes build methodDuring the execution of the tests build phase, the testbench component configuration objects are prepared andassignments to the testbench module interfaces are made to the virtual interface handles in the configuration objects. Thenext step is for the configuration objects to be put into the testsconfiguration table. Finallythe next level of hierarchy isbuilt.At the nextlevel of hierarchy the configuration object prepared by the test is "got"andfurtherconfiguration may takeplace,before the configuration object is used to guidethe configuration and conditional construction of the next level ofhierarchy. This conditional construction affects the topology or hierarchical structure of the testbench.The build phase works top-down and so the processis repeated for theeach successivelevel of the testbench hiearchyuntil the bottom of the hierarchical tree is reached.After the build phase has completed, the connect phase is used to ensure that all intra-component connections are made.The connect phase works from the bottom to the top of the testbench hierarchy. Following the connect phase, the rest ofthe OVMphases run to completion before control is passed back to the testbench module.



The Test Is The Starting Point For The Build ProcessThe build process for an OVMtestbench starts from the test class and works top-down.The test class build method is thefirst to be called during the build phase and what the test method sets updetermines what gets built in an OVMtestbench.The function of thetests build method is to: Set up any factory overrides so that configuration objects or component objects are created as derived types Create and configure the configuration objects required by the various sub-components Assign any virtual interface handlesput into configuration space by the testbench module Buildup a nested env configuration object which is then set into configuration space Build the next level down in the testbench hierarchy, usually the top-level envFor a given design verification environment most of the work done in the build method will be the same for all the tests,so it is recommended that a test base class is created which can be easily extended for each of the test cases.To help explain how the test build process works, a block level verification environment will be referred to. Thisexample is an environment for an SPImaster interface DUT and it contains two agents, one for its APBbus interface andone for its SPI interface. A detailed account of the build and connect processes for this example can be found in theBlock Level Testbench Examplearticle.

Factory Overrides

The OVMfactory allows an OVMclassto be substituted with another derivedclass at the point of construction.Thisfacility can be useful forchangingor updatingcomponentbehaviour or for extending aconfiguration object. The factoryoverride must be specified beforethetarget object is constructed, so it isconvenientto do itat the start ofthebuild process.

Sub-Component ConfigurationObjects

Each collective component such as an agent or an env should have a configuration object which defines their structureand behaviour. These configuration objects should be created in the test build method and configured according to therequirements of the test case. If the configuration of the sub-component is either complex or is likely to change then it isworth adding a function call to take care of the configuration, since this can be overloaded in test cases extending fromthe base test class.

`ifndef SPI_TEST_BASE

`define SPI_TEST_BASE

//

// Class Description:



//

//

class spi_test_base extends ovm_test;

// OVM Factory Registration Macro

//

`ovm_component_utils(spi_test_base)

//------------------------------------------

// Data Members

//------------------------------------------

//------------------------------------------

// Component Members

//------------------------------------------

// The environment class

spi_env m_env;

// Configuration objects

spi_env_config m_env_cfg;

apb_agent_config m_apb_cfg;

spi_agent_config m_spi_cfg;

//------------------------------------------

// Methods

//------------------------------------------

// Standard OVM Methods:

extern function new(string name = "spi_test_base", ovm_component parent = null);

extern function void build();

extern funciton void configure_env(spi_env_config cfg);

extern funciton void configure_apb_agent(apb_agent_config cfg);

endclass: spi_test_base

function spi_test_base::new(string name = "spi_test_base", ovm_component parent = null);

super.new(name, parent);

endfunction

// Build the env, create the env configuration

// including any sub configurations and assigning virtural interfaces

function void spi_test_base::build();

// Create env configuration object

m_env_cfg = spi_env_config::type_id::create("m_env_cfg");

// Call function to configure the env



configure_env(m_env_cfg);

// Create apb agent configuration object

m_apb_cfg = apb_agent_config::type_id::create("m_apb_cfg");

// Call function to configure the apb_agent

configure_apb_agent(m_apb_cfg);

// More to follow

endfunction: build

//

// Convenience function to configure the env

//

// This can be overloaded by extensions to this base class

function void spi_test_base::configure_env(spi_env_config cfg);

cfg.has_functional_coverage = 1;

cfg.has_reg_scoreboard = 0;

cfg.has_spi_scoreboard = 1;

endfunction: configure_apb_agent

//

// Convenience function to configure the apb agent

//

// This can be overloaded by extensions to this base class

function void spi_test_base::configure_apb_agent(apb_agent_config cfg);

cfg.active = OVM_ACTIVE;

cfg.has_functional_coverage = 0;

cfg.has_scoreboard = 0;

endfunction: configure_apb_agent

`endif // SPI_TEST_BASE

Assigning Virtual Interfaces From The Configuration SpaceBefore the OVM run_test() method is called, the links to the signals on the top level I/O boundary of the DUT shouldhave been made by connecting them to SystemVerilog interfaces and then ahandle to each interface should have beenassigned to a virtual interface handle which was wrapped inside a virtual interface container object. See the article onvirtual interfaces for more information on this topic.In the test build method, these virtual interface references need to be assigned to the virtual interface handles inside therelevant component configuration objects. Then, individual components access the virtual interface handle inside theirconfiguration object in order to drive or monitor DUT signals. In order to keep components modular and reusable driversand monitors should not get their virtual interface pointers directly from configuration space, only from theirconfiguration object. The test class is the correct place to ensure that the virtual interfaces are assigned to the rightverification components via their configuration objects.The following code shows how the the SPI testbench example uses the ovm_container to make virtual interfaceassignments to the virtual interface handle in the apb_agents configuration object:



// The build method from before, adding the apb agent virtual interface assignment












// Adding the apb virtual interface:

m_apb_cfg.APB = ovm_container #(virtual apb_if)::get_value_from_config(this, "APB_vif");

// More to follow

endfunction: build

Nesting Sub-Component Configuration ObjectsConfiguration objects are passed to sub-components via the OVM component configuration space from the test. Theycan be passed individually, using the path argument in the set_config_object() method to control which components canaccess the objects, however a common requirement is that intermediate components also need to do some localconfiguration.Therefore, an effective way to approach the passing of configuration objects through a testbench hierarchy is to nest theconfiguration objects inside each other in a way that reflects the hierarchy itself. At each intermediate level in thetestbench, the configuration object for that level is unpacked and then its sub-configuration objects are re-configured (ifnecessary) and then passed to the relevant components using set_config_object().Following the SPIblock level envrionment example, each of the agents will have a separate configuration object. Theenvs configuration object will have a handle for each of the agents configuration object. In the test, all of theconfiguration objects will be constructed and configured from the test case viewpoint, then the agent configuration objecthandles inside the env configuration object will be assigned to the actual agent configuration objects. Then the envconfiguration object would be set into the configuration space, to be retrieved when the env is built.For more complex environments,additional levels of nesting will berequired.



//

// Configuration object for the spi_env:

//

ìfndef SPI_ENV_CONFIG

`define SPI_ENV_CONFIG

//

// Class Description:

//

//

class spi_env_config extends ovm_object;

// OVM Factory Registration Macro

//

òvm_object_utils(spi_env_config)

//------------------------------------------

// Data Members

//------------------------------------------

// Whether env analysis components are used:

bit has_functional_coverage = 1;

bit has_reg_scoreboard = 0;

bit has_spi_scoreboard = 1;

// Configurations for the sub_components

apb_config m_apb_agent_cfg;

spi_agent_config m_spi_agent_cfg;

//------------------------------------------

// Methods

//------------------------------------------

// Standard OVM Methods:

extern function new(string name = "spi_env_config");

endclass: spi_env_config

function spi_env_config::new(string name = "spi_env_config");

super.new(name);

endfunction

èndif // SPI_ENV_CONFIG



//

// Inside the spi_test_base class, the agent config handles are assigned:

//

// The build method from before, adding the apb agent virtual interface assignment












// Adding the apb virtual interface:

m_apb_cfg.APB = ovm_container #(virtual apb_if)::get_value_from_config(this, "APB_vif");

// Assign the apb_angent config handle inside the env_config:

m_env_cfg.m_apb_agent_cfg = m_apb_cfg;

// Repeated for the spi configuration object

m_spi_cfg = spi_agent_config::type_id::create("m_spicfg");

configure_spi_agent(m_spi_cfg);

m_spi_cfg.SPI = ovm_container #(virtual spi_if)::get_value_from_config(this, "SPIvif");

m_env_cfg.m_spi_agent_cfg = m_spi_cfg;

// Now env config is complete set it into config space:

set_config_object("*", "spi_env_config", m_env_cfg, 0);

// Now we are ready to build the spi_env:

m_env = spi_env::type_id::create("m_env", this);

endfunction: build



Building The Next Level Of HierarchyThe final stage of the test build process is to build the next level of testbench hierarchy using the OVM factory. Thisusually means building the top level env, but there could be more than one env or there could be a conditional build witha choice being made between several envs.

Coding Convention - Name ArgumentFor Factory Create Method ShouldMatch Local Handle

The create method takes two arguments,one is a name string and the other ispointer to the parent ovm_componentclass object. The values of thesearguments are used to create an entry ina linked list which the OVM uses tolocate ovm_components in a pusedohierarchy, this list is used in themessaging and configurationmechanisms. By convention, the nameargument string should be the same asthe declaration handle of the componentand the parent argument should be "this"so that it refers to the ovm_component inwhich the component is being created.Using the same name as the handle makes it easier to cross reference paths and handles. In the previous code snippet, thespi_env is created in the test using its declaration handle m_env. This means that, after the end of the build process, theOVM path to the spi_env would be "spi_test.m_env".

Hierarchical Build ProcessThe build phase in the OVM works top down. Once the test class has been constructed, its build method is called, andthen the build method of its child(ren) is called. In turn, the build methods of each of the child nodes through thetestbench tree are called until the whole hierarchy has been constructed. This deferred approach to construction meansthat each build method can affect what happens in the build process of components at lower levels in the testbenchhierarchy. For instance, if an agent is configured to be passive, the build process for the agent omits the creation of theagents sequencer and driver since these are only required if the agent is active.



The Hierarchical ConnectionProcess

Once the build phase has completed, theOVM testbench component hierarchy isin place and the individual componentshave been constructed and linked intothe component hierarchy linked list. Theconnect phase follows the build phase,and works from the bottom of thehierarchy tree to the top and its purposeis to make connections between TLMclasses, assign virtual interface pointersto their handles and to make any otherassignments to resources such as virtualsequencer sub-sequencers.Configuration objects are used duringthe connection process since they makecontain references to virtual interfaces orthey may contain information that guidesthe connection process. For instance,inside an agent, the virtual interfaceassignment to a driver and the TLM connection between a driver and its sequencer can only be made if the agent isactive.

ExamplesThe build process is best illustrated by looking at some examples to illustrate how different types of component hierarchyare built up:A block level testbench containing an agentAn integration level testbench

2012-13 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and

may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.

In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks

mentioned are this document are trademarks of their respective owners.

For the latest product information, call us or visit: w w w . m e n t o r . c o m

Verification Academy Cookbook

Corporate Headquarters

Mentor Graphics Corporation

8005 SW Boeckman Road

Wilsonville, OR 97070-7777

Phone: 503.685.7000

Fax: 503.685.1204

Sales and Product Information

Phone: 800.547.3000

Silicon Valley

Mentor Graphics Corporation

46871 Bayside Parkway

Fremont, California 94538 USA

Phone: 510.354.7400

Fax: 510.354.1501

North American Support Center

Phone: 800.547.4303

Europe

Mentor Graphics

Deutschland GmbH

Arnulfstrasse 201

80634 Munich

Germany

Phone: +49.89.57096.0

Fax: +49.89.57096.400

Pacific Rim

Mentor Graphics (Taiwan)

Room 1001, 10F

International Trade Building

No. 333, Section 1, Keelung Road

Taipei, Taiwan, ROC

Phone: 886.2.87252000

Fax: 886.2.27576027

Japan

Mentor Graphics Japan Co., Ltd.

Gotenyama Garden

7-35, Kita-Shinagawa 4-chome

Shinagawa-Ku, Tokyo 140-0001

Japan

Phone: +81.3.5488.3030

Fax: +81.3.5488.3021

birdhit detection using ovm

Documents

test method

build phase bycalling

test classes

ovm testbench

level test module

phase theovm

thebuild phase

build processthe