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

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

曾经,有同事仿真挂死,抱着显示器看波形,看了两天,没有结果,给我,我看了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,可能有如下几种:

 

  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对齐,不知道看到本文的,数字平台部的验证人员,有多少能明白其中的用意?不解释,不明白的请自行蹲墙角反省。再想起一个以前海思的设计规范,要求寄存器赋值,不可加延迟,也是让人在风中凌乱啊。下面这个逻辑,寄存器赋值没有延迟,仿真能正常工作否?答案是可以!如果上帝比较仁慈,或者验证人员对仿真器的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!!找到直接引发挂死的点,或者和该点直接相关的起点,是很困难的,我不做这种类似分析双色球中奖率的事情,任何挂死的波形,第一时间能够获得的信息,都是表象。我会将任意一个被阻塞的操作作为起点,开始我溯溪的旅途(请确信,无论那个溪流,最终都会汇到唯一的源头)。如有可能,用笔在沿途做下记号,保证在偏离方向的时候能够返回。溯溪的路途有艰辛、险阻,我看过太多的兄弟在中途放弃,或另寻他路,而有时候,他离最终的源头,仅一步之遥,所以,最后一个建议,请保持一颗坚定和勇敢的心。有一首我喜欢的歌,范玮琪的《最初的梦想》,艰难的时候,可以听一下。

 

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

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

 

相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页