UVM方法学实战指南：官方资料解析

5星 · 超过95%的资源需积分: 5 88 浏览量更新于2024-07-15 3 收藏 9.33MB PDF 举报

"uvm_cookbook2019 mentor 官方资料，涵盖了UVM的基础知识、组件、工厂、时相、驱动、监控器、代理、序列、配置数据库、包的使用、测试平台架构等内容，深入浅出地指导了如何构建和配置UVM验证环境。" 《UVM Cookbook》是Mentor Graphics官方发布的一份详细指南，主要针对Universal Verification Methodology（UVM）这一广泛使用的系统Verilog验证方法学。这份文档旨在帮助工程师理解和应用UVM进行集成电路验证。 1. **UVMBasics**：这部分介绍了UVM的基本概念，包括测试平台的基本结构，强调了UVM作为可复用和可配置的验证组件库的重要性。它还涵盖了如何利用UVM来建立高效的验证环境。 2. **UVMComponents**：UVM组件是构成UVM测试平台的核心元素，包括Factory（工厂）、Phasing（时相）、Driver（驱动）、Monitor（监控器）、Agent（代理）等。Factory用于动态创建和实例化组件；Phasing允许在不同阶段执行组件的不同任务；Driver负责与DUT（设计单元）交互；Monitor则监控DUT的行为；Agent是Driver和Monitor的组合，提供了一个完整的数据通路。 3. **UVMSequences & SequenceItems**：UVMSequences用于生成激励并驱动测试，而SequenceItems则是这些激励的基本单元。它们可以被用来创建复杂和随机化的测试序列。 4. **UVMConfigurationDatabase(uvm_config_db)**：配置数据库允许在运行时传递参数和对象到任何层次的UVM组件，增强了可配置性和灵活性。 5. **UsingPackages**：UVM基于包的组织结构，了解如何正确使用和组织包对于有效管理UVM组件至关重要。 6. **TestbenchArchitecture**：这部分详细讲解了如何构建UVM测试平台的架构，包括Block-Level和Integration-Level的测试平台，以及Dual Top Architecture的设计。 7. **DUT-TestbenchConnections**：连接DUT和测试平台是验证的关键步骤，涉及接口和虚拟接口的使用，以及如何通过虚拟接口行为模型（BFMs）进行通信。 8. **HandlingParameterization**：参数化在UVM中用于根据不同的设计需求定制组件，抽象-具体类的连接和参数化测试是实现这一目标的手段。 9. **ConfiguringaTestEnvironment**：配置测试环境包括设置测试平台的配置参数，以及如何配置Sequences以适应特定的验证场景。 10. **TestbenchConfiguration & ConfiguringSequences**：这部分详细说明了如何通过UVM配置数据库来配置测试平台和序列，以实现更高效和精确的验证流程。《UVM Cookbook 2019》是一份全面的参考资料，不仅适合初学者学习UVM的基础知识，也对有经验的验证工程师具有很高的参考价值，帮助他们更有效地构建和管理复杂的SoC验证环境。

The UVM Factory

Factory Coding Convention 2: Constructor Defaults

The uvm_component and uvm_object constructors are virtual methods with a prototype template that must be

adhered to by users. In order to support deferred construction during the build phase, the factory constructor should

contain defaults for the constructor arguments. This allows a factory registered class to be built inside the factory

using the defaults and then the class properties can be re-assigned to the arguments passed via the create method of

the uvm_component_registry wrapper class. The defaults are different for components and objects:

Factory Coding Convention 3: Component and Object Creation

Testbench components are created during the build phase using the create method of the uvm_component_registry.

This first constructs the class, then assigns the handle to the class to its declaration handle in the testbench after the

name and parent arguments are assigned correctly. For components the build process is top-down, which allows

higher level components and configurations to control what actually gets built.

Object classes are created as required, again using the create method. The following code snippet illustrates how this

is done:

// For a component:

class my_component extends uvm_component;

function new(string name = "my_component", uvm_component parent = null);

super.new(name, parent);

endfunction

// For an object:

class my_item extends uvm_sequence_item;

function new(string name = "my_item");

super.new(name);

endfunction

class env extends uvm_env;

my_component m_my_component;

my_param_component #(.ADDR_WIDTH(32), .DATA_WIDTH(32)) m_my_p_component;

// Constructor & registration macro left out

// Component and parameterized component create examples

function void build_phase( uvm_phase phase );

m_my_component = my_component::type_id::create("m_my_component", this);

m_my_p_component = my_param_component #(32, 32)::type_id::create

("m_my_p_component", this);

endfunction: build

task run_phase( uvm_phase phase );

my_seq test_seq;

Phasing

Starting UVM Phase Execution

To start a UVM testbench, the run_test() method has to be called from the static part of the testbench. It is usually

called from within an initial block in the top level module of the testbench.

Calling run_test() constructs the UVM environment root component and then initiates the UVM phasing. The

run_test() method can be passed a string argument to define the default type name of an uvm_component derived

class which is used as the root node of the testbench hierarchy. However, the run_test() method checks for a

command line plusarg called UVM_TESTNAME and uses that plusarg string to lookup a factory registered

uvm_component, overriding any default type name. By convention, the root node will be derived from a uvm_test

component, but it can be derived from any uvm_component. The root node defines the test case to be executed by

specifying the configuration of the testbench components and the stimulus to be executed by them.

For instance, in order to specify the test component 'my_test' as the UVM testbench root class, the Questa command

line would be:

vsim tb_top +UVM_TESTNAME=my_test

Phase Descriptions

The following section describes the purpose of each of the different UVM phases

Build Phases

The build phases are executed at the start of the UVM testbench simulation and their overall purpose is to construct,

