太真实了！那些你不知道的IC验证日常-电子发烧友网

2023年初，Siemens发布了2022年Functional Verification Study。从中可以看到一些近年的验证数据，分享几点个人的愚见。

DE和DV的人数比应该是多少？

根据调查结果如下图所示，分别列出了近几年DE和DV的整体数量比，以及在不同规模领域内的人数比。整体看大部分项目中DE和DV的配比约为1:1。

结果远没有达到所谓的1:2，甚至1:3。甚至在超大规模的芯片项目中，DE的数量还会超出DV。

除了数量上没有达到，还存在一些"奇怪"的现象：DV的“被动”局面。在很多公司或者项目中，DV往往都是一种“被动”的角色。spec的改动或者code修改，DV大多都是处于被通知方，很少有DV能够参与到architecture或者spec修改的讨论中去，有些修改一般也不会征询DV的意见，甚至有些改动都不会知会DV。这种现象在大公司会有所改善，有着相对规范的流程。在小公司里，则尤为明显一些。

怎么办呢？没有什么好办法，不要“妄自菲薄”，合适的时候发出作为DV的声音，提升对业务的专业能力。时间在往前走，不要让自己的认知和技能在原地踏步。如果除了技术因素外，验证leader的风格有时也会成为重要因素:）

DV的时间都去哪儿了？

从图中可以看到，DV的时间的分配：

Test Planning, 13%

Testbench Development, 15%

Creating Test and Running Simulation, 21%

Debug, 47%

Others, 5%

为了对比，作者找来2016，2018年和2020的数据，对比如下：

从上述的对比可以看出，验证testplan的占比比较稳定，没有大的变化，占整个验证周期的13%左右。

Testbench Development的占比则是一直在降低，从2016年的22%下降到15%。脚本和其他的eda自动化构建，包括UVM的广泛使用，或许是testbench构建效率不断提升的原因之一。

Case的开发和仿真，2016年以来的数据，有些起伏，但也变化不大，仍占据整个验证周期的22%左右。而debug过程的占比，一直以来都非常之高，达到40%以上，在2022年的结果中，甚至达到了47%。

如果将creating case和debug统一来看，那么这一过程的趋势如下：

可以看到，验证的开发调试过程的占比是处于增长的趋势，在2020年达到了。随着诸如AI、自动驾驶等新方向的涌现，也会出现一些较新的领域，如安全验证等。随着芯片规模的增长，验证的复杂度和调式难度也在不断攀升。验证周期占整个项目周期的比例也达到50%~60%。

这里还有一个有趣的数据，如果我们把Testbench Development、Creating Test and Running Simulation和Debug看作是testplan的执行过程，那这一过程的占比近年来的数据分别为，2016-83%，2018-84%，2020-84%，2022-83%。看到这个数据，读者能想到什么呢？

二八定律。

虽然前面的testplan的耗时仅占比13%，但作者相信就是这13%的testplan或者testpoint规划，就已经确定了80%的验证完备性。

验证执行中，另一个二八定律是coverage的收集。DV都会有这样的经历，当coverage达到80%或者90%以后，就提升很慢了。最后的这10%或者20%的coverage，需要更多的投入，构建各种定向corner case。

[图片来源：DVCov2023 poster，Accelerating Functional Verification Through Stabilization of Testbench Using AI/ML]