总结我的验证思路：怎样追波形

本文转自公众号“数字芯片实验室”，作者：夏晶。谢谢

曾经，有同事仿真挂死，抱着显示器看波形，看了两天，没有结果，给我，我看了30分钟，找到了原因；曾经，在同事已经仿真Pass，最简单的中断测试波形中，我找到了超过20个Bug（和中断测试无关）。所以有同事问我怎么做到的，所以引出了我写这个连载。在这个连载的最后一节，我最后分享一下，我通过波形发现问题，及问题的原因的一些经验。

一回生，二回熟。

很多新晋的验证人员抱怨，这么多信号，这么复杂的连接关系，千头万绪，眼睛都看得长挑针，还是看不出东西。OK，我说，这是没办法的事情，看波形，追波形，是一个经验积累的过程，任谁都逃不掉。爷爷都是从孙子走过来的。越是看，越是明白，越是不看，越是不懂。看得多了，自然就知道应该抓那些信号，如何分类，如何追溯了。所以我奉劝某些希望通过全自动的Log和信息推导结果，或者每次一有问题就找设计人员看波形的验证人员，回头是岸。波形，是逻辑运行的最真实的表现，逃不掉的。为什么我看波形快？无他，唯手熟尔。

先看X和Z。

任何一个波形，无论是验证的前期、中期、后期，到手之后，先刷屏，找X和Z，确认，某些Z和X是可以存在的，例如某些IP模型，或者未初始化的寄存器和RAM，但芯片开始正常后，Z和X，都不应当存在。OK，我承认这个经验非常简单，某些高层领导可能认为这简直就是幼稚。可惜，可惜的是，我至今为止看的，所有项目的波形，都能够在这上面找到Bug，甚至我可以预计下一个项目，我继续看波形，还是能够找到。以我自己设计的L2Cache为例，一个多年验证经验的老员工负责验证的，至今已经在多个项目中量产，还是在最近检查波形的时候发现有一个文件wire声明时把信号名写错了，悬空了（因为该信号是input，隐含了wire声明，所以不影响功能）。OK，X和Z，一定会存在，第一时间找到它，可以节省非常多的验证定位时间，否则追波形半天发现是X，真是浪费青春。X和Z，所对应的Bug，可能有如下几种：

IP（包括Memory、PLL、Serdes等等）例化时，某些信号悬空未接。也许某些模型允许Power信号悬空，或者某些信号是悬空给DFT处理（当下给DFT处理的信号是接零），但大多数IP，输入信号是不可悬空的；
信号位宽不匹配、信号多驱动、声明的信号名称写错、TB级互联错误或TB中遗漏的Force（额外小心隐藏的Force），不要相信nLint，特别是在芯片顶层或
后仿真时序不满足时的X态传递；
功能错误，某些模拟IP未能正确操作；
功能错误，导致管脚冲突；
功能错误，未能合理使用无复位端的寄存器和未初始化的Memory。

再看时钟。

很多验证人员不看时钟。经过我反复的证明，这是一个非常正确的结论（经常在项目验证后期协助定位时钟不对齐导致的环境问题）。只要TC能够打印Pass，很多验证人员不关心时钟是否有问题（甚至很多新验证人员，根本不明白∆Delay的概念）。大多数情况下，时钟不会有问题？No，大多数情况下，系统验证，时钟都有问题。记得以前在一个项目中推动CRG设计定义了一个规范，时钟分频寄存器，延迟0.2ns，其他寄存器，延迟0.3ns，分频的原时钟，在输出前延迟0.2ns对齐，不知道看到本文的，数字平台部的验证人员，有多少能明白其中的用意?不解释，不明白的请自行蹲墙角反省。再想起一个以前海思的设计规范，要求寄存器赋值，不可加延迟，也是让人在风中凌乱啊。下面这个逻辑，寄存器赋值没有延迟，仿真能正常工作否？答案是可以！如果上帝比较仁慈，或者验证人员对仿真器的always执行顺序无限了解。

always@(posedgeclkx2) clk <= ~clk;always@(posedgeclkx2) b<= a;always@(posedgeclk) if(clken) c <= b;

所以，在看完X和Z后，要将所有时钟拉到波形中Check，看是否所有同步时钟（包括1：N倍频）的时钟沿是否严格对齐，CLKEN时钟能够正确将倍频时钟上升沿罩住，关键地方寄存器赋值是否有Delay（如果时钟间不存在∆Delay，寄存器赋值可以没有Delay）。别小看这个工作，Pxxx验证组，记得哥当时被抓去协助定位了多少时钟问题吗？赔我青春损失费啊。。。。。。。。

