复杂度缺口

这一缺口很容易理解，因为一旦芯片整体的复杂度提高，那么验证的复杂度是要高过设计的复杂度的，这种复杂度是固有的，因为……摩尔定律还在那里，尽管前些日子Intel宣称摩尔定律即将失效，这是考虑到工艺制程的物理极限而言的，但对于芯片集成度来讲，我们仍然不能乐观，因为科技总是向前发展的，而且硬件的性能提升一直在帮助掩盖软件没有充分发挥硬件性能的现实，而且这种尴尬的局面还将会持续相当长的一段时间。

技能缺口

这一个话题是离大家最近了吧。我们在之前《验证的处境》中就提到过一个例子，即VHDL、Verilog和SystemVerilog三种语言标准的出生年份、更新频率和实际使用版本，给大家说明验证的变化速度要显著快于设计方式的更新速度。自从设计实现了RTL设计到综合阶段以后，我们就再没有看到过硬件设计流程还出现过什么新鲜的事物，即便我们认为VHDL和Verilog是两种古董级的语言，但仍然改变不了一个事实，那就是我们现阶段还将依赖于它，除非各大EDA工具厂商推出新的设计流程并有效推广。相比之下，验证人员的成长史简直就是一个杂耍演员要掌握的各项技能，而且他们还将继续保持学习的状态不断学习新的技能，目前他们需要的验证技能包括有：

• 有深入地软件设计思想，包括如何去有效调试软件错误

• 扎实的面向对象编程语言基础

• 深入理解RTL硬件设计，是从硬件思想去理解并非从语言层面上用软件观点去“阅读”

• 有意识懂得硬件的结构和改动会如何影响验证环境的框架和相应的变动

• 断言语言（SystemVerilog assertion 或者 PSL）和功能覆盖（function coverage）使用

• 随机约束验证和懂得如何搭建一个验证结构

• SystemVerilog，最好也懂C和C++，在一些情况下，我们希望你懂Java

• 环境脚本语言，譬如仿真工具中的窗口命令语言TCL，Unix环境中经常使用的Perl，Python，Ruby等等

• 懂得怎么制定验证计划，包括从自然文字语言量化到如何产生激励向量和激励类型

• 形式验证方法和相应的验证工具使用

• 静态和动态的功耗相关验证

• UVM/OVM/VMM等基于SystemVerilog的验证方法学

• 基于图像的新型验证方式

• ... ...

面对这么多的要求，一位验证师必须要精通各项技能才有机会在复杂项目中灵活应用各种验证方式最后达成验证目标。而最显著的技能缺口就是验证工程师缺乏足够的软件技能，当然我们也能听到别的抱怨当一位有十余年经验的工程师在遇到越来越软件化的验证学时感叹道而今的验证方法变得太复杂了，他们反倒认为一个简单的验证环境可以实现更快的工作产出。上面这个例子是少数中的一个，越来越多的验证师意识到他们需要专门掌握更牢固的软件技能才有可能在验证方式越来越趋向软件化的未来有更多的竞争力。

面对实际的情况，我们面临的是大多数被招录到公司的验证师都是持有微电子学位背景的，但同时他们接受到的软件功能技能却非常有限。这种学校所教授的内容同实际工作内容的差别使得有一定工作年限的员工（3年以上）同刚入职的新人之间，在验证的技能树差别上面十分明显，也难怪会有一些论调称，他们宁愿有一个小而精的团队，也不愿意拥有一个大而新的团队。

从目前验证面临的挑战、自身的重要性以及对验证师的各种专业要求上面，都在抨击一种偏见，那就是“做得不好的设计师才会被派去做验证师呢”。不过就验证产出率而言，我们通过研究数据可以看到，不同验证师之间的产出率有着惊人的差别，一般是从2倍到10倍。听起来有点不可思议吧，但只有你愿意承认这一点，你才会跟自己做比较，变成是你过去产出率的10倍！

在实际中，有不少的例子是由于验证师缺乏足够的时间去掌握新的知识对项目产生的严重影响，甚至他们有时候都不愿意花时间问一些跟新的验证技术有关的问题或者寻求相关的资料和培训。而目前EDA工具商存在的一大缺陷就是他们的工具看起来是越来越花哨了，这一点从他们所谓的完整工具链就可以看得出来，那，是一张你看了觉得一辈子也不可能掌握得完的工具列表，而这一点对比起软件工程师常用的开发工具而言，简直是要令人发疯的，更何况这种糟糕的情形正在愈演愈烈。新工具或者以后工具的新特性带来的另外一个问题就是他们想不出一个好办法去推广他们。好吧……首先得让验证师们知道他们有这样一个特性或者一种工具是EDA厂商们还要花力气去做的。

项目进度缺口

