Open Verification Methodology指南：Mentor Graphics权威详解

需积分: 9 194 浏览量更新于2024-07-28 收藏 2.62MB PDF 举报

《开放验证方法论烹饪书》(Open Verification Methodology Cookbook)是由Mark Glasser编著的一本专业书籍，它旨在提供一套全面且开放的指南，帮助电子工程（EE）领域的专业人士理解和实践有效的系统验证策略。该书作为Springer Dordrecht、Heidelberg、London和New York等多地区出版，具有独特的Library of Congress Control Number: 20099，同时有两个版本的ISBN，分别是印刷版的978-1-4419-0967-1和电子版的978-1-4419-0968-8，以及DOI: 10.1007/978-1-4419-0968-8。本书由Mentor Graphics Corporation出版，该公司位于美国俄勒冈州威尔逊维尔的8005 SW. Boeckman Road。作者Mark Glasser的邮箱地址为mark_glasser@mentor.com。版权信息表明，所有内容受2009年版权保护，未经Springer Science+Business Media, LLC的书面许可，不得全文或部分翻译或复制，除非用于学术评论或研究分析。该书的核心内容可能包括但不限于以下方面： 1. 开放验证方法论基础：介绍这一领域内的通用原则和最佳实践，强调方法的透明度和共享价值。 2. 验证流程详解：涵盖验证设计、建模、测试策略、自动化工具选择和集成在内的各个阶段，确保读者能够实施有效的验证流程。 3. 实例与案例研究：书中可能包含实际项目中的应用示例，帮助读者理解如何将理论知识转化为实际操作。 4. 新技术探讨：随着技术的发展，书中可能会讨论如覆盖率分析、静态分析、动态模拟、形式验证等现代验证技术的最新进展。 5. 工具和技术库：列出推荐的验证工具和平台，以及它们在不同阶段的适用性，以便读者能利用最合适的工具进行工作。 6. 持续改进与优化：强调验证过程中的持续学习和优化，提倡创新思维，以应对快速变化的半导体行业需求。 7. 法规与标准遵从：对于验证工作中可能涉及的行业标准和法规要求，提供合规性指导。《开放验证方法论烹饪书》是一本深入浅出的参考文献，对于从事电子工程验证工作的工程师来说，是提升技能、保持竞争力的重要资源。它不仅提供了理论框架，还着重于实践经验分享，是验证工程师不可或缺的实用手册。

xviii

Figure 3-5 Two Components Isolated with a FIFO . . . . . . . . . . . . . . . . . . . . .64

Figure 4-1 A Simple Hierarchy of Components . . . . . . . . . . . . . . . . . . . . . . . .70

Figure 4-2 Connecting an Initiator to a Target . . . . . . . . . . . . . . . . . . . . . . . . . .74

Figure 4-3 Connecting Ports and Exports through the Hierarchy . . . . . . . . .75

Figure 4-4 Control Flow through Ports and Exports . . . . . . . . . . . . . . . . . . . .78

Figure 4-5 Each Component Has a Database of Configuration Items . . . . . .83

Figure 4-6 Hierarchy of Configuration Databases . . . . . . . . . . . . . . . . . . . . . .86

Figure 4-7 Factory Override Map Data Structure . . . . . . . . . . . . . . . . . . . . . . .91

Figure 4-8 Family of Classes for the Toy Factory . . . . . . . . . . . . . . . . . . . . . . .95

Figure 4-9 Two Producers and a Consumer . . . . . . . . . . . . . . . . . . . . . . . . . .101

Figure 4-10 Interface Connecting Testbench to Hardware . . . . . . . . . . . . . .104

Figure 4-11 Layering Tests and Testbenches . . . . . . . . . . . . . . . . . . . . . . . . . .111

Figure 4-12 Hierarchical Design with Report Handlers . . . . . . . . . . . . . . . .115

Figure 4-13 Affect of a Call to set_report_id_action_hier . . . . . . . . . . . . . . .116

Figure 5-1 Transaction-Level Memory Master and Slave . . . . . . . . . . . . . . .122

Figure 5-2 Request and Response Flow between Master and Slave . . . . . .122

Figure 5-3 HFPB Pin Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

Figure 5-4 HFPB State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126

