功能验证有着一整套完备的流程，而且从硬件系统定义贯穿到硅后测试部分。一般来讲，一个验证团队会基于时间差同时进行多个项目，多个项目之间自然也存在着借鉴、更新的关系，所以验证的环境和复用性也是在不断提高的。而每一个项目在进行瀑布模式的开发时，验证团队也会在不同细分的流程当中完成每一项任务，同时在进入到下一项任务之前也会进行一些重要检查点（checkpoint）的核对工作。又由于验证人员会不断地在新项目中提高验证环境，所以验证的周期也是不断往复、螺旋上升的过程。

上图就将功能验证的各个关键节点列了出来。首先验证周期的起始点是从创建验证计划开始的，而验证计划需要参照系统工程师给出的模块功能详述文档。接着验证人员会开发验证环境，在创建验证环境的过程中，验证人员一般会邀请设设计人员和系统人员一同回顾验证计划，确保验证计划没有明显的遗漏，所以验证计划的回顾是第一个检查点。

当验证环境准备完毕，而且已经有一些可供测试的激励时，验证人员会比对设计的输出结果和参考结果，在这一过程中，如果发现有比对结果错误的时候，验证人员首先需要自己去调试环境，并且定位到硬件HDL文件存在缺陷的大致位置。如果验证人员有充分的经验，他还可以进一步给设计人员修改代码的建议。

当硬件设计经过了一定数量的激励测试，验证人员就可以准备递归（regression）测试了。递归测试就是将已有的所有测试序列都执行一次，一般来讲，随机激励的递归测试要大于直接测试的递归，不过这种优势会随着验证完成率曲线的增长而变得不那么明显，具体的原因就是随机激励无法给出定向激励来填补剩余的验证空间，而直接测试则可以被有经验的验证人员运用恰当，用来验证边界情况。在完成递归测试之前，我们需要进行第二个检查点“验证代码检查”，这一检查点的作用就是一通来回顾验证代码以期发现可能遗漏的测试激励、不恰当的随机约束、代码结构的缺陷等。

在完成递归测试以后，我们进行第三个重要的检查点“流片前验证完备性检查”。一般这项检查是验证经理最后签字的，对于验证经理他会根据一份检查清单来将量化的验证进度综合评定，最后考虑是否已经完成验证的任务。当然，这一过程并非只有在流片前才会评估，而是发生在这一期间内若干阶段，包括模块验证阶段、子系统验证阶段、芯片系统验证阶段和最后的网表验证阶段，每一个阶段验证经理都有相应的通过标准和检查清单，来逐一判定出每一个模块、子系统和最终的芯片系统是否达到了验证的目标。

进而，在最终流片以后，验证团队也需要和硅后系统测试团队完成对接。这是由于，硅后系统测试阶段才是真正能够判定小到每一个功能模块大到整个芯片系统的各项功能能否正常工作的标准。通常来说，系统测试团队也会参考功能验证团队的验证计划，先从底部测试每个模块的功能，在逐步向上层走，最终测试整个芯片的联合功能。而在系统测试环节中，如果发生了功能测试失败，那么系统测试人员会同验证人员一同协作，最终来定位到是硬件自身缺陷还是测试中的环境配置或者寄存器设置问题。如果最终测试发现了硬件缺陷，那么硬件团队和软件团队也会一起评估该缺陷是否是不可修复的。一般针对硅后测试发现缺陷的情况，首先会考虑是否有软件修复的可能，其次才会想硬件上面有无变通的办法，当两方面都无法解决的时候，我们只能宣告，一个缺陷在硅后测试发现了。当然，比这还不幸的是，这个缺陷是一个致命缺陷。

在经过系统测试以后，验证团队会就最终被硅后测试发现的缺陷展开逃逸分析，来思考为什么漏洞会在片后测试环节中被发现。这其中可能引起漏洞在硅前验证阶段逃脱的情况包括有：

1. 验证计划制定不充分，没有覆盖完全功能验证点。

2. 激励序列生成不完全，没有完全覆盖可能生成的有效激励情况。

3. 验证环境不完备，例如比较器（comparator/scoreboard）没有足够完善判断设计的输出结果。

在展开逃逸分析之后，我们需要展开整个验证周期的最后一项检查点吸取教训。吸取教训是一种被动的方式，这是因为在已经完成的项目中我们犯了一些错误。如果我们不想被同一块石头绊倒两次的话（没有人会愿意吧……），我们需要吸取教训。这种被动的方式和我们主动去提高验证效率没有冲突，恰恰是在我们没有考虑到的地方学习，在我们考虑到的地方主动完善，使之成为一种内外结合提高验证能效的方式。在这里，我们给出一些关于吸取教训的建议：

1. 请在整个验证周期内保持收集突发状况、如何克服、陷阱从哪来、遗憾没有做到的事情有哪些等等跟验证完善有关的地方。之所以建议这么做，是因为我们通常在项目介绍以后会懈怠下来，而且我们的记性不足以记住事发当时的一些细节，还有我们可能会忘掉当时的一些心理痛苦。所以就像做一份验证记录一样，保持着这样一份完整记录，将来我们可以从中很快地串起来我们一路是如何走过的。

2. 除非有一些个别情况，否则验证缺陷的暴露会跟整个模块验证团队都有关系，因为我们可能一起制定的验证计划不够充分、一起回顾测试序列的时候也不够仔细、一起……所以在一起接受教训的时候，要想团队整体的疏忽在什么地方，每个人也因此需要考虑到自己在验证周期的不同阶段应该充分履行的责任是什么。

3. 尽量地从一些教训中去量化今后可以加强的地方。比如，功能覆盖率和代码覆盖率的指标如果是硬性的，那么验证人员就不应该做出妥协，应该想办法去达到这个标准，又比如一些跨时钟域的问题没有发现，或者在网表仿真的时候才发现，这种情况，我们就应该将跨时钟域检查、同步单元检查作为标准在验证过程中执行下去。

下一节我们依旧会带着大家深入验证周期的不同阶段，更近距离地感受验证在实际项目中的任务《验证的周期（中）》。

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

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