从每一位验证师的口中都能够听到，项目进度太快，而且各种中间节点的进度要求也太苛刻，以至于不能有足够的时间去认真和执行思考验证流程中的环节。我们接下来看看验证师眼里项目进度把他们催赶到了什么地步吧：

• 没有时间制定一个更合理的验证框架

• 没有时间去编写验证文档甚至去做注释

• 以至于有时候连设计文档都看不到就开始验证而参考模型都是参考硬件行为的——这个真得太危险了！

• 没有时间去做验证代码的回顾检查

• 没有时间去优化改进以后的验证流程和框架

这种缺口一方面会让验证师不能严格按照验证流程走，另外一方面也不能留给验证师一些时间去充分阅读设计文档、标准接口文档、工具文档、掌握新的语言、新的验证IP……

针对目前芯片行业普遍存在的事实，我们可以做的比较可行的办法就是——兵马未动粮草先行：

• 在项目的预研阶段和早期阶段就构思验证框架、阅读所需要的工具文档和验证文档、同设计师、系统师一起讨论设计的功能。

• 在执行的过程中，如果时间进度非常紧张，那么你可以为以后提高产出率的实际办法就是，多花时间在验证上面，用更多的时间去主动提高验证效率，进而能够赶得上设计速度和项目进度，进而超过它，形成正向反馈。

• 在执行的空余过程中，譬如RTL仿真到门级仿真之间的一段时间，以及在流片以后的一段时间都可以用来编写验证文档、优化改进验证环境和填充自己的技能树。

质量缺口

关于质量缺口，有两个方面特别值得关注：

1. 芯片结构的成熟度和稳定性：很难想象如果一开始的硬件设计是建立在一个芯片结构还未被最终确定，仍然充满各种未知数和可能变化的背景下，这到底会为设计师和验证师带来多大的麻烦，而且这些未知的工作量是很难预计的。这种结构不稳定带来的未知数还包括不明确不完整的功能详述文档、可读性差的系统结构文档，这些不确定都会带来设计的不稳定和验证进度的严重延迟。

2. 验证环境的的质量缺口：实际指的是说验证环境是否可以提供足够的便捷性，无论对于验证师和设计师而言，他们都需要一个易用的环境，而不希望在验证环境上面消耗太多的时间。那么作为团队中验证环境的构建者，他需要注意到哪些方面来提供一个便捷环境呢？

1. 一个可以实现快速增量编译的环境。譬如设计代码或者验证代码中有某一行修改之后，只需要编译该文件以及相关的一小部分文件。这种增量编译可以更快速地去验证修改了的代码，而不需要花较多的时间等待完整的编译时间。

2. 最好有一个方便的集成开发环境（IDE，Integrated Development Environment），这种环境在软件开发中很常见，而在芯片验证师在构建验证环境的过程中还是个新鲜事物，目前有一种不错的开发环境DVT，是商业工具可供选择，此外，如果不具备条件的情况下，用户可以通过精细配置Vim环境来实现较快开发。关于开发环境我们也会在日后的文章中专门介绍这一部分。

3. 在仿真过程中有较快的复位和启动过程，目的是为了让被测设计可以很快地进入到测试设计功能本身的阶段。而这一部分的重要性会伴随着仿真的系统级别逐步变得重要，到了芯片系统级仿真的时候它的位置会被单独列为验证效率的评估部分。关于仿真快速复位和启动的过程我们也会在日后的文章里单独将这一部分。

4. 尽可能将功能测试下移至模块测试级别，因为这一级别的速度和效率是最高的。而随着验证级别的提高，我们给的测试用例数目和复杂度也会逐步提升，所以要懂得哪些部分应该在模块级测试，哪些部分应该在系统级测试。

5. 足够的运算资源的和网络速度。这一点是硬件上的资源，可是也不能忽略，因为在递归测试和系统验证阶段它们都是缩短验证时间的重要部分。

指标缺口

在验证过程中的指标，指的就是各项覆盖率的数值。这些覆盖率包括代码覆盖率、功能覆盖率和断言覆盖率。而在如何定义、收集、分析、反馈这些覆盖率的时候，也给我们的验证造成了一些困扰。

• 代码覆盖率：这是三项覆盖率中最简单的部分了。如果验证师遵循仿真工具的建议，在编译的部分添加跟代码覆盖率有关的选项，那么在递交了递归测试以后，每一项测试用例都会生成一份代码覆盖率数据。其后用户会将所有产生的数据进行合并，生成最终的数据结果。这些数据结果需要验证经理的检查，并且将覆盖率不满足的功能模块分发给对应的验证人员，要求他们给出生成新的测试序列，或者给出合理的解释。如此经过几轮沟通、数据再产生合并之后，直到代码覆盖率的数据值满足验证要求以后，这一环节才可以通过。

