5对复杂的条件验证唯一_总结我的验证思路：代码检视是最容易发现问题的步骤...

代码检视是最容易发现问题的步骤，从写第一行代码开始，到最后一个Tag结束，都是如此。

代码检视不仅仅是设计人员的事，也是验证人员的事。我知道很多人都不认同这样的观点，正如我不明白为什么有些扫一遍代码就能发现的问题，有些验证人员还那么兴致勃勃、废寝忘食地编写TC，然后再辛辛苦苦跑TC来发现一样。

正因为我做过设计人员，所以我感受非常深刻，设计人员绝对都是极度乐观、自信的，特别是代码刚刚完成那一霎那，瞬间的快感，Oh，凤姐啊，芙蓉啊，让设计人员全身都在颤抖。破绽啊，这里有太多的破绽了。

所以对于新交付的代码，按照我的经验，建议验证人员先检视(尤其是设计人员是两年以内设计经验的)，不过，这个检视绝对不要是傻看代码，要跑一条TC，最简单的，就一个读写就可以了，保存所有信号的波形，然后打开Verilog代码，对照着波形检视。

1)所有信号全部抓出来看一遍，红色的(X)、黄色的(Z)，简单确认一下，然后Alt+Tab，切换到CMM页面即可(百试百灵，至今为止从未失手，nLint不是万能的)。

2)模块间的握手信号，全部抓出来看一下，是脉冲信号还是电平信号(98.765%的设计人员，都不会在信号名上注明是脉冲或电平)，脉冲信号是必须立刻采样的，电平信号是需要鉴沿的，如果握来握去，如果还有异步，基本上，检视出问题的概率非常高。

3)在一个always中，对多个信号赋值的；在一个always中，elsif数量超过6个的；在一个always中，if的条件组合中包括超过5个信号的；都是高产田。

4)协议理解上和自己理解相异的，例如对于我，AXI相关设计未按照我《AXI总线设计的二十一条忠告》的。

代码，是设计人员思路的直接映射，而设计人员的思路，有时候真的是一根筋。通过检视，或者加上设计人员的讲解，可以直接了解一下到设计人员的思路、逻辑思维模式，非常有助于去构造一些检测其思路正确或不正确的点，验证人员的思维其实很简单，抬竹杠就好。

请读者回忆一下刚刚经历过的项目，在100%网表之后，是否有好几个ECO，都是从检视中出现的(代码或脚本或TC)。而每一个这样的事件，都是那么神奇的偶然。可能是某位新员工周末偶然在学习老员工的代码时发现异常；可能是某人在项目经理逼迫下第三次检视某个模块时，惊讶地发现了一个低级错误；可能是某个IP交付团队某天突然想起说有一个连接的错误忘了改正，但幸好在ECO前发现。反正，总是奇迹一般，让项目经理觉得自己是世界上最幸运的项目经理。

明白了吗？我经历的多个项目，每次都有这样的奇迹，其比例占ECO的约30%～50%，这不是偶然，是一个说不清，道不明的必然。也许，只是100%后，同志们有更多的时间投入检视而已。

怎么能不检视？检视，在任何时候进行，都不算早，也不算晚。OK，这里就扯到另一个话题，某些同志经常反馈，检视工作非常不受待见。不做，没人管，做了，看不到绩效，即使检视出问题，也会有人跳出来说，“这么简单的问题啊”，特没成就。OK，我认为这是管理问题，典型的。无论对于海思的投资团队，还是对于项目经理本身，用最小的投资，或者说最小的人力、最短的时间，努力去发现项目中的问题的活动，难度不是最应该鼓励的吗？OK，如果你真有这样的感觉，我的建议是，将检视问题提问题单，再不济也是一个严重，发现阶段为ST，不用觉得害臊，害臊的应当是管理者。

此外，到最后阶段的检视，对于验证人员，可能需要更加地扩大视角，围绕代码为核心，TC、波形、脚本都需要涉及。对于这里，我还是再强调一遍吧。验证人员拥有设计人员所不同的视角，所以一定能够发现潜藏在其中的问题，对于单个项目而言，验证人员会认为是一个偶然，而从多个项目而言，我的经验，这是一个必然。