OK，我们进入正题，怎样看波形。没错，楼上都是废话，谁再让我看波形，结果是上面两种情况，我就要发飙了。

如何在一个看似无限复杂的挂死波形中定位根因？

如何在后仿波形中发现可能的问题？

如何在表面上没有问题的波形中发现问题？

面对波形，首先要端正心态，不要认为看波形是浪费时间，也不要因为一时无法发现其中的问题而焦虑烦躁，更不要盲目乐观，认为已经没有任何问题。要执着、坚定，充满勇气。

先不要看波形，对，先不要看，这是我很重要的经验之一。要先思考，我的做法是对照架构图，虚拟一个芯片运转的场景，即在脑海中想像一下当前这个激励下，波形应当是怎样运作的，激励怎样进入系统，然后怎样完成协议解析和转换，怎样到达了总线，然后出现DDR的吞吐，然后CPU取指、取数，完成处理。OK，也就是说，先要在心中预留一个完美的Scenario，设想一下白雪公主和王子是怎样在城堡中幸福生活在一起的。

心中有了虚构的波形后，再使用Verdi打开波形。抓关键信号，分组，标识不同颜色，这些奇技淫巧应该不用多说，很多兄弟都比我这个验证原旨主义者来得厉害。只是需要说明的是，抓多少信号，怎样分组，很需要斟酌。其实原则只有一个，让尽可能精炼的信号在一屏内显示，这和代码的精简是一个道理。信号除了按功能分类，还要按信息量分权重。所以还是要说，很多验证人员，用着花哨的手指技法，一屏一屏的信号抓，刷刷几屏下来，跟瀑布一样，很是壮观，往往Group的数量比我总共抓的波形数量还要多。操，看个AXI总线，把arlock信号和arvalid信号一起抓出来，除了催眠看波形的人之外，有其他意思吗？以AMBA总线为例，APB先看PADDR、PSEL、PENABLE，AHB先看HADDR、HTRANS、HREADY，AXI先看各个通道ADDR、VALID、READY，如果这些信号不能说明问题，再逐步增加辅助信号观察，尽量保证在一屏中显示所有有效信号，如果信号太多，宁可删除部分。

然后，将展开的波形和脑海中已有的场景进行对照，看数据流是否按照脑海中预期的构想而流动。一般来说，实际波形和预想都不太能够对上，最开始的大多数情况下，波形是正确的，而脑海中的预想存在不足，这主要是因为我自己对架构的细节理解还不充分，对某些特殊逻辑处理方式不熟悉，或者某些逻辑相互连接后新增的耦合关系不了解等等原因导致。而这个时候，在我看来，也正是一个最好的时机，来进一步熟悉和理解芯片真实运转流程，弥补自己对系统结构、互联设计中各个细节的理解不足。在对细节的进一步理解和澄清的过程中，我会逐步修正心中虚构的波形，使其逐渐接近真实的运作。当然，在修正过程中，会出现某些确实表现异常的波形，一些明显出乎设计预期的时序出现。OK，这是一个岔路口，先记录*.rc波形现场，然后对该出乎意料的时序进行进一步深入追溯。正如前面所述，我常常在已经Pass的波形（或后仿波形）中发现Bug，通常都是从这样的岔路口开始的。也许这个岔路口最终证明逻辑没有问题，还是细节理解不足导致，但也许就是一个芯片难以发现的致命缺陷。

看到这里，也许有同志会问，挂死的波形呢？怎么还没追挂死的点呢？Yes，就是还没开始，无论是挂死的波形，Fail的波形，还是Pass的波形，在其实际波形和我大脑中虚构的波形没有完全吻合之前，我是不会开始定位问题的。这简直是浪费时间？嗯，在最开始定位的阶段确实如此，但在验证进入中后期之后，正常的波形和我虚构的波形已经调频到一个波段了，或者说，我已经确认白雪公主和王子开始幸福生活了。和波形到手，从前到后一扫，寻找那些地方异常，例如，白雪公主生下来的小王子永远长不高，那明显就是有问题嘛。然后，半小时发现问题，并不困难。当然，还是要说，我的经验，是不适合那些平时就只看Log，忽视波形的人的。