• 功能覆盖率：功能覆盖率是将验证计划的自然语言量化为功能覆盖率描述的方法。然而在实际功能覆盖率定义的过程中，我们有两方面的困扰。一是如何有效地将验证计划翻译为功能覆盖描述，这本身需要验证师对设计有一定的理解，而且也要考虑到翻译为功能覆盖描述的过程中是不是存在等价翻译的，如果一些功能验证信息没有被包括，或者功能覆盖描述本身包含了其它冗余无效的覆盖空间，这对于最终分析覆盖率都是一项额外的负担。另外一方面是，功能覆盖率在仿真收集的过程中本身是消耗仿真计算资源的，如果验证师疏于考虑收集数据的效率，那么甚至有时候覆盖率对于仿真的延迟低效是很明显的。

• 断言覆盖率：而今我们的设计师和验证师都有习惯在一些重要的逻辑检查、时序检查部位添加一些断言（assertion），然而这些断言可能为日后新的项目或者从IP到系统集成过程中带来一些麻烦。因为设计师和验证师在构建断言时无法考虑到各种可能的情况，而他们的验证环境也无法产生足够多的测试序列，那么这些当时看起来还很有效的断言在被随着设计和验证环境移植到新项目或者更高系统中时，就有可能出现误报一些情况。又由于断言一般都建立在时钟基础上，所以项目执行过程中，仿真被一些IP、标准库单元内置的断言或者继承子验证环境中的断言误报的错误信息“淹没”的情形不在少数。而面对这种情况，验证环境构建者需要花费额外的力气同这些断言的主人对话，澄清场景，禁止断言或者设计满足断言的情景让它们消停下来。

复用缺口

我们之前提到过，目前芯片之所以可以在更短的周期内完成集成，很大一部分要归结于IP化、接口标准化。设计师们在拿到一个第三方IP或者公司内部开发的IP时，他们一般会懂得标准接口在更高级别集成的方式，这对于集成而言是项有点，但这仍然无法避免设计师们要翻阅文档搞清楚接口的参数配置部分、如何使能IP的某些可配置的功能、接口的时序问题、时钟同步考虑问题、复位时序问题等等跟IP接口和配置有关的部分。对于验证师而言，他们要付出的工作恐怕更多，除了要付出设计师同样的知识掌握工作量以外，他们还要将设计IP对应的验证环境IP熟悉，懂得怎么使其在自己的环境中工作、在高一级的验证环境中集成、如何利用IP验证环境来产生自定义的测试序列。这仅仅是一个IP模块（可复用的）在硅前需要花费的工作量，对于硅后测试部分人员他们也面临着类似的处境。所以，复用一词仅仅还局限在IP本身，指的是IP可以通过配置和标准接口在不同客户的芯片结构中方便嵌入。而验证师在拿到一个新IP的时候，花费的力气并没有因为复用一词而有减少。所以对于验证师在面临IP验证环境集成的过程中需要掌握一些固定的方法，来快速集成、验证IP的集成。我们会在今后的IP验证环境快速集成方法中谈一谈这部分。

集成缺口

我们这里针对验证环境来谈集成缺口。在验证环境从模块级到子系统级再到芯片系统级的时候，一方面我们的验证环境会考虑复用集成，同时，我们的测试用例也会有复用的情况。相对而言，对于验证完备性的看法，验证经理会比验证人员保守，项目经理会比验证经理保守。而这种情况下，验证人员在环境集成过程中免不了会被派去做一些重复性的工作来保证验证完备性，要知道，整个验证团队的保守都是来自于担心是否有设计缺陷被隐藏起来了。所以，“你为什么不验这里？不会有可能存在的设计缺陷在这儿吗？”是一把双刃剑，一方面验证师会因为这句话朝着验证完备性看齐充分验证，另外一方面，也可能存在着“过量验证”的地方。过量验证在这里指的是一些风险较低的地方存在着重复验证或者收益率不高的验证工作量。这些地方就包括：

1. 硅后测试人员复用了大量的硅前测试用例，而不考虑哪些实际可以省略

2. 将模块级的测试用例又重复使用在了芯片系统级测试

3. 将模块级的参考模型集成到芯片验证环境中仍然保持小颗粒度的验证监测

4. 将模块级已经测试过的、连线测试过的或者其它方法测试过的功能点在芯片系统测试时又使用处理器进行二次测试

针对这些重复性的工作，我们的验证人员需要在集成过程中考虑哪些可以被略去，而把省下来的时间精力用在更有收益的地方。毕竟我们都知道一点，没有一件设计（更何况一个芯片）是无缺陷的（bug-free），而如何发现更多更有价值的缺陷，需要我们的验证团队“胆大心细”，将投入产出比放在心上投入到更值得的地方。

下节内容我们将会到处验证路上的伤与痛，给你带来一篇《验证长征路上的各种坑》。

您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证，并注明出处“路科验证”。