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

发布时间:2018年11月29日 11:11    发布者:小编
关键词: 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。
欢迎分享本文,转载请保留出处:/thread-550735-1-1.html     【打印本页】
您需要登录后才可以发表评论 登录 | 立即注册

相关文章

回顶部
网站地图