1.前言
在 SoC 验证中，checklist是很重要的一步，要审视下有没有无意间漏掉的检查或者做出的假设。大部分情况下，checklist 总能发现一些 RTL bug，本文给出了检查的思考方向，希望对大家有用，也欢迎大家补充。
2.存在假设
- 对 TB 的假设
- 对 IP 只需要验证集成和基础功能就可以？
- 测试点分解时有做过哪些等价类划分？
- Memory 调试信号不需要看，有错的话，验证环境会报的？
- 继承的用例一定没问题？是 golden 的？
- 如果集成的 IP 没变，验证用例也不需要改动？
- 对 RTL 的假设
- IP 是成熟的？
- IP 功能没有修改？
- IP 是供应商交付的？
- 寄存器是脚本产生的，默认值应该不存在问题？
- 没有改动的代码没有问题？
- 不同层次验证是否使用相同的 RTL 版本
上述这些假设是否成立，我们该如何证明这些假设是成立的。
3.功能验证
- IP 的输入信号
- IP 的输入信号有哪些？是否每根信号都有覆盖过？
- 是否构建了多个输入同时触发的场景？
- 输入信号来源于哪些 IP，这些 IP 在各种低功耗场景下给我的信号正确吗？
- 输入信号来源的 IP 的工作场景和我负责的 IP 有耦合吗？
- IP 的输出信号
- IP 的输出信号值是否正确？
- 每根输出信号是否都正确连接到对应的终点？
- 输出信号是否是寄存器输出？
- 中断输出是脉冲还是电平？是否构建了多次中断，且中断是否能被正确消除？
- 掉电或异常时，输出是否会有毛刺或跳变出现？
- IP 的工作流程
- 只验证集成的，集成验证的层次是否正确？是否验证到了 IP 的接口位置？
- IP 的整体工作流程是怎么样的？
- 在整个工作流程中，时钟域是否正确，占空比是否合适？
- 复位域是否正确，复位宽度是否合适？
- 上电流程是否正确？
- 下电流程是否正确？
- 电源域是否正确，掉电钳位值是否正确？
- 如果有多个时钟源，是否构建了各种频率组合，特别是时钟源之间的最大频率差和最小频率差？
- 如果有多个电源域，是否构建了各种电源域的组合？
- 是否构建了多次上下电的场景？
- 上下电流程波形检查了吗？
- 是否构建了唤醒的场景？唤醒信号的宽度是否合适？
- 安全是如何管理的？
- 会有哪些异常，这些异常是如何管理的？
- IP 如果在样片上出现问题，该如何 debug 呢？需要的信号通过什么手段得到？如果同时发生其它问题，还能继续 debug 吗？
- 如果有一个访问挂死，会怎么处理？
- 总线反压是如何触发的？该如何解反压？
- RTL 代码我 review 过了吗？如果我是设计人员，我会如何设计这些代码？我考虑了哪些因素，目前的设计人员都考虑了吗？
- IP 中有异步设计吗？怎么做的？符合规范吗？异步两端的复位是怎么处理的？
- 多个 master 访问同一个 slave，访问的优先级是否正确，访问地址时怎么处理的？
- IP 的应用场景
- IP 的各种应用场景都覆盖了吗？
- 在各种应用场景中使用哪些输入和输出？以及如果出现了其它输入信号的跳变会怎么样？
- IP 对外支持的功能是否都验证到了？是否验证了一个功能多次触发的场景？
- 配置是否支持动态配置？
- 构建的应用场景是否全面，是否足够复杂，是否考虑了多种场景、异常的组合？
- 移植的验证用例我修改了哪些？为什么要做这些修改？其它不修改的地方是基于什么考虑？
- 所有验证用例都了解吗？每一行的作用都明白吗？
4.性能验证
- 这个 IP 的性能指标有哪些？如何测试的？
- 性能测试的场景是否充分？
- 性能是否满足市场使用需求？
5.低功耗验证
- 有哪些低功耗场景，这些场景都有覆盖吗？
- 这些低功耗场景是如何切换的(切换过程中是否有时钟、复位等的异常)？
- 各种低功耗场景对 IP 是什么要求？
6.网表验证
- exclude 的时序报错是否 review 过？
- 这个 IP 是否有一些需要综合 keep 的单元？网表中这些都还在吗？
7.后记
上述这些内容我已经整理成思维导图，有需要的话，可以在《专芯致志 er》公众号后台回复SoC关键字自动获取。
END
作者：谷公子
文章来源：专芯致志er
推荐阅读
更多 IC 设计干货请关注IC 设计专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