Figure 5-5 HFPB Write Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127

Figure 5-6 HFPB Read Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128

Figure 5-7 Memory Master with Driver, Monitor, and Pin-Level Slave . . .129

Figure 5-8 Analysis Port Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

xix

Figure 6-1 Master and Slave Connected through a Transport Channel . . . 136

Figure 6-2 Simple Agent with a Driver and a Monitor . . . . . . . . . . . . . . . . . 141

Figure 6-3 Simple Agent with Driver Disabled . . . . . . . . . . . . . . . . . . . . . . . 142

Figure 6-4 Simple Agent with the Monitor Turned Off . . . . . . . . . . . . . . . . 142

Figure 6-5 HFPB Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Figure 6-6 An Example Using an Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Figure 6-7 Complete Topology of Agent Example . . . . . . . . . . . . . . . . . . . . 149

Figure 7-1 Simple FPU Testbench with Coverage . . . . . . . . . . . . . . . . . . . . . 151

Figure 7-2 Pinout for FPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Figure 7-3 FPU Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Figure 7-4 Complete FPU Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Figure 8-1 Relationship between Sequences, Sequencer, and Driver . . . . . 166

Figure 8-2 Simple Sequence Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Figure 8-3 Processes Involved in Sequence Communication . . . . . . . . . . . . 170

Figure 8-4 UML for Sequences and Sequencers . . . . . . . . . . . . . . . . . . . . . . . 171

Figure 8-5 FPU Testbench with a Randomized Sequence . . . . . . . . . . . . . . 173

Figure 8-6 Sequences with Response Queues . . . . . . . . . . . . . . . . . . . . . . . . 176

Figure 8-7 Flow of Control between Sequence and Driver . . . . . . . . . . . . . 177

Figure 8-8 Flow of Control with a Response Handler . . . . . . . . . . . . . . . . . 179

Figure 8-9 Using Sequences to Construct a Test API for HFPB . . . . . . . . . . 182

Figure 9-1 Complete System Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Figure 9-2 HFPB Memory Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Introduction

Software construction is not usually a topic that immediately comes to mind

when hardware designers and verification engineers talk about their work.

Designers and verification engineers, particularly those schooled in electrical

engineering, naturally think of design and verification work as a “hardware

problem,” meaning that principles of hardware design are required to build

and verify systems. Of course, they are largely, but not entirely, correct.

Electronic design requires an in-depth knowledge of hardware, everything

from basic DC and AC circuit analysis and transistor operation to

communication protocols and computer architecture. A smattering of physics

is useful too for designs implemented in silicon (which is the intent for most).

However, building a testbench to verify a hardware design is a different kind

of problem—it is a software problem.

synchronous design techniques, the lowest level of detail that designers must

consider is register transfer level (RTL). As the name suggests, the primary

elements of a design represented at this level are registers, interconnections

between registers, and the computation necessary to modify their values.

Since each register receives new values only when the clock pulses, all of the

combinational logic needed to compute the register value can be abstracted to

a set of Boolean and algebraic expressions.

RTL straddles the hardware and software worlds. The components of an RTL

design are readily identifiable as hardware; such as registers, wires, and

clocks. Yet the combinational expressions and control logic look suspiciously

like those in typical procedural programming languages, such as C or Java.

The process of building an RTL design is much like programming. You write

code that represents the structures in your design using an HDL, a special

programming language designed specifically for this purpose. You use

compilers, linkers, and debuggers, just as you would if you were

programming in C. There are differences, of course. You do not need to

consider issues surrounding timing, concurrency, and synchronization when

programming in C (unless you are writing embedded software, which further

blurs the line between hardware and software).

Testbenches live squarely in the software world. The elements of a testbench

are exactly the same as those found in any software system—data structures

and algorithms. Testbenches are hardware aware since their job is to control,

Today, with the availability of reliable synthesizers and the application of

剩余247页未读，继续阅读

speedboy1211

粉丝: 0
资源: 1

Open Verification Methodology指南：Mentor Graphics权威详解

a practical guide to adopting the universal verification methodology

VMM/OVM/UVM

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

Open SoC Verification（OSV）是什么

uvm cookbook

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

uvm_coverage_db

uvm refernce_model

ovm candence

uvm monitor

最新资源