configure and connect the testbench component hierarchy.

All the build phase methods are functions and therefore execute in zero simulation time.

build

Once the UVM testbench root node component is constructed, the build phase starts to execute. It constructs the

testbench component hierarchy from the top downwards. The construction of each component is deferred so that

each layer in the component hierarchy can be configured by the level above. During the build phase

uvm_components are indirectly constructed using the UVM factory.

connect

The connect phase is used to make TLM connections between components or to assign handles to testbench

resources. It has to occur after the build method has put the testbench component hierarchy in place and works from

the bottom of the hierarchy upwards.

end_of_elaboration

The end_of_elaboration phase is used to make any final adjustments to the structure, configuration or connectivity of

the testbench before simulation starts. Its implementation can assume that the testbench component hierarchy and

inter-connectivity is in place. This phase executes bottom up.

Run Time Phases

The testbench stimulus is generated and executed during the run time phases which follow the build phases. After the

start_of_simulation phase, the UVM executes the run phase and the phases pre_reset through to post_shutdown in

parallel. The run phase was present in the OVM and is preserved to allow OVM components to be easily migrated to

the UVM. It is also the phase that transactors will use. The other phases were added to the UVM to give finer run-

time phase granularity for tests, scoreboards and other similar components. It is expected that most testbenches will

only use reset, configure, main and shutdown and not their pre and post variants

Phasing

start_of_simulation

The start_of_simulation phase is a function which occurs before the time consuming part of the testbench begins. It

is intended to be used for displaying banners; testbench topology; or configuration information. It is called in bottom

up order.

run

The run phase occurs after the start_of_simulation phase and is used for the stimulus generation and checking

activities of the testbench. The run phase is implemented as a task, and all uvm_component run_phase() tasks are

executed in parallel. Transactors such as drivers and monitors will nearly always use this phase.

Parallel Run-Time Phases

NOTE: The following run-time phases execute in-order, in parallel with the run_phase phase. These phases should

only be called from the test and the env to start sequences. Drivers, monitors and other components should not

implement these phases.

pre_reset

The pre_reset phase starts at the same time as the run phase. Its purpose is to take care of any activity that should

occur before reset, such as waiting for a power-good signal to go active. We do not anticipate much use for this

phase.

reset

The reset phase is reserved for DUT or interface specific reset behavior. For example, this phase would be used to

generate a reset and to put an interface into its default state.

post_reset

The post_reset phase is intended for any activity required immediately following reset. This might include training or

rate negotiation behaviour. We do not anticipate much use for this phase.

pre_configure

The pre_configure phase is intended for anything that is required to prepare for the DUT's configuration process after

reset is completed, such as waiting for components (e.g. drivers) required for configuration to complete training

and/or rate negotiation. It may also be used as a last chance to modify the information described by the

test/environment to be uploaded to the DUT. We do not anticipate much use for this phase.

configure

The configure phase is used to program the DUT and any memories in the testbench so that it is ready for the start of

the test case. It can also be used to set signals to a state ready for the test case start.

post_configure

The post_configure phase is used to wait for the effects of configuration to propagate through the DUT, or for it to

reach a state where it is ready to start the main test stimulus. We do not anticipate much use for this phase.

pre_main

The pre_main phase is used to ensure that all required components are ready to start generating stimulus. We do not

anticipate much use for this phase.

Phasing

main

This is where the stimulus specified by the test case is generated and applied to the DUT. It completes when either

all stimulus is exhausted or a timeout occurs. Most data throughput will be handled by sequences started in this

phase.

post_main

This phase is used to take care of any finalization of the main phase. We do not anticipate much use for this phase.

pre_shutdown

This phase is a buffer for any DUT stimulus that needs to take place before the shutdown phase. We do not

anticipate much use for this phase.

shutdown

The shutdown phase is used to ensure that the effects of the stimulus generated during the main phase have

propagated through the DUT and that any resultant data has drained away. It might also be used to execute time

consuming sequences that read status registers.

post_shutdown

Perform any final activities before exiting the active simulation phases. At the end of the post_shutdown phase, the

UVM testbench execution process starts the clean up phases. We do not anticipate much use for this phase ( with the

possible exception of some object-to-one code ).

Clean Up Phases

The clean up phases are used to extract information from scoreboards and functional coverage monitors to determine

whether the test case has passed and/or reached its coverage goals. The clean up phases are implemented as functions

and therefore take zero time to execute. They work from the bottom to the top of the component hierarchy.

extract

The extract phase is used to retrieve and process information from scoreboards and functional coverage monitors.

This may include the calculation of statistical information used by the report phase. This phase is usually used by

analysis components.

check

The check phase is used to check that the DUT behaved correctly and to identify any errors that may have occurred

during the execution of the testbench. This phase is usually used by analysis components.

report

The report phase is used to display the results of the simulation or to write the results to file. This phase is usually

used by analysis components.

final

The final phase is used to complete any other outstanding actions that the testbench has not already completed.

剩余546页未读，继续阅读

斐非韭

粉丝: 5993
资源: 2

UVM方法学实战指南：官方资料解析

UVM_Cookbook

uvm cookbook

UVM cookbook 2013 自制详细书签版+练习代码，UVM查询手册.zip

UVM-IEEE Std.1800.2™-2017：FPGA IC验证最新指南

uvm-1.1a.tar.gz

UVM-Info的结构

从UVM-3A紫外线传感器读取数据的程序

centos 安装uvm

使用uvm平台需要加入uvm库文件吗

uvm的top.sv中为什么有了uvm_pkg::*还要写svt_uvm_pkg::*

最新资源

uvm的top.sv中为什么有了uvm_pkg::还要写svt_uvm_pkg::