日志

为复用IP构建UVM验证环境的一种方法

已有 3983 次阅读| 2016-7-26 16:58 |个人分类:验证前沿资讯

基于复用IP的设计方法学已经被广泛应用在SOC设计中，复用IP数量的增多使得IP的验证与集成变为一个不小的挑战，在本篇论文中，我们将介绍一种通用的搭建复用IP验证环境的方法，这种方法有两个特点:一是通用性强，适用于绝大部分的IP验证，二是我们的IP验证环境除了在IP层面可用，还可以被集成到顶层验证环境中继续发挥验证作用。

下面我们将以AMD的power管理的IP DVR（digital voltage regularor）为例从四个方面来进行阐述:DUT分析，设计验证模块，构建IP验证环境，集成验证环境到顶层。

第一步：DUT分析

DVR被集成在SOC和CPU中的一些功能模块中，负责管理经过这个功能模块的电压，频率，温度以便于整个芯片可以更有效率的工作，减少功耗，下面是DVR的简图:

从验证角度来看，

DVR有两个接口可以配置内部的寄存器，分别是Jtag接口和AMD平行总线接口(parallel interface)
DVR的输入是一些用于驱动内部计算逻辑的电压信号（voltage input）和驱动内部状态机的控制信号（control signals），它们可以放在一组接口中
在验证环境中有一个行为模型模拟电压传感器，它是RTL的设计者提供的

第二步：设计验证模块

逻辑上看，DVR模块有三组接口，我们将会设计三个代理（agent）来分别与它们交互，每一个代理都分别有一个sequencer，driver，monitor，每个driver和monitor都会拿到虚拟接口的句柄进行驱动和采数，每个sequence（数据和控制信息）会通过代理中的sequencer被发送到driver中去，driver负责把接收到的sequence顺序驱动到接口上去，下图展示了我们针对DVR的整个验证框架

在另一方面，当有读写寄存器的操作发生时，我们会利用UVM中driver和sequencer的"item_done(tx)"和"get_response(tx)"的交互机制进行寄存器的读写检查，driver负责把数据驱动到DUT的输入，然后读回DUT的输出，这样我们可以在一个sequence中对寄存器的读写访问权限进行检查而不用依赖scoreboard中的寄存器模型。

另外在验证环境中例化了一个scoreboard，它包含一个预测器(predictor)和一些做比较的逻辑(cmpr)，代理中的monitor把采集回来的DUT的输入和输出数据分别送给预测器(predictor)和比较逻辑(cmpr)的输入，然后cmpr负责把它的两个输入(DUT的输出和predictor的输出)做比较，如果不一样则会打印出错误信息。

在验证环境中我们还有一个功能覆盖率的模块和一个负责配置验证环境的模块，功能覆盖率模块包含一些针对这个IP的需要覆盖到的测试点，它的句柄会被传给monitor中负责收集覆盖率的函数，用以保证收集功能覆盖率的函数可以访问到任何一个覆盖率的点，这些被链接在monitor的环境中收集功能覆盖率的函数每当在有事务(transaction)被创建且发送出去时，就会被调用用来收集覆盖率的信息，最后收集到的覆盖率信息会被放在一个数据库中，通过一些脚本处理成HTML的格式，由验证人员去分析，配置模块负责配置验证环境中的所有的变量，例如bus的宽度，Jtag的开关，以及各个agent工作模式的变化，由于我们IP验证环境比较小，所以只有一层的配置模块，在各个agent内部没有子的配置模块，另外是我们的配置模块中有一些"ifdef"的开关去控制一些变量，这些变量最终会被传到一些component的类中去，可以实现整个验证环境的模式配置(模块级别中的主动模式(active mode)和顶层中的被动模式(passive mode))。

第三步：构建IP验证环境

我们的验证模块会提供所有的验证激励，而TB负责把DUT和验证模块以一个灵活的结构连在一起，我们把TB定义为了一个模块，其中包含验证模块，接口，时钟/复位，SV的行为模块，如下图

验证模块中的所有的接口都被例化在TB中的SV接口中，TB的端口信号都被定义成"inout"类型，接口中的信号定位"logic"类型，TB的端口和接口信号都被以双向类型连接起来，这样如果DUT的端口方向有所改变，TB中的端口类型也可以继续使用，clk/rst模块负责为DUT和验证环境中的SV行为模块提供clk和rst信号，它也是可以配置的，可以在验证模块时打开，验证顶层时关闭，模块的基础测试激励通过验证环境的指针来对访问验证环境中的各个代理(agent)，来发送代理中的sequence，其他的激励基于基础测试激励进行扩展。

第四步：集成验证环境到顶层

当一个IP被集成到顶层环境中时，我们最关心的是IP能不能被以正确的方式去使用，对于模块中的测试激励已经无法在复用了，我们在顶层环境可以复用的只有monitor和checker，有两种方法去复用:一是把它们直接链接到顶层环境，二是把整个IP验证环境链接到顶层，然后配置参数，如下图

为了能够更简单的复用验证环境，我们把整个IP的TB用SV的bind方法链接到DUT下面，这样，无论DUT在哪里例化，那TB的环境也会被一起带进去，我们要做的改变是通过配置模块关掉TB中的agent，sequence等等，只留下monitor和scoreboard，并把接口中的信号连向上一层的RTL输出，这样顶层的验证人员不需要对被bind上去的TB环境做任何改动，就可以实现对IP DUT的验证，下面是bind的代码

如果想再减少IP集成时环境的改动，我们可以在一开始就定义好TB和验证模块以及接口的被动模式，这样就只需要改变配置文件，无需做其他改动。在顶层的测试激励中，将会有一个假的测试激励用于启动所有UVM的component，由于顶层验证人员想最大程度的隔绝属于IP级别的事情，我们会仅仅把例化在TB模块中的验证模块的句柄传到顶层测试激励，无论顶层测试激励是基于C/C++或是UVM，这样就可以时刻对IP模块的使用方式进行监测。

总结

我们阐述了一种构建复用IP的验证环境的方法，这种方法最大的好处是，我们不仅可以在模块级别对IP设计进行验证，还能够把我们模块级别的验证环境最大程度的复用到顶层验证环境中去，这样，我们就实现了水平(验证环境可配置适用于绝大部分IP)和垂直(在顶层环境中复用模块级别的验证资源)两个维度上的复用，以最大程度迎合我们复用的验证理念。