673
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关键字自动获取。
[下载]LAT1482 STM32G0单线串口通信帧错误问题解析
