OVM 2.1.1 Kit验证方法详解

ovm2.1.1

验证方法学

需积分: 9 189 浏览量更新于2024-08-01 收藏 1MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

OVM (Open Virtual Machine) 是一个开放源代码的硬件模拟器，专用于虚拟硬件验证。OVM 2.1.1 Kit 提供了一套完整的验证方法学，它在 March 2010 的版本中被更新和发布，由 Cadence Design Systems 和 Mentor Graphics 共同维护和支持。这个工具集遵循 Apache Software Foundation 的 Apache License, Version 2.0，这是一种开源许可协议，强调了软件的可自由分发和修改。 OVM 2.1.1 Kit 验证方法学的核心在于其用户指南（OVMUserGuide），该指南详细阐述了如何设计、配置和执行虚拟机模型，以确保硬件设计的正确性和一致性。验证过程通常包括以下几个关键步骤： 1. **模型设计**：OVM 通过抽象层次结构来构建虚拟硬件模型，允许开发者模拟处理器、内存、I/O 设备等组件的行为。设计者需要了解目标架构的细节，以便准确地模拟实际硬件行为。 2. **测试脚本编写**：使用 OVM 的 API 或者高级语言（如 SystemVerilog）编写测试脚本，定义测试用例，检查虚拟机在各种输入条件下的行为是否符合预期。 3. **仿真环境搭建**：设置合适的仿真环境，包括配置运行时参数、连接到物理或虚拟硬件等，确保模拟与实际硬件环境尽可能一致。 4. **执行和监控**：运行测试脚本，监控虚拟机的行为，记录和分析结果，发现并修复潜在的设计错误或不一致。 5. **回归测试**：随着设计迭代，定期执行回归测试以确保新添加或修改的部分不会引入新的问题，保持整个系统的稳定性。 6. **文档和报告**：生成详细的测试报告，记录测试过程、结果以及任何遇到的问题，这有助于团队协作和持续改进。 7. **许可证遵从性**：在使用和分发 OVM 时，必须遵守 Apache License 的条款，确保版权权益的尊重，并避免未经授权的修改。 OVM 2.1.1 Kit 的验证方法学是一个系统性的过程，它利用 OVM 的灵活性和功能，为硬件验证提供了强大且灵活的工具，帮助设计者确保其产品在虚拟环境中表现出稳定的性能和功能一致性。

资源详情

资源推荐

OVM User Guide

OVM Overview

March 2010 16 Product Version 2.1.1

Figure 1-3 (Partial) OVM Class Hierarchy

The advantages of using the SystemVerilog OVM Class Library include:

■ A robust set of built-in features—The SystemVerilog OVM Class Library provides many

features that are required for verification, including complete implementation of printing,

copying, test phases, factory methods, and more.

■ Correctly-implemented OVM concepts—Each component in the block diagram in

Figure 1-2

on page 15 is derived from a corresponding SystemVerilog OVM Class

Library component. Figure 1-4 on page 17 shows the same diagram using the derived

SystemVerilog OVM Class Library base classes. Using these base-class elements

increases the readability of your code since each component’s role is predetermined by

its parent class.

OVM User Guide

OVM Overview

March 2010 18 Product Version 2.1.1

OVM Factory

The factory method is a classic software design pattern that is used to create generic code,

deferring to run time the exact specification of the object that will be created. In functional

verification, introducing class variations is frequently needed. For example, in many tests you

might want to derive from the generic data item definition and add more constraints or fields

to it; or you might want to use the new derived class in the entire environment or only in a

single interface; or perhaps you must modify the way data is sent to the DUT by deriving a

new driver. The factory allows you to substitute the verification component without having to

provide a derived version of the parent component as well.

The SystemVerilog OVM Class Library provides a built-in central factory that allows:

■ Controlling object allocation in the entire environment or for specific objects.

■ Modifying stimulus data items as well as infrastructure components (for example, a

driver).

Use of the OVM built-in factory reduces the effort of creating an advanced factory or

implementing factory methods in class definitions. It facilitates reuse and adjustment of

predefined verification IP in the end-user’s environment. One of the biggest advantages of the

factory is that it is transparent to the test writer and reduces the object-oriented expertise

required from both developers and users.

Transaction-Level Modeling

OVM components communicate via standard TLM interfaces, which improves reuse. Using a

SystemVerilog implementation of TLM in OVM, a component may communicate via its

interface to any other component that implements that interface. Each TLM interface consists

of one or more methods used to transport data. TLM specifies the required behavior

(semantic) of each method but does not define their implementation. Classes inheriting a

TLM interface must provide an implementation that meets the specified semantic. Thus, one

component may be connected at the transaction level to others that are implemented at

multiple levels of abstraction. The common semantics of TLM communication permit

components to be swapped in and out without affecting the rest of the environment.

OVM User Guide

March 2010 19 Product Version 2.1.1

Transaction-Level Modeling (TLM)

Transaction-Level Modeling Overview

One of the keys to verification productivity is to think about the problem at a level of

abstraction that makes sense. When verifying a device under test (DUT) that handles packets

flowing back and forth, or processes instructions, or performs other types of functionality, you

must create a verification environment that supports the appropriate abstraction level. While

the actual interface to the DUT ultimately is represented by signal-level activity, experience

has shown that it is necessary to manage most of the verification tasks, such as generating

stimulus and collecting coverage data, at the transaction level, which is the natural way

engineers tend to think of the activity of a system.

OVM provides a set of transaction-level communication interfaces and channels that you can

use to connect components at the transaction level. The use of TLM interfaces isolates each

component from changes in other components throughout the environment. When coupled

with the phased, flexible build infrastructure in OVM, TLM promotes reuse by allowing any

component to be swapped for another, as long as they have the same interfaces. This

concept also allows OVM verification environments to be assembled with a transaction-level

model of the DUT, and the environment to be reused as the design is refined to RTL. All that

is required is to replace the transaction-level model with a thin layer of compatible

components to convert between the transaction-level activity and the pin-level activity at the

DUT.

The well-defined semantics of TLM interfaces between components also provide the ideal

platform for implementing mixed-language verification environments. In addition, TLM

provides the basis for easily encapsulating components into reusable components, called

OVM verification components (OVCs), to maximize reuse and minimize the time and effort

required to build a verification environment.

This chapter discusses the essential elements of transaction-level communication in OVM,

and illustrates the mechanics of how to assemble transaction-level components into a

verification environment. Later in this document we will discuss additional concerns in order

to address a wider set of verification issues. For now, it is important to understand these

foundational concepts first.

剩余165页未读，继续阅读

derek63

粉丝: 0
资源: 2

OVM 2.1.1 Kit验证方法详解

OVM验证方法学OVM2-1-1

ovm_212验证方法学

uvm验证方法学pdf

VMM/OVM/UVM

ovm candence

uvm-1.1a.tar.gz

如果我想学习数字ic验证，该从何做起

验证工程师需要掌握vip的哪些知识

8bit加法器 uvm

ovm6946怎么防雾

OVM6946+426 功耗

AXI的验证环境该怎么搭建，验证功能点有哪些

systemverilog讲座-pdf教程

OVMDpython代码

可以写一个json格式的登录接口吗？

Libsvm中多类分类python

东华大学在北京2021-2024各专业最低录取分数及位次表.pdf

中国矿业大学(北京)在广东2021-2024各专业最低录取分数及位次表.pdf

NJUST软件课程设计.zip

使用Python语言来模拟一个中秋节日的庆祝活动

最新资源