日志
验证的管理篇之七： 验证的专业化
| ||
人们对一个行业所产生的偏见多半是由于没有亲身体验过，而在芯片领域验证所接收到的偏见也丝毫不少于其它行业所面临的窘境。在每次新开学与我的学生们交流的时候，他们对于验证的理解仍然停留在当初学习VHDL或者Verilog所学到的通过一个简易包装的测试盒子，固定的激励源和细致的时序激励调整来测试设计。当我在第一堂课将数十种以上的验证方法列举出来的时候，一看他们的神情便知道他们对此的一无所知。这么看来，象牙塔里的教育要落后工程界很多年，要知道那些老套的验证方法从十多年前就一直是那样教育的啊。
对于验证的偏见
让我们将目光再切回到企业，而即便是企业中，从执行层到管理层对于验证的偏见也一样不见得少，常听到的和看到的有下面的情形，读者可以对照一下自己的所见所闻，看看言中了几点：
- 公司A目前的设计复杂度低，而且有面向市场的压力，所以他们更愿意将设计做完经过简单的测试直接将原型通过FPGA来实现和测试，至于RTL验证的投入，还少得可怜。
- 公司B的验证平台已经有很多年没有更新过了，尽管设计越来越复杂，但是因为一直缺少经验丰富的验证师来更新换代公司的验证平台，所以在新的项目开始尽管能听到越来越多对于验证平台老旧不方便的抱怨，项目管理者还是以缺少合适的人力来理由，让大家通过加班来弥补验证平台的硬性资源缺失。
- 公司C没有专门的验证团队，而验证的工作几乎是公司内部的设计人员之间互相合作验收的，至于验证标准、计划、环境、文档缺失验证，所以设计师也同时担任了验证师。如果你们设计师验证是否困难，他们会回答，这不就是添加激励，看看行为是否异常吗？看来，设计师心中的设计工作一直是最需要受到公司关注的……
- 公司D的验证师团队整体实力与设计团队有不小的差距，通过分析我们可以发现该公司的验证团队是将公司不合格的设计师和新进公司的人员拼凑成的团队。公司的管理层认为，验证的好处不单单是可以发现一些漏洞，还可以让那些做不好设计、暂时没经验的人先到验证环境去熟悉情况，至少不会因为一些简单的错误给设计种下一些严重的漏洞。看起来，公司D的验证团队接收到的是一种隐形的“二等公民”的待遇。
- 公司E的设计团队和验证团队比较健全，然而他们之间的沟通经常不顺利。当前期验证发现一些漏洞的时候，还可以跟设计人员探讨修复漏洞的问题，而到了项目后期如果再发现什么严重的漏洞，设计人员就表现得没那么愉快了，除了抱怨漏洞怎么到了后期才发现，还因为发现漏洞以后设计要做更多的修补工作才有可能不影响项目节点，这无形中增加了设计修正的难度。
我们暂时找不到这种对验证的偏见的历史根源在什么地方，但恰恰是一开始设计复杂度低而验证也简单时，这种对于验证技术含量低的错误认识从很多年以前就积累了下来，以至于无论在教材、工程应用书、学术论文还是从管理、公司技术路线层面都让验证缺席了很多年，得不到该有的尊重。这些问题积累下来对任何一方都没有什么好处，最直接的是影响公司芯片的质量。我们再回过头来看看上面举例的几家公司一些错误认识具体在什么地方：
- 公司A虽然看起来在用FPGA可以快速得到测试结果，但是更多地是将设计作为黑盒验证，缺少内部信号的检测调试、同时也缺少随机激励的场景来达到验证的完备性。
- 公司B为什么缺少合适的人？深层次的原因恐怕跟对验证不重视有很大关系，如果一开始从验证人员招聘和后期对验证贡献的充分肯定上入手，那么验证人员的培养不会比设计人员滞后那么多。
- 公司C除了对于设计师的验证能力充分“信任”之外，也没有觉得验证师一项单独需要培养的技能。而真正的事实是，验证确实不是一项技能，而是许多项的综合技能。
- 公司D看起来倒是通过这种小聪明使得那些烫手的员工没有做出什么可能让公司无法挽回的损失，但除了让员工被感到不信任之外，公司又如何能够保证他们的验证工作就做的足够好发现的漏洞足够多？要知道，设计种下了漏洞，如果没有被发现，那么在没追究是哪一方过错之前，公司的损失仍然无可挽回，这也已经是一种事实了。
- 公司E的设计师越到后期越不情愿听到自己的设计被发现漏洞，而且和验证人员沟通起来也都颇为困难。除了对于设计和验证的关系需要正确理清之外，该公司也得多鼓励鼓励验证团队让他们在关键时刻可以顶住压力，该报出的设计漏洞需要义无反顾的提交，公司也应该打开香槟庆祝。当然不是为了又一个加班的夜晚做设计补修，而是庆祝又一个漏洞在流片之前被发现，为公司挽回了隐形的损失。
验证面临的现状
芯片业对验证的偏见不单单来源于公司和业界的成见，就连之前提到了教育行业也是如此。高校的教育与芯片行业的脱节在这近十年以来越来越验证，当我问同学们是否学习过面向对象编程语言的时候，在场的近百位同学有只有两名举起了手，其中一名还问我，为什么要学习一门软件编程语言？这种芯片设计有何关系？国内顶尖的微电子高校研究生在本科期间缺失的专业教育可见一斑。
我在为同学们选择教科书的时候，也实在是捉襟见肘。最直接的限制就是国内芯片验证领域的书目严重缺少，而国外优秀的图书又缺少引进和翻译。对于已经深入到验证行业的人，业界优秀的图书本身也与实际工作联系不够紧密，而大多数人又缺少时间和资源来查阅每年最新的关于设计验证会议上的验证领域论文，再加之国内本身缺少验证行业交流的大会，使得工程师在验证经验积累和技术突破上缺少可以互动交流的平台。
可验证师们不能因为缺少这些资源，而不去发声、不去呐喊。验证师也应该从幕后走到台前，无论在公司内部、业界形象、教育领域都能够将验证职业化、深入化，同时积极参加与验证技术有关的会议，发表论文，针对各种复杂的芯片验证问题展开交流。实际上，设计之间的交流可能会有泄漏公司秘密的风险，而验证则不然，它完全可以将设计的功能属性在表述问题时简化，将问题主要停留在解决验证复杂性上面，如此更加有利于验证的交流。同时，随着目前个人知识传播的兴起，有望借助验证领域技术专家的订阅号、网络直播来开展更深入的项目问题讨论，传播关于验证的文章和项目经验。
就公司自身而言，在验证师的职业发展路径上，需要给出明确的信号，不但需要作出及时的赞赏、认可，也需要就验证职业发展给出清晰的路线图，让新员工和有经验的验证人员懂得，长期在验证领域深耕一样可以同设计师作出同样重要的贡献，甚至更多。验证经理也需要在公司内部多推广验证的理念、宣扬其价值重要性，而项目经理也应该具备基本的验证知识，尤其在分派验证工作、评估验证工作量、回顾验证质量时可以有客观合理的认识。
验证标准化
验证领域如果需要得到更清晰的认识，就首先需要将自身的流程标准化、量化，就想软件测试的环节一样。对于一个验证团队或者一位验证师，他如何可以表明自己足够优秀？对于一个团队而言，可能我们会看他们往期芯片的成绩，从项目难易度、执行时间长短、是否有延期、有重大缺陷等方面，对于个人呢？如果他是不足五年的工程师，我们主要会看他的技能和经验两方面是否具备所要求的水准。但这些参考部分仍然不足以、或者不清晰地评估验证水平，我们需要一份综合的评估表格，如同计分板一样，将每个节点所需要做的工作，完成度、完备性、效率、复用等各个维度作出评估，将整体验证的功能覆盖率、性能、能耗检查都作出量化计算。无论对于团队还是个人，只有趋向标准化、量化的验证才能更稳固地推进项目，做到心里清楚，手下不慌。
验证团队除了需要优秀的验证师，也需要经验丰富的验证经理。这一要求的着眼点并非单单在于日常管理，也包括就芯片整体规划验证框架、环境、流程，制定验证计划、评估人力、时间节点等等。与设计不同，设计经理通常不会要求设计符合一定的框架规范（尽管大公司内有设计代码规范，然而遵循的人少也没有严格的代码检查工具检查代码风格），而验证经理会就本项目、之前的项目、未来的项目之间验证环境的复用和优化两方面考虑，要求模块、子系统和芯片级验证环境可以保持垂直复用和水平复用的要求。同时，验证经理也需要考虑采用何种验证方法、选派合适的人进行验证等。可以这么讲，正是由于验证环境对于复用度和剪裁度的高要求，我们才更需要有合格的验证经理给出整体的规划，所以他的角色不单单是日常管理，更是体现在了对于整体验证所有周边事务的掌握上面。
验证经验的积累和突破
经验分享是需要长期贯彻的事情，它包括了公司内部分享和公司外部分享两方面。验证的事务做久了容易让人产生倦怠，原因主要在于验证师对于以后的验证环境逐渐了解、趋向于按照现有环境的框架去思考问题，也容易对现有环境的效率产生满足，很难做到主动突破现有框架，作出改善甚至是验证环境换代的举措。
公司内部交流值得推荐，除了沟通成本小，不同验证团队、不同事业部或者分公司之间都可以就验证技术展开交流，因为没有哪一个验证团队做的环境、技术是最完美的，这种交流经常能够碰巧火花，产生进一步合作、分享、成果复用的可能性，当然对于提高一个优秀验证团队整体影响力也是很有帮助的。
此外，我们也建议验证团队可以将现有的技术突破、成体系的验证思想和框架同外面的公司做分享，毕竟验证环境还不能算入公司的机密，这也不存在代码外泄的情况，例如通过发表验证大会的文章分享公司自开发的优秀技术、同时也听取其他公司的新动态，这些看起来在更大的验证生态环境中经常“走动”，也能有不小的收获，往往自己之前有困惑的疑难点，可能早已是其它公司证明了的技术，当然，你们的验证技术也会对其它公司带来启发和帮助。
至此，我们已经将验证执行环节的检查清单、项目验证中的各个要素、验证进度的收敛和跟踪、验证团队和验证师的培养以及如何长期推广正确验证理念的《验证的管理篇》同大家介绍完了，感谢你们对于这一篇的跟踪。
下一篇我们将转入同验证具体技术语言联系紧密的承接篇《验证的结构篇》。
谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。
/2 
eetop公众号
创芯大讲堂
创芯人才网