基于模块的断言监视器

9.2　基于模块的断言监视器

本章的第一个例子是基于模块的断言监视器。它身兼两任，一方面它被用于确认DUT是否按照预想工作；另一方面它将管脚级行为转化为事务流，供平台中其他验证组件（如覆盖率）统计器使用。

基于模块的监视器有三个独特之处。第一是使用SystemVerilog的属性和序列代替程序代码FSM模型，确认和校验总线上发生的事件；第二是使用分析端口向验证平台中所有接受组件（subscriber）广播信息；最后是使用另外一个分析端口向测试控制器传送错误状态信息，控制器则根据信息采取适当动作。

9.2.1　类和模块组成的完整验证平台

图9-5是一个由类和模块混合组成的验证平台例子。基于模块的断言监视器在验证平台top.sv模块中例化（如下代码所示），而基于类的组件均在tb_env类（从avm_env类扩展而来）中例化。

图9-5　混合类和模块的验证平台

驱动模块、响应模块和监视器之间的连接通过管脚级SystemVerilog接口（前面5.4节中讨论过）实现，如图9-6所示。

图9-6　SystemVerilog接口

除管脚级SystemVerilog接口之外，基于模块的断言监视器还需要与验证平台中的多个分析验证组件通信，因此在监视器中引入了一个错误状态分析端口，如图9-7所示。同样，监视器中也添加了一个分析端口，用于向验证平台中所有注册验证组件广播信息。

图9-7　AVM分析端口

图9-7中，当监视器发现非流水线型总线错误时，错误状态分析端口将该错误情况通过错误事务对象向外广播发送。下述代码是扩展自avm_transaction基类的错误事务类。tb_status类包含了一个枚举各种类型错误的enum和一系列方法，给检测到的错误作唯一标示。

接口nonpiped_bus pins_if实现监视器和验证平台的驱动以及响应组件间的管脚级连接（详细情况参照图9-6）。该接口在验证平台的top模块内例化，然后被传入监视器tb_monitor。另外，该接口也被传入环境类env构造函数（new）中，赋值为虚非流水线型总线接口，代码如下所示：

环境类的构造函数调用验证平台中所有其他基于类的组件的构造函数。基于模块的监视器与基于类的驱动以及响应验证组件间的连接最终在环境类的connect方法中实现，代码如下所示：

同样，基于类的覆盖率统计器和测试控制组件也在环境类的connect方法中，注册于监视器的覆盖率分析端口。到此，完成了监视器与所有AVM类组件间的连接。

9.2.2　基于模块的断言监视器的实现

为了使断言编写简单化，我们在模块内构造一个由控制信号sel和en到先前定义的状态的映射模型。这一系列的断言通过监测总线状态的非法转换来检测协议违反情况。

现在，根据9.1.3小节中定义的非流水线型总线需求写出以下断言：

断言a_state_reset_inactive说明，复位后，总线必须初始化到INACTIVE状态（意味着sel和en信号均无效）。同样，根据9.1.3小节中自然需求列表，可写出其他断言。

构建基于模块的断言监视器时，建议将错误（覆盖率）检测与处理分开，例如在监视器内关闭断言只处理总线行为。断言检测打开后，在失败断言的行为块中调用错误事务类status的方法，来唯一标示错误类型。然后将该错误的情况通过监视器中的分析端口反馈给测试控制器，控制器则根据此信息采取适当动作（甚至可选择忽略该错误）。监视器中错误监测和行为处理完全分开，提高了其重用性并在其本身不改变的前提下支持更高级的验证平台功能（如错误插入）。

最后一组断言（定义于9.1.3小节）规定，当总线在START和ACTIVE状态间转换时，总线控制信号、地址信号以及写数据信号均需保持稳定。

除断言外，基于模块的断言监视器一般还包含覆盖率属性。如在下述代码中，为非流水线型总线编写了覆盖率属性用于跟踪总线突发读写大小。

上述序列中定义了局部变量psize，当处理总线突发时，每次完成一个新的数据字传输，该变量就加一。而在下述代码中，将看到突发大小和类型（如读或写）被传递入build_tr函数中。

通过基于模块的断言监视器的覆盖率事务分析端口，函数bulld_tr将突发尺寸和类型信息向验证平台中的所有预定的验证组件（本例中，可能为测试控制器或覆盖率统计器）广播，以供它们使用。