可能在贯穿到整个验证系统思想里面，我们都会不断重复验证人员该具备的素质。为了可以将抽象的词汇具象出来，我们列出了验证人员在验证流程中需要具备的五个技术维度。接下来让我分别解释这五个维度：

• 完备性：该维度要求验证的充分。无论你从项目经理、系统人员、设计人员还是验证人员，大家谈验证首先提到的就是要“充分”。然而充分一词对于验证而言边界时模糊的，很难量化到什么时候才可以达到验证的完成标准。所以，作为一名验证经理，需要引入各种数据来综合量化出验证的进度，这其中包括了验证功能点的覆盖率，代码覆盖率，是否经过了低功耗验证流程（power aware verification），是否经过了跨时钟域检查等等。 通过数据量化，来对验证人员和验证经理增强足够信心来宣布某一个项目节点中，验证已经得到了“充分”的验证。当然，对于功能覆盖率部分，如何将功能描述文档充分理解，进而充分列出要测试的功能点并尽可能地细分出来，这需要系统人员、设计人员和验证人员的共同努力。同时，如何将抽象的验证计划转换到功能覆盖语言（SystemVerilog function coverage）需要验证人员具备该能力。

• 复用性：从项目的实际运用角度来看，复用性和完备性是同等重要的。没有人愿意会在下一个项目中将以前的验证环境做较大的更新，因为这意味着额外的资源消耗，包括时间、人力和项目进度的考虑。在硬件设计角度而言，通过标准总线协议，可以最大限度的讲模块之间实现相对独立和快速集成，所以对于目前项目进度不断缩紧的现状来看，一方面是市场的瞬息万变导致的，一方面也是由于SoC自身逐渐趋向于软件的快速周期迭代方式而成的。对于一个系列芯片而言，后续芯片的性能提高、功耗优化都是建立在前一代的基础上的，而这些不断地提高和优化具体到每一个硬件子系统而言，可能就是他们的存储大小、时钟快慢、动态电源开关、总线宽度、缓存深度来综合决定的，然而下一代硬件设计自身一般不会有第一代芯片的艰难历程（否则它也就称不上是系列芯片了）。 那么从硬件设计的角度来看，这些更新如果不会在逻辑上面有大的变动，那么带来的工作量是可以估计的。而从验证角度来看，我们也很自然地希望验证的工作量也不需要太大——可是事实并不一定是这样的。首先从芯片项目的集成性而言，设计人员相比较验证人员，在同一功能模块的稳定性是更高的，那么当一个验证人员在尝试阅读和修改上一个项目的验证代码时，就要看看他的运气。一般来讲，他的运气会跟上一个验证人员的代码风格有直接的关系……同时，验证人员在处理一些总线协议的时候要有意识引入参数来为日后的复用做好准备。而不断融合的验证方法学，走到今天，UVM（Universal Verification Methodology）之所以划分出不同的功能单元，实现小的颗粒度，提供快速插拔式的环境集成，也是为了复用性考虑的。

• 高效性：指的是用尽可能少的工作量来完成验证工作。在保证验证完备性的情况考虑下，实际上复用性和高效性会有存在冲突的可能。例如，验证人员会考虑如何“短平快”地在一个紧张周期内完成验证工作，但可能他不会采用UVM等方法学框架，也有可能他不会考虑将参数引入到验证环境中，因为这些“额外”的因素虽然是对复用性有帮助的，但是也会跟高效性有冲突。所以，验证人员需要针对不同的情况来在上述的五种维度之间做好平衡，至少需要保持一种意识，那就是工程学的执行阶段本身就是一种平衡，对于验证人员来讲，他需要作出的判断就是在每一个项目每一项验证任务中做好取舍，来给出一个合适的验证考量维度。甚至对于同一项验证任务而言，采取不同的验证策略也会有不同的完成效果。例如，一开始考虑采用随机约束的验证方法，那么单单就约束而言，它的约束一开始是比较窄合适，还是一开始比较宽宽合适？
  这里我们再给出一张示意图来说明高效性实际上在不同的验证方法和同一个验证任务在不同状态时都需要有相应的变化。因为在开始阶段，考虑到设计不够完备而且尚未经历过验证，我们一开始的阶段称作基本功能验证阶段，这个阶段，我们会将随机约束域降低到基本范围，尽可能少的触碰到边界情况，而把重点放到如何先将各项基本功能都验证到。第二个阶段是在我们已经完成基本功能验证以后开始的完备功能验证，这时我们就可以逐渐放开随机约束域，而开发的速度跟合适能够设定最终的开放域范围需要验证人员充分考虑到各种合理的情形再做约束域的限定。而当了功能覆盖率一般上升到80%附近的时候，这就处于了最后的爬坡阶段，这个时候，如果再沿用之前广泛的约束域，那么会产生很多无效的随机种子，这些“无效”的随机种子基本对于剩下的验证覆盖率完善没有什么帮助，那么这个时候验证人员就需要通过理解设计本身和随机产生的约束两方面来考虑具体贡献覆盖率的测试序列，再进一步缩窄随机约束域，来定向（biasing）产生一些激励，对于最后的这一阶段，一种极端的情况就是将随机约束域缩到尽可能窄的情况，甚至和直接测试（directed test）没有什么区别。
  
  
  

• 高产出：指的是在一定的时间，可以调试、报告、帮助修正出多少个设计缺陷，以及可以建立多么完整的验证环境。多年来数字硬件设计（RTL级别）的基础并没有发生太多变化，同时EDA厂商提供的自动化工具又进一步提供了便利，提高的设计本身的可靠性。但是这一情况却并不适用于数字验证，因为EDA工具目前仍然只能作为辅助手段，例如提供更多方便的调试功能和接口，却不能也随之自动化帮助建立复杂的验证环境。这也就不难解释了2014年Wilson在功能验证领域的调查数据显示，今天在设计和验证领域面临着最大的挑战之一就是为快速的芯片产品和员工数量增长之间找到一个平衡点， 实现单位产出的提高。

• 代码性能：关于这一点要讲详细一点，需要专门开个话题。代码性能似乎也跟高效高产出有冲突的地方，因为对于验证代码的整洁性、复用性甚至一点点地美感都对于数字意义上的验证完备性没有直接联系，这也包括你的验证经理可能有好长时间都不会注意到你写的验证代码，除非有一天你验证的那个设计出了一个缺陷，而且是一个显而易见的缺陷却没有被发现，这可能才会引起验证经理的注意专门来访问可能是一团糟的代码结构。 但是每一位验证人员也需要记住一句台词“出来混迟早是要还的”，无论是你在看着别人写的验证代码没有注释、没有缩进、超长if-else判断语句等等这些让你已经无力吐槽是时刻，还是你因为项目紧张快速搭建验证环境和编写测试用例的时候没有考虑到“后来阅读者”和“你后来阅读”而偷的各种懒，相信我，时间会让你为此买单的。所以，作为一名验证人员，请在你写每一行代码的时候把它当做你日后行业名声的荣誉墙，尽管你还在迫于项目的压力快速建立环境疲于完成验证，但等到你有闲的时候会去再改善那些代码吗？不要再相信这些鬼话了，现在就去做吧！

从上面的五个维度来看，做一名合格的验证人员实属不易，更不要说考虑到每一个项目每一项验证任务来分别针对制定出合适的五个维度指数。虽然项目执行没有尽善尽美，但是针对验证人员自身，如果可以意识到这五个维度的存在，并且能够在实际工作中都照顾到它们，运用到验证任务的考量当中，那你就是有意识地在培养自己成为一名验证师了。

下一篇中，我们会带着大家纵览《验证的任务和目标》。

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

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