IC数字验证的全流程经验总结

大家好，欢迎来到IT知识分享网。

https://zhuanlan.zhihu.com/p/?utm_id=0

本文是测试验证工作的方法论,软硬件通用,醍醐灌顶.

一、驗證目的

若世界上任何人都明白这个道理,就不会有xx语言xx技术之争了.曾我也误入误区,喜欢”华丽的招式”(如:新的语言/框架/技术等). 但究其本质,任何技术都是为解决某种/类问题而服务.需先明确解决哪类的问题及其技术难点,再去考虑使用什么招式是最佳的. 所谓”乱拳打死老师傅”,能搞定问题的方法就是好的方法.

最艰苦的验证是覆盖10%的corner case. 一方面要证明你的tc确实有用,另一方面要证明你的tc验证了实现者的意图.

二、验证视角

1. 测试至少要懂代码,懂分析逻辑,甚至全盘考虑问题,来发现需求实现人员的视角盲区
2. 测试可以站在用户视角上看待实现的合理性和问题
3. 作为软件,不但需要看这个某个接口调用功能实现是否是正确的,还要考虑到每个单步走各项值是如何变化的,什么原因导致这个变化的.每个变化是否符合你的意图.

三、淘金的执念

四、淘金的技巧

ARM ACP我猜测可能是各个BUG的表象点或易错点,那么通过观看此点的实现和测试用例,可以回溯出内部出现过哪些问题,为什么会出现. 另外,不要不屑于写tc.

表层土都差不多了，就需要找关键部分深挖了。如何找关键部分，是非常讲究的事情，兼顾风水、心理、外交、直觉等多方面知识，很难给出综合性的分析。下面几点可作为Hint：

1. 如前面所说的，只知道跑TC，跑错后让设计人员定位的验证人员负责的区域；
2. 对实现没什么概念的设计人员设计的模块；责任人变来变去的地方；
3. DFT相关的地方（验证人员的DFT知识严重缺乏）；
4. 规格老是变来变去的地方及其可能影响的地方；
5. 第一次做代码集成人员连接的顶层位置；浮浮躁躁、毛毛糙糙的新员工负责的地方；
6. 时钟域（几乎当前所有的验证人员都不关心时钟正确性，只要能跑TC）；
7. 所有人都认为没有问题的地方；验证人员宣称放弃的地方；
8. 技术难度比较高的地方；
9. 你以前项目发生过问题的地方（相同或类似的问题很大几率存在）；
10. 整个系统中相关性非常高的一连串区域；
11. 协议和时钟转换的区域；
12. 其他隐藏在内心深处的秘密。

这确实是个”综合性”学科,排查Hint也非常重要.仔细体会这些容易挖到金子的区域.分为几个方面:

1. 人不靠谱 -> 实现/测试
2. 模块不靠谱 -> 模块无人看管/责任人或需求频繁变更/验证人员放弃/技术难度高
3. 容易出问题的基础领域需要验证,否则会导致上层出现表因 -> 时钟域的例子
4. 大家都忽视的点 -> 所有人都觉得没有问题的地方
5. 曾经做过的项目出问题的点或该出问题概率极高的点(伟大的局部性原理)
6. 耦合性极高,正交性极低的区域 -> 相关性非常高的一连串区域/协议和时钟转换的区域
7. 有人藏起来的秘密 -> 多问问看相关开发

五、开门红

用一条tc来覆盖正常的冒烟通路,这样可以覆盖掉绝大多数的场景. 再逐渐考虑concer case.

六、检视

1. 年轻的设计不会认为自己的代码有问题.
2. 多用小黄鸭方法,解释自己的代码,自己多和自己抬杠
3. 不要有”不好的预感”,任何预感都要追根溯源认个明白
4. 最好有个checklist来检查
5. 不要因为不受待见,没技术含量而不重视.工程本就是双手沾泥仰望星空的事情,保持良好的心态.干困难的事兴奋,干验证的工作当休息就好
6. 偶然的问题,早晚会变成必然.墨菲定律.

七、检视的经验

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

1. hdl_stat统计整个模块代码行数，及各个子模块代码行数分配；
2. 打开代码顶层，快速浏览整个代码，获取这几个信息：代码风格、设计人员的思维成熟度、代码结构、重用度、逻辑类代码和集成类的分布、关键C Path和关键D Path的位置；
3. 按照现有的经验，其实已经大致能够推断出该模块整体的缺陷数量和缺陷分布了；
4. 先简后难，先扫除直接就能够看出的Bug，这种Bug分布比较散，没什么特别的依据，但很多问题，真的很简单，就在设计人员鼻子底下（不要超过2小时）；
5. 用Verilog构造最简单激励给模块，保留波形供对照，如有疑问，更改激励再仿（不要超过3小时）；
6. 然后，因为我有设计经验，我就会思考如果自己是设计人员，我会怎样划分模块、描述关键控制逻辑，如果和设计者不符的地方，着重分析；对识别出来的关键控制逻辑，例如异步握手、堆栈、链表、数据拼接，静下心来，慢慢看，慢慢看。对于疑点，构造简单激励，出波形对比。

7.2、拿模块Security Engine代码作为实例，检视如何进行

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，重点覆盖。

八、再谈检视

1. 中国国情,大部分写代码的都是刚入行的,所以检视发现问题的概率极高.相关,若都是非常有经验的工程师,那么概率就较低. 检视可以发现代码设计上的问题和一些重大的明显的问题,且时间成本极低.
2. 检视不能替代运行调试,但可以大大缩短问题收敛时间. 想想看,你对着一帮经验丰富的工程师来次代码思路的公开演讲和拷问,你对代码的熟悉程度肯定大大增加
3. 检视可以发现一些遗漏的问题和缺陷.这些缺陷新手可能不熟悉,而老手清楚得很.
4. 当你迟疑思考了,那么这地方很可能有大问题或者是个难点.需要重点检视.

九、重要的是人

1. 合适的人做合适的事,以及合适的搭配. 团队中识别那些人玩得好,每个人的性格特征来分配任务
2. 对于测试经理,也要因人下菜.

十、测试数据会撒谎

1. 确定环境正确,没有误操作,数值什么也都对. 最好让测试演示一次给你看.
2. 要从不同的角度验证出来的问题都要指向相同的方向才可靠,才能往这个方向走
3. 现场不可被破坏

十一、波形为王