验证笔记
验证进阶操作
设计跟验证
验证跟设计的关系
- 设计跟验证，都需要参考同一套功能描述文档：设计时根据该文档设计、实现；验证时根据该文档设计验证点
- 验证发现bug之后，需要设计人员修改设计、代码；然后需要对新的实现做回归测试
- 设计跟验证同步：设计（模块、子模块、系统）各个等级，验证都需要同步进行，确保验证的完备性
验证的挑战
验证需要解决的问题:
- 如何产生激励(testcase)，一般是在sv里面提供随机约束后由sv随机产生
- 如何判断结果正确性，结果比对的方法
验证的重要性:
- 验证跟设计薪资相当
- 验证跟设计人员比例2:1
- 验证工作趋向于软件化，知识迭代跟新更快
验证的过程:
- 创建验证计划(确定需求之后，跟设计工程师多次review)
- 搭建验证环境
- 仿真测试：在测试环境里测试testcase，进行验证跟debug
- 回归测试：通过一定量的testcase之后，需要进行回归测试（确保bug修改不会导致之前的case不通过）
- 验证代码检查：检查验证是否有遗漏、或者不恰当的随机约束
- 覆盖率收集：代码覆盖率、功能覆盖率；覆盖率是表征验证完备性的重要指标
- 完备性验证：根据验证计划、验证进度、覆盖率收集等情况，来判断当前的验证进度，判断是否完成所有的验证任务
- 硅后测试：硅后测试人员发现bug之后，验证人员需要跟硅后测试人员一起分析“硅前测试bug逃逸”的原因
验证review
- 验证计划review
- 验证代码review
- 覆盖率review
- 验证总结review
测试平台
- 定义：能够对DUT进行验证并且能够生成验证报告的平台
- Driver:
- 模拟于DUT进行交互的接口，模拟真实的信号去驱动DUT
- 可以主动发送信号给DUT；也可以接受DUT的请求后再发送信号给DUT
- Moniter: 监测DUT的信号
- 监测DUT的IO
- 监测DUT的内部关键信号（采用灰盒测试，尽量不要监测太多内部的信号）
- 监测信号可以反馈给driver，产生对应的测试激励
- 监测信号可以用于生成验证报告
- Checker: 判断DUT功能
- 缓存moniter的结果，用于生成测试报告
- 将激励发送给RM(reference model)，比较RM跟DUT
验证计划
功能需求文档 & 设计文档 --> 验证计划文档:
- 设计文档跟验证文档，都是根据功能需求来的
- 验证文档还受设计文档的影响
- 功能需求文档、设计文档更新之后，验证文档都需要对应更新
验证计划的好处:
- 设计人员跟验证人员对于需求的理解保持一致
- 为功能文档提供反馈，修改文档中不明确、有歧义的描述
- 将自然语言描述的功能通过可测试性语言来描述
- 将自然语言描述的功能通过可测试性语言来描述
- 为验证人员提供明确的验证目标、任务和进度安排
验证计划的内容:
验证的功能:
- 基本功能，在模块级验证中完成
- 交互功能：在子系统级、系统级完成
- 次要功能：不太重要的功能，如性能（性能优先级肯定在正确性之后）；最后验证
验证的层次:
- 弄清楚功能点在哪个层级进行验证
- 从验证效率和激励自由度来看，应该尽量在较低层次验证更多功能点
- 在较高层次，应该侧重于系统集成测试
验证的方法:
- 方法： 模拟仿真 or 形式化验证 or 硬件加速验证
- 透明度： 黑盒 or 白盒 or 灰盒（建议尽可能使用黑盒）
- 激励： 定向激励 or 随机约束激励
测试用例testcase:
选择： 更随机的测试方法，尽可能遍历可能的状态空间 适中的随机约束，倾向于更贴近实际场景的随机激励 采用定向测试，针对一些边界情况可以更有效的收集覆盖率
建议： 验证初期，应该只发送一些基本的测试数据，约束范围尽可能窄 验证中期，由于设计基本稳定，可扩大约束范围，以此更有效地完成验证 验证后期，有一些边界场景通过随机约束激励无法有效收集覆盖率，需要采用定向用例
功能覆盖率
功能覆盖率衡量设计的各项功能是否实现。功能覆盖率会关注设计的输入、输出和内部状态。
- 输入： 检测数据端的输入和命令组合类型，以及控制信号与数据传输的组合情况。
- 输出： 检测是否有完整的数据传输类别，以及各种场景的反馈时序。
- 设计内部： 检查信号与功能点相对应，通过单一覆盖、交叉覆盖或时序覆盖来检查功能场景是否被触发。 注意： 功能覆盖率的收集需要依据功能点文档编写covergroup，且fail用例的覆盖率数据不能合并到回归测试的覆盖率数据中。
UVM & SV
- TODO: sv
- TODO: UVM
- testcase
- checker
- 中断如何测试