一、两种能力
验证工程师在项目过程中，需要面对的问题主要就是需求（Spec）、平台（Testbench）、用例（Testcase）等问题。从技术的深度上，验证工程师很难以压倒性的优势体现出与他人的差异。如何在一批验证工程师中脱颖而出，往往考验的是其综合分析问题的能力，以及解决问题的速度。那么，有什么方法能够同时提升这两项能力呢？本文给出的方法，值得你拥有。
二、一本好书
为了大家能够轻松理解本文的方法，首先要推荐一本好书：《学习之道（The Art of Learning）》，作者乔希·维茨金。
注：本文提及的方法仅涉及书中的两个片段，大家没有必要通读全书。
为了后文展开，我不得不列出作者简介，但是您可以跳过这部分，仅记住一句话即可：他是全美国际象棋冠军，也是太极世界冠军，他很牛。
| 他曾是9岁起便8度荣获全美象棋冠军的天才神通；他的传奇经历被记录成书，并改编成电影《王者之旅》；他是纵横西方棋坛10年后，改行研习太极拳，并连续21次荣获全美太极冠军及世界冠军的“太极拳王”。……正如维茨金所言，“我意识到自己最擅长的既不是象棋也不是太极，我最擅长的是学习之道”。 |
三、整体理论与渐进理论
“回首过去，当时我只有6岁，是个十足的淘气包。在赢得我的信任后，布鲁斯（编者注：作者的老师）以一张空白棋盘开始了我们的象棋学习。我们拿棋子布局，棋路简单，原则清晰。我们首先把重点放在王和对抗王的兵上，棋盘上只放三枚棋子。慢慢地，我对王的威力及兵的微妙作用有了很好的感觉……
一点点地，我的知识根基不断加牢，我对于‘如何把常识转变为创新性想法’有了新的理解。之后，7岁到8岁的时候，我们用了很长时间研究车、象、马残局，探索我从来没有遇到的棋局的应对原理……”
——摘自第三章“整体理论和渐进理论”
大家可以看到，即使是所谓的神童，他的学习过程并不是“整体式”的，而是“渐进式”的。不是一开始就学习如何谋篇布局，而是从最简单的少量棋子对抗入手。小时候，我学习中国象棋的画面却完全不同，我是从背诵“当头炮、把马跳”这样的套路开始的。记忆套路的确可以占得一些先机，但是，当情况变得复杂时，“整体的”套路就不够用了，我无法从微观层面解读棋子之间的相互制约，运用时总觉得底气不足，漏洞百出。
而乔希·维茨金的“渐进式”学习方法，则可以让他从复杂的棋局中解脱出来，首先用最简单的棋局，学习棋子之间的相互制约关系。当更为复杂的棋局出现时，他的基础理论就可以帮到他了。
四、划小圈
“从一开始我就觉得太极拳这种移动式冥想有一个很主要的武术目标，就是让习武之人不断改进一些基本原理。比如说：通过放松胯关节来转移重量；不断放松；思想、呼吸和身体的协调；对内在能量的意识；结束后发招；把来袭的力量化解到地面上；牢牢站立；把能量聚积到某一个部位上。这些原则中的大部分可以通过站立、起始式以及不停地完善各种最简单的动作来实现——比如把你的手在空气中推出去六英寸。通过这些精简动作的练习，你可以感受到身体内部各种细微的反应……
……我把重心放在细小动作上，有时候会花上数个小时就为了练习把手往外伸出去几寸，然后又收回来，释放能量，脚和指尖的练习障碍逐渐减少……关键就是要认识到使得一个简单的技巧发挥作用的原理和支撑太极拳整个系统的原理是一致的”。
“这个方法跟我早期学棋相似，我找到了不那么复杂的比赛结束用招——比方说王和兵，棋盘上也就三个棋子——练习迫移、速度，或者是结构计划。”
——摘自第十一章“划小圈”
其实，“划小圈”在我看来，就是“渐进理论”的另一种表述方式，或者是更直观的表述方式。
验证秘籍TO油腻的巴斯光年：说好的方法呢？难度就是“学好验证基本功”！本文给出的方法是非常具有建设性和操作性的，是保证“见效快”的方法：收集Demo,Demo就是王和兵,Demo就是“渐进式”方法,Demo就是“划小圈”！
那么，有了Demo就可以综合分析问题，快速解决问题了？大多数情况下，是的。
五、验证工程师经常会碰到以下场景
1、怀疑EDA tools设置有问题：尝试执行使用该Tools的Demo，如果Demo都执行不起来，那就是自己的shell设置有问题，或者IT出了问题；如果Demo可以执行，那么，你可能忘记source你的shell了，或者你的仿真脚本中重新设置了EDA tools，而且设置错误了，对照着改过来，问题就解决了；
2、怀疑自己写的SystemVerilog代码达不到预期目标：应用到自己不熟悉的语法时，经常会产生这样的困惑。那么，改一下，调一下吗？如果你的工程编译时间是3分钟，咬咬牙也就忍了（不推荐），但是，如果你的工程编译时间是30分钟呢？你还继续忍吗？为什么不在编译时间仅需要1分钟的Demo上试验一下你的语法呢？
3、与场景2类似的情况，包括：
- 对UVM验证平台的接口不熟悉，在Demo上试一下；
- 某些EDA tools对语法理解不一致，在Demo上找语法替代方案。
刚刚举了提升“解决问题的速度”的案例。那么，如何提升“综合分析问题的能力”呢？其实，您“综合分析问题的能力”已经不知不觉中提升了。为什么这么说呢？因为每次都是你通过自己的努力解决了问题，而频繁的使用Demo提升了你对验证环境的理解。你知道EDA tools应该怎么设置，随机约束应该怎么写，RAM文件应该怎么读取，UVM的组件通过怎样的语法连接。即使偶尔忘记了，给你5秒钟切换到你对Demo下，你立刻就想起来了。你就像乔希·维茨金摆弄他的“王和兵”，以及“把手往外伸出去几寸”那样，日复一日的练习，每天都比前一天都更熟悉你的环境。此时，当你遇到需要解决的问题时，你能够迅速找到值得怀疑的对象。为什么？因为你碰到的情况太多了，你对那些你熟悉的工具、语法、接口充满了信心。
方法很简单，谁用谁知道！
六、最后建议
1、不要在原Demo上修改，建议备份以后再修改，因此Demo应尽量简化；
2、修改后的Demo，如果觉得有用，应扩充到自己的Demo库中，并记录好哪个Demo解决的哪类问题（记录也应放在安全和容易找到的地方）；
3、Demo不应仅限于验证平台，如何对某种设计分解需求，如何写某类log的分析脚本，这些都可以形成Demo;
4、Demo不一定是自己写的，可以来源于别的项目，别的同事，EDA厂商提供的Example，以及培训机构的培训材料，毕竟我们的武林秘籍不是创建Demo，而是收集Demo；
5、相信我，很多验证工程师还没有意识到这一点，你先做到一定可以脱颖而出。