SoC验证如何减少Bug

前言

在SoC验证中， checklist 是很重要的一步，要审视下有没有无意间漏掉的检查或者做出的假设。大部分情况下，checklist总能发现一些RTL bug，本文给出了 检查的思考方向 ，希望对大家有用，也欢迎大家补充。

存在假设

• 对TB的假设

• 对IP只需要验证集成和基础功能就可以？

• 测试点分解时有做过哪些等价类划分？

• Memory调试信号不需要看，有错的话，验证环境会报的？

• 继承的用例一定没问题？是golden的？

• 如果集成的IP没变，验证用例也不需要改动？

• 对RTL的假设

• IP是成熟的？

• IP功能没有修改？

• IP是供应商交付的？

• 寄存器是脚本产生的，默认值应该不存在问题？

• 没有改动的代码没有问题？

• 不同层次验证是否使用相同的RTL版本

上述这些假设是否成立，我们该如何证明这些假设是成立的。

功能验证

• IP的输入信号

• IP的输入信号有哪些？是否每根信号都有覆盖过？

• 是否构建了多个输入同时触发的场景？

• 输入信号来源于哪些IP，这些IP在各种低功耗场景下给我的信号正确吗？

• 输入信号来源的IP的工作场景和我负责的IP有耦合吗？

• IP的输出信号

• IP的输出信号值是否正确？

• 每根输出信号是否都正确连接到对应的终点？

• 输出信号是否是寄存器输出？

• 中断输出是脉冲还是电平？是否构建了多次中断，且中断是否能被正确消除？

• 掉电或异常时，输出是否会有毛刺或跳变出现？

• IP的工作流程

• 只验证集成的，集成验证的层次是否正确？是否验证到了IP的接口位置？

• IP的整体工作流程是怎么样的？

• 在整个工作流程中，时钟域是否正确，占空比是否合适？

• 复位域是否正确，复位宽度是否合适？

• 上电流程是否正确？

• 下电流程是否正确？

• 电源域是否正确，掉电钳位值是否正确？

• 如果有多个时钟源，是否构建了各种频率组合，特别是时钟源之间的最大频率差和最小频率差？

• 如果有多个电源域，是否构建了各种电源域的组合？

• 是否构建了多次上下电的场景？

• 上下电流程波形检查了吗？

• 是否构建了唤醒的场景？唤醒信号的宽度是否合适？

• 安全是如何管理的？

• 会有哪些异常，这些异常是如何管理的？

• IP如果在样片上出现问题，该如何debug呢？需要的信号通过什么手段得到？如果同时发生其它问题，还能继续debug吗？

• 如果有一个访问挂死，会怎么处理？

• 总线反压是如何触发的？该如何解反压？

• RTL代码我review过了吗？如果我是设计人员，我会如何设计这些代码？我考虑了哪些因素，目前的设计人员都考虑了吗？

• IP中有异步设计吗？怎么做的？符合规范吗？异步两端的复位是怎么处理的？

• 多个master访问同一个slave，访问的优先级是否正确，访问地址时怎么处理的？

• IP的应用场景

• IP的各种应用场景都覆盖了吗？

• 在各种应用场景中使用哪些输入和输出？以及如果出现了其它输入信号的跳变会怎么样？

• IP对外支持的功能是否都验证到了？是否验证了一个功能多次触发的场景？

• 配置是否支持动态配置？

• 构建的应用场景是否全面，是否足够复杂，是否考虑了多种场景、异常的组合？

• 移植的验证用例我修改了哪些？为什么要做这些修改？其它不修改的地方是基于什么考虑？

• 所有验证用例都了解吗？每一行的作用都明白吗？

性能验证

• 这个IP的性能指标有哪些？如何测试的？

• 性能测试的场景是否充分？

• 性能是否满足市场使用需求？

低功耗验证