IC设计验证

IC设计验证

做了多年的IC验证工作。经过学习和实践，对验证的理解零零散散也有不少，但总没法形成一个比较完整全面的经验谈。这里把我对验证的一些想法记录归纳，由于理解有限，下面的篇幅也许会比较零散。

一、验证对于IC的重要性

IC是集成电路的缩写，也就是我们常说的芯片；IC行业的技术门槛高、投入资金大、回报周期长、失败风险高，做一款中等规模的芯片大致需要10多人做1年半，开模的费用一般都在几百万，设计过程的笔误或者设计bug至少都

会有上千个，由于设计缺陷或者工艺缺陷很容易造成芯片完全变成所谓的石头，而如果要重新头片不但需要投入额外的费用，更会将芯片上市时间延后至少半年，这些风险对于商业公司来说都是不可接受的。

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

二、验证的目标

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

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

三、验证的两问题

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

1）我们要验证什么？

2）我们该怎么验？

这两个问题是验证的根本，就如同哲学里的“我是谁、我来自哪儿、我要去

哪儿”一样，“我们要验什么？”是给我们指明目标，”我们该怎么验？“则是告诉我们该采用什么样的手段去达到这个目标。

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

四、验证的三板斧

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

1）验证工具的掌握

验证工具包括vmm/uvm等验证方法学、sv/sc等验证语言、vcs等验证仿真工具、perl/python等脚本语言，这些东西是做验证要掌握的基本技能，不论你

做什么样的芯片都需要这些东西来支撑你的验证工作。

这些验证工具可以帮助你解决“我们该怎么验”这个问题，当你很好的掌握这

些验证工具后，你可以有很多种方法途径去达成你的验证目标。

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

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

2）算法/协议的理解

芯片要实现什么，不外乎是xx算法、某某协议，算法/协议才是芯片的魂。验证其实也就是验的算法/协议实现是否正确。就跟批改作文一样，只有批改者

有一定的文学功底，才能更好的评判作文水平。

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

3）验证的意识

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

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

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

·对问题要刨根问底

五、验证的流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·接口完备性确认，保证所有的接口时序都已覆盖，包括正常时序及异常时序；·覆盖率确认，分析所有的代码覆盖率、功能覆盖率，保证全部覆盖；

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

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

六、验证的后话

1）验证的空间

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

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

2）CDV验证

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

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

3）formal验证

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

4）环境自动化