本文
芯片验证系列文章主要分为三部分：验证工程师与芯片验证、SV学习笔记、UVM学习笔记。此为 验证工程师与芯片验证 部分第一篇，主要介绍验证的背景、验证的前景、验证的目标、验证的流程。
参考
| 名称 |
作者 |
来源 |
| 《芯片验证漫游指南》 |
刘斌 |
书籍 |
| 《全面的功能验证：完整的工业流程》 |
Bruce Wile , John C. Goss , Wolfgang |
书籍 |
专业术语与缩略语
| 缩写 |
全称 |
说明 |
| FAB |
fabrication/foundry |
晶圆加工厂 |
验证的背景
芯片开发流程
- 从市场调研和用户需求开始，形成产品报告。
- 系统设计人员按照功能划分为各个子系统。
- 子系统被进一步划分为功能模块，并由设计团队实现。
- 验证人员对设计功能展开验证，发现设计缺陷，交由设计人员修正。
- 验证没有出现漏洞后，交由后端人员进行综合、布局、布线。
- 后端人员将核心数据交由FAB进行流片。
验证和设计的关系
- 设计如果没有经过充分验证、量化验证，是没有足够信心去流片的。
- 验证要懂设计，否则无法更好的发现和定位bug。
- 设计要懂验证，否则无法体会验证逐渐趋向于软件化。
- 设计需要验证尽早尽快尽量的发现设计bug，越到后期修正设计bug的代价越大：1）后期设计的修正可能牵一发而动全身；2）修正后需要完整的回归测试；3）甚至需要后端重新综合布局布线。
- 设计和验证都需要围绕功能描述文档展开工作。
- 设计初步完成时验证就要启动，甚至更早启动。
- 发现验证结果与预期不符，明显bug可提交给设计工程师，若无法判定，需要与设计工程师依据功能描述文档进行沟通，统一对功能的理解。
- 设计从底层模块向系统集成过程中，验证与设计要各自开展工作，验证要保证每一个层次验证的充分性和完备性。
验证和设计的协作
- 验证和设计都需要认真阅读功能描述文档。
- 设计会将其实现为RTL模型。
- 验证会按照其功能发送激励和比较结果。
验证的三个方向
- 设计功能是否符合功能描述文档？
- 设计工程师是否有遗漏的边界场景(Corner Case)？
- 设计是否足够稳定来处理错误场景(Error Response)？
验证的挑战
- 如何穷尽所有场景为设计产生激励？
- 如何在各种激励下发现和判断设计的bug？
- 根据不同类型设计提供相应的测试激励，选择相应的check方法。
- 根据不同类型设计选择相应的验证工具，仿真验证和形式验证。
- 根据复杂度不同，选择黑盒验证、白盒验证以及灰盒验证。
| 设计类型 |
激励类型 |
结果比对方法 |
| 处理器 |
预先被存入到存储单元的指令和数据 |
每个指令执行以后寄存器的值是否符合预期 |
| 存储控制器 |
数据的读写操作并且尽可能覆盖所有可访问范围 |
数据的存储和读取是否正确 |
| IO模块 |
数据包的传输，包括定义包的头部、长度、数据和地址 |
数据从IO的输入到输出是否得到正确的转换打包，数据是否有丢失的情况 |
| 音频视频组件 |
数据流的编码解码 |
数据流在输出端相对输入端来讲的完整性是否符合预期音频是否失真，视频是否完好 |
| 片上网络(NoC) |
通过列出主从单元的访问矩阵来穷举所有可能的访问路径 |
各个可能访问的路径是否都可以通过同时被禁止的路径是否按照预期无法访问 |
| 系统模块(时钟、复位、电源) |
逻辑开关测试，顶层连线测试 |
通过寄存器的配置各个控制信号是否正确更新，同时顶层的连线是否将系统模块的输出连接到目标子系统端 |
验证的前景
- 工作中设计与验证同等重要（薪资）。
- 验证需求量大，与设计的比例接近2:1。
- 学习和掌握验证知识，对后期从事设计或验证都有帮助。
- 公司研发团队越正规化，对验证的规范性越重视。
- 验证工作越来越趋向软件化，知识迭代比设计快，更富有挑战性。
验证的目标
按时：
- 验证工程师需要按照项目的预期进度来考虑验证节点。
- 协调安排各模块验证工作进度，任何一个模块验证的延迟都会影响整体验证进度。
- 团队协作，所有验证工程师都要有时间节点观念。
保质：
- 尽可能保证验证的充分性和完备性，减少硅后bug的出现。
- bug出现的阶段越到后期，代价越大。
- 提前做好验证计划，设计与验证定期沟通，保证验证计划的充分性和完备性。
低耗：
- 人力和时间成本低耗，保证工作的高效率。
- 资金成本低耗，尽早保证验证的充分性，防止bug出现在硅后甚至客户端，就是在保证资金成本低耗。
验证的流程
验证流程
- 创建验证计划 ：参照设计功能描述文档创建验证计划，并且与设计师完成多次review，确保验证计划无明显缺陷。
- 搭建验证环境 ：验证师搭建验证环境，准备测试用例。
- 模拟仿真和debug ：运行测试用例，进行验证环境和设计的debug。
- 回归测试 ：当设计通过了一定量的测试用例，验证师需要准备回归测试，也就是将已有的测试用例重新测试一遍。
- 验证代码检查 ：也就是对验证环境和当前验证结果的review，检查是否有遗漏的测试用例、不恰当的随机约束等。
- 收集覆盖率 ：覆盖率包括功能覆盖率和代码覆盖率，覆盖率是对验证进度以及验证完备性的重要数据指标。
- 完备性检查 ：主要根据验证计划、验证进度、数据结果等信息来综合评定是否全部完成验证任务，并签字画押。
- 硅后测试 ：当硅后测试发现bug时，不仅要协助测试人员定位和修复bug，更重要的是分析硅前测试bug逃逸的原因，总结经验教训。
review节点
- 验证计划review ：设计师与验证师依据功能描述文档沟通，检查验证计划，确保无明显遗漏和功能偏差。
- 验证代码review ：回归测试前，设计师与验证师对验证代码进行review，检查是否有遗漏的测试用例、不恰当的随机约束等。
- 覆盖率review ：回归测试后，对当前覆盖率进行review，确保验证的完备性。
- 验证总结review ：其一是分析bug逃逸，总结经验，吸取教训；其二是验证流程、工具使用、团队协作等经验总结。
功能描述文档
- 接口信息 ：描述接口信号的时序信息和数据传输信息等。
- 结构信息 ：描述模块的逻辑结构，包含各个功能组件，以及各个功能组件的逻辑关系。
- 交互信息 ：描述模块与其他模块的交互信息，包括逻辑示意图和时序信息，确保集成后模块间按照预期功能完成交互。
验证计划
- 验证方法 ：定向验证、随机约束验证、形式化验证等。
- 验证工具 ：选择需要的验证工具来支持验证方法，如VCS、XRUN、JasperGold等。
- 验证完备性 ：量化一些参数（功能点覆盖率、代码覆盖率、断言覆盖率）可以衡量验证任务是否完成。
- 验证资源和进度 ：人力、时间、硬件、软件等预算。
- 验证功能点 ：列出验证功能点，以及明确在什么层次去验证它，甚至选择何种激励去验证它。
开发验证环境
- 搭建验证环境，实现driver、reference和checker。
- 不同的验证方法，验证环境的结构和使用软件不同。
- 随着bug的发现和修正，设计趋于稳定，验证环境保持更新，补充测试用例。
- 添加covergroup或assert，使环境支持覆盖率收集。
debug
- 验证环境是否存在bug。
- 硬件设计是否存在bug。
- 测试激励是否合理。
- 参考模型是否遵循设计功能描述文档。
回归测试
- 确保改动没有引入新的bug。
- 随机种子不同，测试激励不同，有利于收集覆盖率，往复的回归测试和补充的定向测试，可逐步提高验证的完备性。
芯片流片
- 经过回归测试（RTL回归和门级网表回归），项目负责人、设计负责人、验证负责人、后端负责人一同回顾整个checklist，确保通过各项指标，交给FAB厂商进行流片。
- 特别提示： 即便已经交给FAB厂商进行流片，仍需要继续保持回归测试，并尽可能创造新的测试激励，覆盖更多状态空间，进一步保证验证的完备性。
- 如果交给FAB厂商进行流片后发现设计bug，一考虑是否有软件补救办法，二提交设计修改意见，下次流片前准备好设计和验证方案。
硅后测试
- 流片后系统测试工程师会将芯片植入测试系统或依靠测试开发板，进行硅后测试。
- 硅前工程师（设计、验证）和硅后工程师保持沟通，出现测试问题，第一时间判断是测试问题还是设计bug，以及如何修补。
逃逸分析
- 验证无法保证设计没有任何bug，而是尽可能发现所有bug。
- 硅后测试发现bug，设计和验证要与系统测试沟通，尝试在硅前的仿真环境中复现。
- 逃逸分析后，对下一个芯片周期，设计如何规避设计bug、完善设计经验，验证如何完善验证方案、如何产生更多有效测试激励都是很有意义的。
文章原创，可能存在部分错误，欢迎指正，联系邮箱 cao_arvin@163.com。