下冰雹 · 2022年10月21日 · 北京市

IC验证中的风险分析

之前写过一篇文章关于芯片流片失败的原因,今天和大家聊聊芯片验证中的风险。

第一个,spec 理解错误。这个问题比较致命。有些bug是designer理解错了spec导致的,然后dv也理解错了,最终导致bug没有验证出来。另外一类是designer 理解正确但是写code引入了bug,dv理解错了spec,认为bug正常,从而导致bug没有修掉。

第二个,testplan没有列全。dv的后续验证行为都是根据testplan进行执行,很多时期bug没有验到是因为testplan没有列全。如何保证testplan的完备性?找designer 一起review不失一种很好的办法。

第三个,验证环境的架构不合理,这包括scoreboard 检查数据的机制不全,monitor到的信号不全,driver输出的激励局限性,random的数据可能局限性等等问题。从而导致漏验一些场景。

第四个,盲目相信code coverage。很多dv认为code coverage 收全design就大概率没有问题。实际上在我们的设计中很多时序问题靠code coverage是没法发现的。如果我们的function coverage也没有写全,此类问题很容易漏掉。

第五个,假pass,从而导致该验证的没有验证到。这类问题表现在验证环境可能有bug,自己没发现,或是 第三条提到的验证架构的局限性,导致bug没有验证到。

第六个,忽视了log中的warning或者是violation,导致一些有问题的design被放任不管,从而导致流片风险。

第七个,实际应用的场景没有验证到,验证的场景实际不会用到,这表现在写test的时候没有考虑软件的应用情况,比如某模块在实际应用中会被频繁调用实现某一算法,但是在验证的时候只考虑了单一场景,从而忽视在实际应用中可能存在的问题。

第八个,关注了模块功能,没关注模块性能,从而导致功能上没有bug,但是性能上有bug。

第九个,芯片验证中漏掉重要的检查,比如寄存器属性,reset值,模块 reset行为等等。从而导致bug漏掉。

第十个,芯片验证的文档缺失,bug管理缺失,导致有些bug虽然已经发现,但是没有提醒designer修掉,从而导致流片风险。

第十一个,一些验证人员关注RTL验证,但是在gate leverl simulation  和 power simulation 中缺乏经验,没有做全,导致一些时序bug 和功耗问题漏验。

除了上面十一条,在我们的验证工作中还有很多风险。如何做好验证,除了验证工程师自身的因素以外,还需要一套完善的验证流程。

作者:梨果爱秋天
文章来源:处芯积律

推荐阅读

更多IC设计技术干货请关注IC设计技术专栏。
迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。
推荐阅读
关注数
19297
内容数
1296
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息