之前写过一篇文章关于芯片流片失败的原因,今天和大家聊聊芯片验证中的风险。
第一个,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)加入技术交流群,请备注研究方向。