最后，我还是共享一些我定位复杂挂死波形的根因的经验。起点，定位挂死的起点在那里？或者说，从那里开始追？很多同志认为寻找一个合适的起点很重要，或者说最好直接就找到引发挂死的点。我说，No！！找到直接引发挂死的点，或者和该点直接相关的起点，是很困难的，我不做这种类似分析双色球中奖率的事情，任何挂死的波形，第一时间能够获得的信息，都是表象。我会将任意一个被阻塞的操作作为起点，开始我溯溪的旅途（请确信，无论那个溪流，最终都会汇到唯一的源头）。如有可能，用笔在沿途做下记号，保证在偏离方向的时候能够返回。溯溪的路途有艰辛、险阻，我看过太多的兄弟在中途放弃，或另寻他路，而有时候，他离最终的源头，仅一步之遥，所以，最后一个建议，请保持一颗坚定和勇敢的心。有一首我喜欢的歌，范玮琪的《最初的梦想》，艰难的时候，可以听一下。

最最后，再补充一点后仿定位的思路，供参考。

还是先关注时钟，每一个模块，clk和clken相位是否正确（PR有时会对时钟取反，需要注意）；
关注有门控功能的时钟和复位，确认是否存在毛刺；
把Top层所有管脚和oen、I、C信号抓出来。除掉红色黄色，观察有特殊变化的oen、i、c信号,尤其是和管脚值不符的,还有毛刺；
观察所有异步接口的时序，基本上都会发现毛刺。例如EBI、Efuse，确认毛刺是否影响功能；
观察顶层或Subsys独立处理的信号，特别针对还不够成熟的集成人员的特殊设计，例如testmode、rst_out、系统控制器特殊的配置和检测信号；
关注跨团队的模块，例如功能可控的MemoryBIST；
以上所有这些,MAX和MIN会有不同，要仿真Typical时序，并且确认以上的内容；
后仿的波形，需要结合Log中的Warning一起Check。

总结我的验证思路：怎样追波形相关推荐

【DV】arbiter 的验证思路
这篇文章是写arbiter 验证思路,可以借鉴... 对于arbiter 验证,目前有了解到几种状况: 1. 可以完全用reference model 来预期golden value; 2. 由于HW ...
个人观点的软件测试功能验证思路-前后分离
个人软件测试功能验证思路一.记录背景二.例举 1.画出基本结构图: 2.拆分功能内容: 3.验证拆分的功能内容: 4.具体操作流程: 三.附操作截图版本历史一.记录背景如果只进行单纯功能上的 ...
《VLSI仿真与验证》课程实验：TinyCore交叉编译验证思路
一.前言: 本实验是对一个基于RISC-V指令集的CPU核fwrisc进行功能验证.在宋宇鲲老师的<Verilog语言与FPGA实现>的课程实验中我们已经写过一个只有5条指令的8位CPU, ...
邮箱验证的思路及实现
邮箱验证一.开启POP3/SMTP服务 QQ邮箱.网易163邮箱均可.这里以网易163邮箱为例 1.注册163邮箱帐号,进入设置 1.进入设置的POP3/SMTP/IMAP选项 2.开启两个服务,I ...
十年磨一剑，两万字长文深剖析分享IC验证经验
有人认为我验证做得很牛,也有人认为我的验证早就丢下了:有人认为我发现了各个项目的不少问题,也有人认为我在CMM库的几百个问题单大部分属纯净水. 好吧,无论怎样,我还是把我在验证中如何发现和定位Bug的 ...
华为内部的关于IC验证的经验总结
华为内部的关于IC验证的经验总结 ----IC验证工程师的"易筋经" 有人认为我验证做得很牛,也有人认为我的验证早就丢下了:有人认为我发现了各个项目的不少问题,也有人认为我在CMM ...
Kaggle知识点：数据分析思路与工具（EDA）
Kaggle知识点数据分析在现有数据竞赛和数据领域中数据分析是重要组成部分,且数据分析与具体的业务背景和业务逻辑联系紧密.数据分析是发现数据规律的有效方法,也是验证思路的有效方法. 本文将以Kag ...
【STM32入门】这个项目绝了，用手势来产生波形，基于手势控制的波形发生器
大家好,我是张巧龙,之前有给实验室学生出了一道关于STM32的题:基于手势控制的波形产生题,题目简单,但综合性较强. 有些学生完成的还不错,个人觉得此题用来入门 STM32再合适不过了. 展示视频: ...
python进程join的用法_python 进程介绍进程简单使用 join 验证空间隔离
一.多道程序设计技术(详情参考:https://www.cnblogs.com/clschao/articles/9613464.html) 所谓多道程序设计技术,就是指允许多个程序同时进入内存并运行 ...

总结我的验证思路：怎样追波形

总结我的验证思路：怎样追波形相关推荐

最新文章

热门文章