IC验证工程师总结的经验谈

在学校时就对IC有着浓烈的兴趣，毕业后也如愿做了IC验证工作。经过2年的学习和实践，对验证的理解零零散散也有不少，但总没法形成一个比较完整全面的经验谈。这里把我对验证的一些想法记录归纳，由于理解有限，下面的篇幅也许会比较零散。

1 验证对于IC的重要性

IC是集成电路的缩写，也就是我们常说的芯片；IC行业的技术门槛高、投入资金大、回报周期长、失败风险高，做一款中等规模的芯片大致需要10多人做1年半，开模的费用一般都在几百万，设计过程的笔误或者设计bug至少都会有上千个，由于设计缺陷或者工艺缺陷很容易造成芯片完全变成所谓的石头，而如果要重新头片不但需要投入额外的费用，更会将芯片上市时间延后至少半年，这些风险对于商业公司来说都是不可接受的。

正因为芯片的高风险，才凸显了验证的重要性。在流片之前，通过验证人员的验证活动发现所有的设计bug，这就显得特别重要。

2 验证的一目标

做验证首先要明确我们做IC验证的目标是什么。上面我们已经提到，由于芯片的高风险、高代价，才更突出了验证的重要性，尤其是芯片规模越来越大，逻辑越来越复杂。

为了保证芯片的成功，验证唯一的目标就是发现所有的bug，做到无漏验、零漏测。

3 验证的两问题

作为验证人员，首先要搞清楚两个问题：

1）我们要验证什么？

2）我们该怎么验？

这两个问题是验证的根本，就如同哲学里的“我是谁、我来自哪儿、我要去哪儿”一样，“我们要验什么？”是给我们指明目标，”我们该怎么验？“则是告诉我们该采用什么样的手段去达到这个目标。

如果这2个问题都没搞清楚，那么没人对你负责验证的模块有信心，毕竟你自己都不知道你的目标是什么，不知道该怎么做才能达到那个目标。这两个问题是验证的核心所在，如果想做好验证，这是前提。

4 验证的三板斧

要想做好验证，保证无漏验、零漏测，以下三个要素是必须要具备的：验证工具的掌握、算法/协议的理解、验证的意识。

1）验证工具的掌握

验证工具包括vmm/uvm等验证方法学、sv/sc等验证语言、vcs等验证仿真工具、perl/python等脚本语言，这些东西是做验证要掌握的基本技能，不论你做什么样的芯片都需要这些东西来支撑你的验证工作。

这些验证工具可以帮助你解决“我们该怎么验”这个问题，当你很好的掌握这些验证工具后，你可以有很多种方法途径去达成你的验证目标。

说实在话，验证工具的东西很多，要想在短时间内全部掌握也不可能，而且很多工具可能在你的验证过程中不会用到。

个人对验证工具的一点感悟是：不要贪求全部掌握，你可以先看书学习实践，把这些东西都学习一遍；在学习的过程中你肯定会发现一些好东西（原来还有这种方法可以让我的xx做的更好）；对于那些暂时不知道怎么应用到实践中的东西，你也不要认为它们是没用的，其实只是你不知道用在哪儿而已，在你以后的验证中也许就会发现它的应用场景，当你需要它的时候也许你已经忘记怎么用了，这个没关系，你可以再回去查阅资料，这个相信很快就能解决的，这样有个好处是当你碰到可以用xx的时候你至少能想起曾经看到某个东西可以来实现它，如果你从未学习过，那么你根本就不会想起有这么个方法可以解决它，这才是可怕的，我都不知道这个问题是可以被解决的。

2）算法/协议的理解

芯片要实现什么，不外乎是xx算法、某某协议，算法/协议才是芯片的魂。验证其实也就是验的算法/协议实现是否正确。就跟批改作文一样，只有批改者有一定的文学功底，才能更好的评判作文水平。

因此，验证人员对算法/协议理解越深刻越好，要理解算法的原理以及算法的实现结构，只有这样才能找出其中的corner点。

3）验证的意识

验证的意识究竟是什么，其实我也说不清楚，只能按照我自己的理解写写一些。

· 对任何东西都要有质疑的态度

· 手要伸长，延伸到上下游

· 对问题要刨根问底

5 验证的流程

