IC验证之怎样通过波形来发现和定位Bug资料.pdfVIP

IC 验证之怎样通过波形来发现和定位 Bug 根据海思验证大牛一文《总结我的思路，如何在验证中发现和定位 Bug 》整理而得。 很多新晋的验证人员抱怨，这么多信号，这么复杂的连接关系，千头万绪，眼睛都看得长挑针， 还是看不出东西。 OK ，我说，这是没办法的事情，看波形，追波形，是一个经验积累的过程， 任谁都逃不掉。越是看，越是明白，越是不看，越是不懂。看得多了，自然就知道应该抓那些信 号，如何分类，如何追溯了。所以我奉劝某些希望通过全自动的 Log 和信息推导结果，或者每 次一有问题就找设计人员看波形的验证人员，回头是岸。波形， 是逻辑运行的最真实的表现， 逃 不掉的。 看波形首先有两个基本的看点。 先看 X 和 Z 。 任何一个波形，无论是验证的前期、中期、后期，到手之后，先刷屏，找 X 和 Z ，确认。某些 Z 和 X 是可以存在的，例如某些 IP 模型，或者未初始化的寄存器和 RAM ，但芯片开始正常后， Z 和 X ，都不应当存在。 OK ，我承认这个经验非常简单，某些高层领导可能认为这简直就是幼稚。可惜，可惜的是，我 至今为止看的，所有项目的波形，都能够在这上面找到 Bug ，甚至我可以预计下一个项目，我 继续看波形，还是能够找到。 以我自己设计的 L2 Cache 为例，一个多年验证经验的老员工负责验证的，至今已经在多个项 目中量产，还是在最近检查波形的时候发现有一个文件 wire 声明时把信号名写错了， 悬空了 （因 为该信号是 input ，隐含了 wire 声明，所以不影响功能）。 OK ，X 和 Z ，一定会存在，第一时间找到它，可以节省非常多的验证定位时间，否则追波形半 天发现是 X ，真是浪费青春。 X 和 Z ，所对应的 Bug ，可能有如下几种： 1 、 IP （包括 Memory 、PLL 、Serdes 等等）例化时，某些信号悬空未接。也许某些模型允许 Power 信号悬空，或者某些信号是悬空给 DFT 处理（当下给 DFT 处理的信号是接零），但大 多数 IP ，输入信号是不可悬空的； 2 、信号位宽不匹配、信号多驱动、声明的信号名称写错、 TB 级互联错误或 TB 中遗漏的 Force （额外小心隐藏的 Force ），不要相信 nLint ，特别是在芯片顶层或 3 、后仿真时序不满足时的 X 态传递； 4 、功能错误，某些模拟 IP 未能正确操作； 5 、功能错误，导致管脚冲突； 6 、功能错误，未能合理使用无复位端的寄存器和未初始化的 Memory 。 再看时钟。 很多验证人员不看时钟。 经过我反复的证明， 这是一个非常普遍的现象 （经常在项目验证后期协 助定位时钟不对齐导致的环境问题）。只要 TC 能够打印 Pass ，很多验证人员不关心时钟是否 有问题（甚至很多新验证人员，根本不明白 ? Delay 的概念）。大多数情况下，时钟不会有问 题？ No ，大多数情况下，系统验证，时钟都有问题。 记得以前在一个项目中推动 CRG 设计定义了一个规范，时钟分频寄存器，延迟 0.2ns ，其他寄 存器，延迟 0.3ns ，分频的原时钟，在输出前延迟 0.2ns 对齐，不知道看到本文的，数字平台 部的验证人员，有多少能明白其中的用意 ? 不解释，不明白的请自行蹲墙角反省。 再想起一个以前海思的设计规范，要求寄存器赋值，不可加延迟， 也是让人在风中凌乱啊。 下面 这个逻辑，寄存器赋值没有延迟，仿真能正常工作否？答案