可能在工程技术领域要找出比芯片验证更考验团队合作的项目类型会很难,之所以这样讲,是因为验证质量只有在流片之后经过测试、用户反馈才能得到最终的结果,而且,验证非常依赖于团队的整体协作,一百个人的验证协作如果其中有一个人疏忽了,那么我们只能心里默默祈祷,他疏漏的模块功能作用没有那么广。
我们在验证工作中,面临紧张的进度,除了可以加班加点赶任务,也还需要有时候停下来回顾一下我们走过的路是否有弯路和没有寻访的地方。因为我们不但需要下力气去尽量实现验证的完备性,也需要考虑如何利用现有的人力资源实现最大化的验证收益。
除了越来越完备的各种验证方法、工具和流程,我们还需要注意,人始终是对项目能否顺利进行的至关重要的因素。招聘到合适的人,融入一个优秀的验证团队,使我们个人和公司都要关注的地方。我们这一节将“以人为本”,来讲一讲如何建设一个验证团队的文化。
验证团队的7个好习惯
无论哪一家公司,我们在加入那家公司前了解他们的企业文化,而一旦加入之后,团队文化的影响要更胜一筹,因为每个人日常工作中都会在自己的团队或者接触其它团队。接下来我们介绍的7个好习惯有的是广泛意义上的团队习惯,有的则是专门针对验证团队的建议。这些习惯尽管并不会列在我们执行项目的检查清单中,但是它对于保持整个团队的健康和活力有着积极的作用。
习惯1:从全局入手
在处理同一件日常事务时,专家的考量角度总会比新手更高、更广、更丰富,也因此解决问题时的方案也因此产生了高下的区别。无论你目前是什么专家水平还是新手入行,都会有更高、更新颖的视角等待你去挖掘。对于一个团队而言,在项目启动开始的时候,如果团队负责人就能够对项目的周期、难点、人力估计、环境建设作出响应,与团队分享他的视野,保证团队清楚接下来大家要如何作战、清晰每个阶段的作战目标时,团队中的每一个人也因此会在思考问题时多保持一份全局观。实际上,从全局入手解决问题,往往解决方式更有利于项目的中长期运行,也只需要更少的代价去修改和维护。
习惯2:追求百分百
如果一个问题从硅前RTL隐藏到门级仿真,那么代价是数倍的,如果被隐藏到了硅后测试,那么代价是数十倍的。如果已经发现了问题,那么你预见到该问题带来的影响会随着项目执行而不断放大,所以我们建议如果你遇到了问题,就解决它。不要再说什么这个问题下周处理、这个节点结束以后再做的谎话,要知道下周还有下周的问题,这个节点结束了还有下一个节点。这里我们要着重强调的是,如果你发现了一个会影响大家的问题,更应该主动去修复它,避免一个问题影响到更多的人。也许的确由于节点,你放缓了一些问题的处理进度,但请一直讲它们记录到你的待处理事项清单上,直到你真得做完了它。
习惯3:保持面向对象的开发习惯
对于硬件设计者而言,面向对象的开发方式不一定需要熟悉,而对于验证工程师而言,它的重要性尤为明显。无论你是使用SV、SC、C++还是Python,如果你需要开发一个长期维护的工具,请首先考虑面向对象的方式。作者曾经参与过一些芯片验证工具的开发,在早期功能简单的阶段,由于未对日后软件的结构有一个充分的认识(缺少习惯1),以至于用了过程语言的方式去构建了软件工具的框架。待需要大幅扩容软件的功能时,我们在后续的开发中面临了诸多痛苦,而首当其冲的就是当时缺少面向对象构建的思想。
习惯4:合理复用
复用一词是高效验证的核心理念之一,无论是方法学的推陈出新还是验证环境的搭建维护,都需要始终考虑复用。复用所涉及的范围也很广,除了设计模块复用、验证环境复用、测试用例复用之外,也包括项目环境建设复用、脚本复用等。验证目前占到了整个芯片前端开发的60%以上的工作量,提高复用性就可以加快验证速度,同时也减少维护成本(对于一些需要专门知识的IP模块尤甚)。所以,我们验证工作中,可以考虑将验证环境参数化、脚本自动化、提交文档使得验证环境便于维护和使用。
习惯5:保持创新
除了书本上的知识,更多的磨练来自于项目执行。在从新手逐渐转变为老手以后,往往会有一段倦怠期或者自满期,因为验证人员可能觉得他所属的模块已经足够了解,验证环境也熟练了,似乎没有那么多再需要埋头深挖的地方了。这个时候,不妨建议你争取新的模块和任务,我们看重的是熟练的“新人”在接手新任务以后提出的问题和改善措施。我们相信验证总有需要不断完善的地方,在新的领域你的思想还会保持一段活跃时间,从而提出一些新的改善方法。同时,如果你要考虑如何让大脑保持不断创新的状态呢?除了不断学习、不断交流之外,那就是永远对验证效率的不满足。而实际工作中的创新一旦被证明它对整个团队的价值,那么不单单是它的作用会逐渐放大,而且你也可以感染吸引更多的人一同加入到你们的创新队伍中去。
习惯6:高效沟通
随着验证团队的扩大,如果人员一旦超出10个人,那么整体的沟通效率会随着人员增多而下降,对此我们提出几种建议来有效提高团队的沟通效率。首先,可以进一步考虑拆分为5人以内的小组,平行执行任务,保持各组之间的独立;其次,在可行的情况下首先考虑面对面谈话,次而打电话,再次者写邮件,我们相信口头表达是最高效的方式;再者,尽量少开会,开短会,只邀请必要的人参加,节省他人时间,也节省自己的时间;最后,如果有条件,可以将团队在一些关键项目节点附近聚集在一起办公,团体作战,减少沟通成本。
习惯7:突破责任边界
在设计的边界划分上,我们可以通过定义模块层次和结构来实现,而在验证工作中,我们则无法清晰划分出边界,因为模块之间往往有互动功能。一般,我们会遵循主从、上下行数据和功能实现工作量大小的方式来确定互动功能谁哪一方来验证。例如,如果模块A是主端,模块B是从端,在集成验证中模块A的验证人员也需要验证从模块A发起的访问经过模块B,再回到模块A的数据通路;又例如,如果模块A实现了互动功能更多的逻辑部分,那么也会由模块A的验证人员来发起集成验证。尽管我们希望以一种合理的方式来划分验证边界,但仍然难免有一些边界不清晰的功能交互部分,这时候如果模块A、B双方可以突破责任边界,积极承担各自的部分,或者从项目整体出发,定义验证的完整方案,再考虑工作的承担问题,那么这毫无疑问对于验证团队的整体验证质量是有益的。
通过上述的验证团队的7个好习惯,我们不难看出,一个优秀的验证团队需要从职业技能和工作态度两方面入手来培养。于公司和团队如何着眼于个人培养他们的职业技能,以及个人如何不断炼化自己的工作态度,我们将在管理篇的最后一节《验证师的进阶》中展开讨论。
谢谢你对路科验证的关注,也欢迎你分享和转发真正的技术价值,你的支持是我们保持前行的动力。