检视的经验：

OK，这里我可以再补充一下我个人检视代码的经验，我的步骤如下：

1)hdl_stat统计整个模块代码行数，及各个子模块代码行数分配；

2)打开代码顶层，快速浏览整个代码，获取这几个信息：代码风格、设计人员的思维成熟度、代码结构、重用度、逻辑类代码和集成类的分布、关键CPath和关键DPath的位置；

3)按照现有的经验，其实已经大致能够推断出该模块整体的缺陷数量和缺陷分布了；

4)先简后难，先扫除直接就能够看出的Bug，这种Bug分布比较散，没什么特别的依据，但很多问题，真的很简单，就在设计人员鼻子底下(不要超过2小时)；

5)用Verilog构造最简单激励给模块，保留波形供对照，如有疑问，更改激励再仿(不要超过3小时)；

6)然后，因为我有设计经验，我就会思考如果自己是设计人员，我会怎样划分模块、描述关键控制逻辑，如果和设计者不符的地方，着重分析；对识别出来的关键控制逻辑，例如异步握手、堆栈、链表、数据拼接，静下心来，慢慢看，慢慢看。对于疑点，构造简单激励，出波形对比。

OK，我拿我曾经的一个模块SecurityEngine代码作为实例，如果我进行检视如何进行。

1)代码行数约17000，行数最多的集中在几个整体控制模块：sec_ctrl(2235)、sec_slave(2121)、sec_channel(1669)、sec_master(1193)，除了这几个大模块，几个算法都分散为非常多小模块，相互调用搭成aes_core、kasumi_core等算法模块被顶层调用。

2)第一轮检视，快速浏览。各个算法模块的输入输出非常干净，都是通过run、done进行握手，其内部都是轮运输，通过round控制，其中aes_core还是纯复用以前项目的模块，而顶层几个ctrl模块，则相互交互非常复杂，特别是代码数量最多的模块，数据交互特别复杂的sec_ctrl和set_master，居然没有状态机，看起来设计人员是希望通过自己的逻辑思维，直接描述其控制；而sec_slave，纯寄存器描述，而且是大量复制代码搭建，技术含量低；结构上，sec_channel是一级控制，sec_ctrl和set_master是二级控制，各个算法Core是三级控制。代码风格上，设计人员部分遵守代码规范，但很多地方自以为是，为了自己方便写了不少擦边球的代码。

3)分析，aes_core理论上缺陷将很少，而其他几个算法Core，如果round控制上没有发现错误，那么错误通过RM比对验证，效率更高；然后，sec_channel，可以着重关注状态机和状态机对应的控制信号是否正确；最后，sec_ctrl和set_master的交互，一定是关键，特别是代码量大的部分。

4)第二轮检视，对算法Core的各个round控制信号检视，是否符合run、done控制；对sec_slave的寄存器读写控制检视，是否有笔误和拷贝的错误；检视整个代码集成和互联；简单查看其它代码中if和else比较复杂的地方，记录可能的疑点。

5)构造一条TC，正常而言，是通过sec_channel调配sec_ctrl完成一次算法运算(用最简单的Verilog搭建TB，超过2小时是否非常失败的事情)。根据波形，将sec_channel、sec_ctrl和set_master主要逻辑，全部过一遍。

6)关键逻辑，重点关注，关键疑点，修改TC，重点覆盖。

往期精彩

总结我的验证思路：发现Bug，发现所有的Bug，或者证明没有Bug，是验证存在的唯一目的

总结我的验证思路：心有多大，舞台就有多大

总结我的验证思路：只有疯子，才能发现隐藏得最深的金子

总结我的验证思路：“开门红” Test Case

转夏晶帖:总结我的思路,如何在验证中发现和定位Bug资料网址：http://bbs.eetop.cn/thread-274126-1-1.html?id=2930135447473&23=mV7I