芯片验证全视之十一（终）：验证长征路上的各种坑

 Rocker 路科验证

到现在，我们都渐渐意识验证的重要性——你不经意埋下的坑会在未来硅后测试中被暴漏出来，进而导致可能重新流片。一些时候，我们的团队并不会严格遵循验证周期和各项标准检查表，而且有时候一些常见的错误也会使得局部模块的缺陷导致整个芯片的功能失效。

 

那么我们一一来细数在验证过程中我们容易犯的错误，按照坑深指数来看看哪些错误你可能经历过。

 

验证参考模型从设计中来 坑深指数 ★★

我们之前指出过，验证参考模型应该从功能详述文档中来，而非从硬件设计中来。否则，参考模型对于功能详述的二次翻译机会就丧失了，也因为并不会帮助设计人员一同理解功能详述和发现可能存在的问题。

 

验证先于功能文档开始 坑深指数 ★★★

在一些时候功能文档可能没有准备足够充分，而这时候进度的压力又迫使让设计人员和验证人员开始硅前设计验证工作，这会由关键信息的缺失导致没有可以参考的功能详述标准。同时这也进一步增加了沟通成本，无论是系统人员、设计人员和验证人员三方之间的沟通只能基于碎片零散的信息，伴随着进度的推行，这种沟通沟壑会越来越宽。在验证前期出了问题的时候，三方需要在功能不明确的地方口头沟通，而在后期验证的时候一旦发现问题，影响范围较广的时候，这又为可能出现的责任落实和问题根源地方上埋下了答案不明确的种子。

 

验证计划不够充分 坑深指数 ★★★

验证计划不充分有两方面。一方面是说验证人员由于自身对于模块功能的理解不充分，而列的验证计划有一些功能验证点缺失了；另外一方面是验证人员在将验证计划中自然语言描述转换到软件测试序列的时候存在缺失、或者转换到功能覆盖定义的时候存在覆盖域的不完整。

 

经验教训没有吸取 坑深指数 ★★★★

往往我们避免不了一个错误也不犯，但公司绝不希望我们在同样一个坑里掉进去两次。所以在每次硅前验证阶段结束的时候我们就会总结经验教训。往往这些经验教训是无法从一般的技术培训、日常经验中得到的，也是对我们项目在滚动执行中可以保持不断完善的最好课程。但仍然有些情况会让逃逸分析进行得效果不好或者干脆省略掉，而在这里我们需要指出的是，逃逸分析一定要做，而且最好在几个关键节点的时候就开始收集，这样可以为最终做逃逸分析的时候通过平日积累的素材来做经验总结，也为下一次项目和新组合的项目团队提供有价值的经验。

 

验证人员数量不充分 坑深指数 ★★★★

如果在一开始项目无法对验证量做出合理估计，那么验证人员的数量也自然无法有合理的安排。之前我们也讲过，验证经理对验证的估计是偏消极的，而项目经理正好相反，会偏乐观一些。如果双方在验证人员数量上一开始无法做到统一，那么过少的验证人员就无法按照验证标准完成任务，即便是完成了，也只是看上去完成了，很有可能没有发现一些功能缺陷而有待于硅后测试中被发现，这样反倒会造成更严重的问题。

 

验证完备性不够却迫于进度压力而流片  坑深指数 ★★★★★

往往在一些已经延迟的项目上，我们的执行层面迫于上层对于进度的压力而不得不将未被充分验证的芯片数据送出进行流片。在这里如果验证完备性没有通过，那么我们自然也无法保证流片后的硅后测试不会发生测试错误。而关于这一点，作为验证团队中的一员，你需要告诉给验证经理的是验证不充分可能会导致哪些功能的失效，进一步帮助他进行功能点失效引起的严重程度排列。如果在一些时候，按时流片的节点无法推迟，那么验证上面可以调整的就是将有限的时间用在失效影响更严重的功能点上面。作为验证经理，他也需要考虑如何尽可能地降低功能失效可能性、在固定时间内做一些优先级划分，保证基本功能通过、客户关心的功能通过、影响芯片全局的功能点通过。

 

至此，我们关于《芯片验证全视》的部分就连载结束了，希望我的总结能够让你对功能验证有了一些结构化的认识。我们的下一部分将会更深入地讨论验证的系统思想，且请关注《验证的策略篇》。