做任何事情都需要按照一定的流程来走，否则很容易陷入混乱之中，尤其是对于刚入门的新手来说更是如此。我目前接触的通用流程大致如下：

1）提取测试点，明确验什么

· 分析FS/浮点平台，提取芯片的规格及测试点；

· 分析AS/定点平台，提取测试点；

· 分析DS，提取测试点并识别asic与算法的不一致点；

2）制定验证方案，明确怎么验

· 刷新测试点列表，明确测试点的覆盖方式：功能覆盖率、代码覆盖率、直接用例；

· 验证环境的搭建策略，这个步骤是可以做成自动化工具的；

· 验证的重点难点，提前识别重难点，并制定相应的对策；

· 刷新用例列表，明确测试用例的方法及步骤；

3）用例执行，随机测试，发现bug

· 执行直接用例，发现大部分的bug；

· 带随机的大量测试，试图撞出bug；

4）完备性分析，确保无漏验

· FA/AS完备性确认，确认FS/AS中的所有点都已纳入测试点，并确保已被覆盖，包括应用场景；

· 接口完备性确认，保证所有的接口时序都已覆盖，包括正常时序及异常时序；

· 覆盖率确认，分析所有的代码覆盖率、功能覆盖率，保证全部覆盖；

· 代码分析，熟练掌握电路的实现逻辑，保证所有的电路corner都已覆盖；

上述这几个步骤是一个比较规范的流程，只要每个步骤都做好，基本就能做到无漏测、零漏验。

6 验证的后话

1）验证的空间

作为验证人员最希望的情况是：把所有的激励空间都覆盖到，这样就绝对能保证无漏测、零漏验。但实际情况是：芯片规模越来越大，其激励空间近乎无限，同时EDA仿真的速度奇慢，根本无法实现全覆盖，即使是FPGA、EMU等仿真加速器对此也是无能为力。

因此，合理划分激励等价类是相当重要的，但这也一直是验证的难点所在，很多情况下根本就没法分析清楚等价类。

2）CDV验证

CDV就是覆盖率驱动验证的意思，就是写一大堆覆盖率（断言覆盖率、功能覆盖率、代码覆盖率），只要这些覆盖率全都达到的话则表示验证已经完备。

这是我们的目标，其前提是分析清楚我们的测试点覆盖空间，这个分析也是让人头痛的事，没有谁敢拍着胸脯说这个测试点空间是完备的。

3）formal验证

传统的仿真都是动态验证，由于其仿真效率低下无法遍历所有空间，formal这种静态的验证手段则可以遍历所有空间。不过在目前这个阶段，formal还只能适用于百万门级的模块验证，同时目前市面上的formal工具大多要么只对控制逻辑支持较好，要么只对算法逻辑支持较好，几乎没有一款formal工具能完美支持所有的电路逻辑。

4）环境自动化

在验证过程中，搭建验证环境是一个机械性的劳动，但有时候又比较耗费时间而且容易出错，因此把验证环境做成自动化工具，还是能提高不少验证效率的。

5）全部使用直接用例

从验证流程中可以看到，用例执行过程中大部分bug在直接用例过程中被发现，但还有一部分隐藏比较深的bug只有通过随机激励来发现。

这里存在一个问题，随机测试是不可靠的，有很大的概率发现不了隐藏的bug，对此可以有两种方法：

一是采用带约束的随机，这样可以更好的达到边界点，这同样存在概率性问题；

二是所有的corner点全部用直接用例覆盖，这些直接用例执行一次即可发现所有的bug，根本不需要进行长期的随机测试，这要求我们能识别出所有的corner点；

方法二是我们追求的目标，全部用直接用例覆盖，取代长期随机测试，可惜愿望是美好的。

6）复用的东西都BB化

在芯片设计中经常回重用以前的模块，这样不仅加快进度，而且能降低出错风险；但是对于验证人员来说，复用并不一定是好事情，经常会出现这样的事情：由于是复用之前的模块，所以在验证的时候会掉以轻心，结果埋下bug。如果把复用模块当做全新模块来验证，这又要花费大量的时间，可能就会延后芯片的投片时间。

对于复用的模块，验证人员也可以把验证的相关东西做成BB化，后续芯片复用该模块时，也可以复用该验证BB。