本文主要是介绍细数EDA动态仿真验证的七宗罪，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
令人意外的是，7nm->5nm->3nm->2nm，摩尔定律还在前进。但从验证的角度来看，这并非好事。
因为单位面积能够容纳更多的复杂逻辑，从而提高了整个芯片在硅后发生功能BUG的可能性。
验证是整个芯片研发过程中非常关键或者说瓶颈的一环。没有验证，就像是足球队没有守门员。与此同时，对于芯片的上市时间（time to market）要求越来越短，因为市场上的竞争压力越来越大需要尽快将产品投入到市场获得更多的利润。可以说，目前芯片想要做到完备的验证是一件非常困难的事情。
使用EDA动态验证方法进行验证主要包括以下内容：
•针对待测设计（DUT）创建一个测试平台（testbench）。
•编写定向或者随机的测试用例，以激励待测设计的输入、检查待测设计的输出，同时统计待测设计测试点覆盖的情况。
•执行所有的测试用例。在此期间会不停地调试待测设计和测试平台，最终使得验证sign off。
但是，这种EDA动态验证方法方法有许多缺点，也就是这个标题党文章的标题所述，EDA动态仿真验证的十宗罪：
•Testbench的开发可能是一个漫长的过程，通常复杂设计的验证平台开发需要几个月
•Testbench开发非常容易出错，通常测试平台中的BUG数量会多于待测RTL设计中的BUG数量
•执行测试用例非常昂贵—需要持续地利用服务器资源/硬件加速器/FPGA进行回归，直到芯片最终tape out。
•测试用例本身可能包含一些错误，这些错误可能会误报或者漏报RTL中的BUG
•调试Fail的测试用例会消耗大量的精力，会是占据验证工作最多的组成部分，因为报出Fail的地方和实际BUG的根因可能离得很远，很难定位，就跟洋葱去皮的过程一模一样。
•很难说执行了多少测试用例才能证明设计是没有BUG的，即EDA动态仿真只能证伪。
•一些BUG可能是data-dependent，即触发条件非常苛刻，几乎无法在RTL模型上使用随机测试覆盖到。即使是覆盖率驱动的随机测试也做不到完备验证，不然Intel CPU怎么会有BUG，是因为对芯片验证不够重视？
这篇关于细数EDA动态仿真验证的七宗罪的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
