利用APB_I2C模块搭建层次化验证平台

一、前言

　　近期疫情严重，身为社畜的我只能在家中继续钻研技术了。之前写过一篇关于搭建FIFO验证平台的博文，利用SV的OOP特性对FIFO进行初步验证，但有很多不足之处，比如结构不够规范、验证组件类不独立于DUT等问题。此次尝试验证更复杂的IP，并利用SV的更多高级特性来搭建层次化验证平台。

二、APB_I2C IP概述

　　实践出真知，于是在opencores网站上下载了个APB_I2C的IP核，便着手展开验证工作。第一步是理清楚这个IP的整体功能、引脚作用以及顶层结构。整体功能从模块名称便可得知是带有APB总线接口的I2C_master。要了解引脚作用与时序，直接截取SPEC上的示意图查看：

APB_WRITE:

 APB_READ:

 I2C_PROTOCOL:

 　　接口和协议这里就不细说了，感兴趣的朋友查找相关的资料。至于顶层结构这方面，最好还是交给工具方便点。无奈回家没有带回我的虚拟机硬盘，只能下载个WINDOW版本的EDA工具了。本文使用QuestaSim，原理图如下：

　　很容易看出该模块顶层包含APB接口模块APB、分别用于缓存发送和接收数据的FIFO_TX和FIFO_RX，以及I2C协议转换模块I2X_INTERNAL_RX_TX。master通过APB总线访问该IP核内部的数据缓存区和配置寄存器，无需关注内部实现。

　　除了这几个方面，配置寄存器的访问也非常重要。IP核必须做出正确的配置和使能才可以按照需要正常工作。配置寄存器见下表：

 三、QuestaSim常用指令

　　QuestaSim工具的WINDOWS/LINUX版本很容易下载到，和Modelsim的主要区别是对SV UVM的支持性较好，这一点非常符合本文的意愿。但仿真过程中一次次点击鼠标很麻烦，只好学习学习操作命令了，写个脚本配合SV实现自动化仿真。以下是在官方文档user manual和tutorial中截取的常用指令及解释。

1 Compile the source files. vlog gates.v and2.v cache.v memory.v proc.v set.v top.v

2 Use the vopt command to optimize the design with full visibility into all design units 

vopt +acc -o -debugdb

The +acc argument enables full visibility into the design for debugging purposes. The -oargument  is required for naming the optimized design object. The -debugdb argument collects combinatorial and sequential logic data into the work library.

3 Use the optimized design name to load the design with the vsim command: vsim testcounter_opt -debugdb

4 set WildcardFilter "Variable Constant Generic Parameter SpecParam Memory Assertion Endpoint ImmediateAssert" With this command, you remove “CellInternal” from the default list of Wildcard filters. This allows all signals in cells to be logged by the simulator so they will be visible in the debug environment. 

5 Add Wave *

6 add log /*

This will provide the historic values of the events of interest plus its drivers

7 run 500

四、搭建验证环境

　　这一节是本文的核心内容了。通用的验证环境的结构和组件如图：

 　　Stimulus将测试激励送入待测试模块DUT，Monitor观察响应并发送给检Checker。遇到复杂的设计还需要设计Reference model，进而对比实际响应与黄金参考的响应区别。并且当Monitor无法简单直接地收集DUT响应时，还需要设计VIP来解析复杂的响应信号时序。这几天参照工具书和网上的教程视频，根据APB_I2C模块的特性构思出基本的验证环境。

　　APB_I2C模块并不复杂，所以没必要设计reference model。若想利用Monitor组件获取DUT响应需要解析I2C协议时序，这里编写个VIP来帮助它解析出有效数据，进而与Stimulus数据对比。Monitor因VIP的存在得到了很大程度上的简化，主要的功能为将等待触发事件发生后，将数据通过MAILBOX传输给Checker进行比较。

　　另外，为了让Stimulus脱离具体接口信号操作，建立Generator和Initiator类分别用于产生读写访问和将读写访问转换成读写操作对应的具体信号逻辑。为了实现OOP特性中的“细节隐藏”，建立配置类Config来配置验证环境，这里主要是配置Generator发送特定场景的读写请求。想要测试不同的功能特性，只需改动传入Config的参数即可。到此验证环境包含了Generator Initiator Monitor Checker Config五个验证组件，这里再建立Environment类将这些组件包在一起，方便调用方法。还是上图更直观些（有点丑，凑活看吧）

 　　除了验证环境结构，好的代码结构也能极大提高平台的重用性。这里将所有类及对应的属性方法封装到Package components中，方便被import到testbench中。验证过程中用到的所有变量类型、参数放置在defines.sv中。

五、仿真分析

　　当Config类对象的配置参数为CONFIG_WR_DATA时，generator发起写请求。波形如下：

 　　观察打印的Log可以看出每个SCL时钟周期采集到一个bit，MAILBOX正确传输，checker对比正确，故而仿真PASS。

　　验证过程中发现该模块有很多BUG！！这里举两个例子。

1 SDA为双向端口，但当sda_enable为0时，并没有赋值为高阻态，即释放信号线控制权给slave。做出如下修改并让VIP在ACK阶段拉低SDA。

 2 SCL在读操作状态机中没有被toggle，因此config的配置参数为CONFIG_RD_DATA时SCL没有翻转。在读操作状态机中添加翻转逻辑，使BR_CLK_RX_O信号在counter_receive_data == clk_t_1_4时拉高，counter_receive_data==clk_t_3_4时拉低。

 　　波形显示在读操作时SCL正常翻转。

 　　该模块的读操作很多地方不正确还有待修改，就不一一赘述了。总的来说就是根本不能用o(╥﹏╥)o 不抱希望了，之后我还是自己写一个吧。

六、总结

　　本文利用APB_I2C模块为例搭建了层次化验证平台，但还有待改善。这里列出几点：

1 没有完全做到测试用例与环境分离

2 没有构建场景层给予丰富的pattern