集成电路开发中的自动化工具-验证回归工具

引言

IC验证工程师在接到任务后的工作流程一般是这样的：

• 读模块规格说明书（Module Specification）
• 写验证计划（Verification Plan）
• 搭建测试平台（Testbench）
• 开发测试用例（Testcase）
• 跑仿真调试（Simulation & Debug），如有Bug需上报并等待修复并重新测试
• 批量跑所有的测试用例并自动给出结果，称为测试回归（Regression）
• 收集各项覆盖率（Coverage），根据结果增加新测试用例，查漏补缺
• 写测试结果报告

在以上工作中，开发测试用例和跑仿真调试占据了验证流程的绝大部分时间，也是验证工程师的工作日常；在这个流程中，下面的工具有潜在的自动化需求：

• 搭建测试平台自动化
• 测试回归及结果报告自动化

验证回归工具

一个简单的验证回归工具，至少需要做下面一些步骤：

• 创建临时目录，将所有的测试用例目录拷贝或者浅拷贝到临时目录下面
• 分别启动每一个测试用例，本地启动或者提交到算力池，并重定向输出到log文件
• 对于随机测试用例，上面一步需要多次启动并给出不同的随机种子
• 等测试用例结束之后，需要打开log文件并检查有没有错误发生
• 生成所有测试用例的运行结果

从上面的步骤可以看出，如果没有回归自动化，手动做这项工作还是相当麻烦的；但如此简单的功能肯定不是一个通用工具，要解决通用性，上面的步骤很多地方需要参数化，比如下面列举的一些方面：

• 临时目录的位置
• 哪些测试用例参与回归
• 并行启动的用例个数最大值
• 随机用例的次数
• 检查结果时哪些算出错，哪些不算出错

解决了以上参数化后，就勉强算一个最低要求的通用回归工具了；但这并不终点，我们不会因为解决了温饱问题就止步不前，高质量的幸福生活是我们每个人追求的目标！

RunFab

RunFab是笔者开发的主要用于验证回归的通用并行任务管理工具，目前具有下面一些功能：

• 任务模板的定制，任务的参数化
• 任务的实例化，以及任务实例列表管理
• 任务实例的启动，停止，实时运行状态监测
• 运行结果的检查，可配置的关键词句过滤
• 结果报告的生成
• 集成的验证目标计划模块，验证目标与测试用例的映射和覆盖率的结果报告

RunFab将用户执行的命令抽象成一个任务模型，任务由若干条动作组成，动作可以是一些Linux命令，也可以是一些python模块里的函数或者类，这些动作可以支持输入参数，参数可以是常量，也可以是变量；含有变量的任务就是参数化的任务，将这些变量具体化就是任务的实例化，由多个实例化的任务组成了任务实例列表，对任务实例的管理是工具的核心内容；

任务可以嵌套，形成树形结构，任务内的变量可以定义本地缺省值，任务实例可以用一个新值覆盖这个缺省值，层次化的任务树形结构形成的变量值的覆盖链条，这个链条的顶端是任务实例；在任务实例列表文件中，也可以有列表及的缺省值，它的优先级介于任务和任务实例之间；这个策略跟编程语言的类的继承概念相似，都是方便代码复用，以及用户做扩展；

RunFab的内核有一个并行任务分发器，负责启动并行任务并实时监测任务的运行状态，并将实时状态回传给内核，可以及时显示在图形界面上；用户可以通过界面或者命令来控制任务分发器来启动部分或者全部的任务实例，也可以停止部分或者全部的运行任务实例；

结果检查模块负责在任务实例运行结束后，对产生的一个或者多个日志文件进行分析，给出运行结果；检查模块定义了2级过滤系统，第1级为错误抓取，第2级是错误排除，日志文件内容经过2级过滤后剩下的就是真实的错误，需要用户关注并分析；用户可以使用工具自带的检查器，也可以自定义一个，然后用配置告诉工具怎么调用；

RunFab还针对验证的随机测试用例做了相应的功能，可以方便的产生随机子用例，以及随机子用例的重复次数，并对随机子用例进行管理；

另外，除了对任务实例的管理，也支持工具级的一些配置，比如：

• 对远程提交任务的控制
• 任务分发器的启停
• 并行任务数量的控制
• 任务运行的后台模式、独立窗口模式、以及图形模式的选择

RunFab不仅可以用于验证回归，也可以用于日常的一般任务，例如将一些常用命令，或者流程做成一个任务，再将任务实例化，并对每一个实例起一个好记的名字，这样就可以将一些杂乱无章的命令或者脚本统一放到一个或者多个分类的任务实例列表中去，用户只需要打开固定的列表，在里面选择要执行的有名字的实例即可，省去了记忆大量命令的烦恼；

总结

验证回归工具实际上是验证流程中的平台，验证工程师日常用它来启动仿真，检查分析结果，写验证计划，生成验证报告等；在现实中它为验证工程师提供一条龙的服务，是验证工程师真正的朋友!