日志

UVM世界观篇之二：类库地图

热度 2已有 3989 次阅读| 2017-6-11 23:39 |个人分类:验证系统思想|系统分类:芯片设计

读者在之前的SV核心篇章同几位verifier新人一起从底层模块的验证组件搭建、到模块验证环境的组织、通信和激励生成，认识到了一个验证环境构成的因素。这些因素无论是软件对象的创建、访问、修改、配置，还是组件之间的通信等等都是通过用户自定义的方式来实现的。而UVM验证方法学作为将之前高效方法学的融合版本，从自身的初衷而言，就是将验证过程中可以重用和标准化的部分都规定在其方法学的类库当中，通过标准化的方式减轻了验证人员构建环境的负担。从之前SV的验证环境构成篇章中，可以看到的一些公共功能要求是：

组件的创建和访问
环境的结构创建、组件之间的连接和运行
上述阶段的顺序安排
激励和测试的生成、传递和控制
测试的报告机制

由于软件环境中对象的生成是动态的，验证环境中的组件也需要UVM提供底层的功能来完成对象的创建和访问。在组件的创建之上，UVM也需要提供环境上下层次中创建、连接和运行组件的顺序，只有在底层机制上有效地保证这一点，才会避免可能发生的句柄悬空引用问题。

在组件之间的通信中，UVM也提供了功能更丰富的TLM（Transaction Level Model）接口，这可以保证相邻组件的通信不再通过显式的句柄引用，而是独立于外部组件的通信方式。TLM的通信方式为了验证组件的复用提供了很好的封闭性。

在各个TLM通信管道中流通的是高层次抽象级的数据即事务（transaction），一个事务可以包含丰富的内容包括传输指令、数据整包、状态等，从事务发起端到事务接收端的请求在完成之后，也可以通过返回响应事务的方式完成通信同步。

对于测试序列（sequence）的生成和传输也是利用了TLM传输方式在sequence和driver之间完成。而对于不同sequence和driver同时的控制，也类似于SV中测试MCDF的子系统集成测试的要求，需要考虑整体sequence之间的控制，完成好sequence们的协奏。

为了便于验证环境的调试，UVM的报告机制可以将来自于不同组件、不同轻重级别的信息加以过滤，最终生成测试报告。

接下来的这一份UVM地图尝试着按照UVM的核心机制将版图进行了分块：

核心基类
工厂（factory）类
事务（transaction）和序列（sequence）类
结构创建（structure creation）类
环境组件（environment component）类
通信管道（channel）类
信息报告（message report）类
寄存器模型（register model）类
线程同步（thread synchronization）类
事务接口（transaction interface）类

首先，核心基类提供了最底层的支持，包括了一些基本的方法例如拷贝、创建、比较和打印。在核心类之上发展了支持UVM特性的各个相关的类群。工厂类提供了注册环境组件、创建组件和覆盖组件类型的方法。事务类和序列类用来规定在TLM传输管道中的数据类型和数据生成方式。环境组件类则是构成验证结构的主要部分，组件之间的嵌套关系通过层层例化和连接形成了结构层次关系。而事务接口类和管道通信类则共同实现了组件之间的通信的存储，线程同步类则要比SV自身的同步方法更方便，同步时包含的信息更多。信息报告类使得从UVM环境中报告的信息一致规范化，便于整体的控制和过滤。最后，寄存器模型类用来完成对寄存器和存储的建模、访问和验证。

通过上面对UVM类库地图的分类，UVM库可以帮助验证师更快搭建出一个结构良好、便于复用的验证环境。层次化的组件通过phase机制可以有序完成环境的创建、连接和运行，同样层次化的sequence通过test可以完成不同的测试场景。在这里需要提醒读者的是，我们接下来对于UVM机制和类图的分析是建立在最新的UVM-1.2的，由于比UVM-1.1新添加了一些类和做了更新，这一点需要读者注意。

在进入下一篇《UVM环境构建篇》之前，我们将首先带领读者深入UVM的核心机制之一即factory机制，请关注下一节《工厂机制》。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。