芯片验证全视之八：验证的资源需求

本文转自：http://www.eetop.cn/blog/html/28/1561828-436966.html

从前面的文章中我们可以明显地发现，对于验证周期的合理投入是非常有利于在硅前尽可能发现一些缺陷的。虽然真正检验功能验证标准的时间得到硅后测试阶段，但对于一家一般规模的公司他们可不希望有惊喜发生，因为一次流片的失败对于一家公司而言或许是灾难性的。所以，我们应该多投入资源到验证中去，是吗？

 

没错，是应该多投入，然而是越多越好吗？任何一家商业公司都会核算成本，将每一个阶段的预算都保持在一个合理的部分，所以对于验证资源需求也是一样的。一方面我们希望投入更多的人力、物力让芯片硅前验证流程可以尽可能的完备，另外一方面我们的项目经理也需要考虑人员增加的成本以及相应带来其它方面的新增成本。再考虑到不同验证人员之间的产出比例也存在明显差异，这对于验证经理而言，做出一个合理的估计已经是件不容易的事情了，如果再考虑到中途突发的一些事件例如新增加的模块、修改的功能需要额外的验证人员，是否在前期有过考虑较合理的验证人员数目的缓冲，或者做到了合理的动态资源分配，都是一名验证经理该具备的能力。

 

接下来我们把验证的资源需求分为常见的五大类，依次对它们的特点做一些讨论。

 

验证人员

验证人员本身就是首要考虑的资源。首先我们倾向于一直独立于设计团队之外的验证团队，这一点在稍后的《一名验证师的自我修养》中会详细解释。由于目前验证师需要具备的各种能力和设计师的技能树差异逐渐拉大，以至于我们需要专门的培养线路来对新入职的验证人员做培训，而随着验证人员与设计人员的经验增长，他们的技能树在各自的领域里面也会逐步拉开差异性。

 

除过技能树的明显差异以外，从验证周期来看，我们也希望有第二份保证，那就是验证人员会对功能描述文档进行独立的翻译，进而建立激励发生器、参考模型和比较器。激励发生器是面向接口协议的理解，参考模型和比较器是面向设计功能描述的理解，这有助于同设计人员一起做二次核对，发现双方在设计功能描述上理解的差异和模糊的地方，进而找到可能存在的功能缺陷。

 

如果面向一些小公司，条件无法达到拥有一支验证队伍的时候，那么通常的场景是设计人员会同时担当设计和验证两项工作。我们先暂且将验证专业性的要求搁置在一边，针对这种情况，我们可以给出的合理建议就是设计人员一定不要自己去验证自己的设计。因为从理解层面来看，这违背了验证的二次核对思想。当设计人员针对自己的设计在构建验证环境的时候，他无法跳出自己理解的思维边界，在用另外一个人的眼光去看待他的设计，也因此他的参考模型很难做到像独立验证人员写的模型一样可以发现一些他自己没有注意到的边界情况和设计缺陷。

 

此外，至于设计人员同验证人员的分工，他们之间的边界并没有那么明显。这指的是，验证人员需要在仿真报错以后，进一步调试，首先找到失效的功能点，判断问题是由于验证环境的不完整还是设计本身。如果是设计的功能点有缺陷，那么他还需要在设计RTL代码中分析逻辑的错误原因、状态机发生意外跳转的原因、时序没有满足的原因等等，当进一步定位到逻辑时效的根本原因再递交给设计人员的时候，那么这中间的沟通效率的工作产出会更高。同一个场景，从设计人员在递交给验证人员更新过的设计之前，设计人员可以做的有实现做语法检查（编译可以通过）、递交一些基本的测试列表确保设计在改动以后基本功能都是得到保障的，这一点也有助于设计在更新之后，验证人员可以将有限的精力专注在设计更新部分，而不需要浪费在一些基本的功能点意外失败的状况上面。

 

上面我们主要提到了设计团队和验证团队有效合作的方式，对于验证人员自身的能力，我们在之前的《验证能力的五个维度》中完整讨论过。而作为一名验证经理，他需要做的事情包括整个工作量的估计、动态的人员量估计、以及合适的人员安排。

• 工作量估计：一般发生在项目开始阶段，这一点会根据芯片结构的功能模块数量和复杂度来估计。一般来讲对于验证经理估计出来的工作量是偏高的，这跟他默认需要留出人员余量用来处理突发状况或者较充裕的人员留作缓冲是有关系的。所以验证经理会跟项目经理之间就自下而上的估计和自上而下的估计做几次讨论（可能是激烈的讨论，但只要有效果就是有意义的），而在会上的讨论验证经理除了需要有合理的依据给出工作量估计数字的原因之外，也需要考虑到公司层面上对于验证投入经费的考量，这样比较平衡的观点相对而言，容易跟项目经理之间有更少的分歧，最终达成一致。

• 动态的人员量估计：按照硅前验证不同阶段不同验证层次（从模块级到子系统级再到芯片系统级）的特点，我们也需要给出一份合理的动态人员量估计。对于一家成熟公司，他们可能同时在做两个以上的芯片项目，而合理的动态人员量估计可以更有效地根据两个芯片项目在同一时间处在不同阶段的时间差来充分利用验证人员。一句话，给每一位验证人员饱满的工作量是判断验证整体产出的一项标准。

• 合适的人员安排：我们一般倾向于让有经验的人去做他们更有把握的事情，这对于项目执行的风险来讲，是会降低的。如果从团队活力和自驱动的观点而言，一名有经验的验证人员长期做一件轻车熟路的事情对于他的能力成长和公司培养员工的初衷来看都不是积极的。所以，我们建议在项目间歇阶段，收集这些有经验员工的意见，在合理可控的情况下完成一些轮岗、调岗的办法，让不同模块之间的验证人员进行调换。在这一过程需要注意的是，最好不要做大的“血液循环”，否则在“过氧”的积极新鲜的氛围下，可能也会有一些潜在风险，例如知识传递的断层问题。

 

EDA工具和支持人员

目前的芯片设计阶段越来越需要EDA（Electronic Design Automation）工具的协助。再考虑到逐渐繁多的验证方法，它们也各自需要通过不同的验证工具支持来实现。这些不同的验证方法和对应工具的情况大致有：

• 常见的仿真验证和仿真工具

• 断言（assertion）和形式验证（formal verification）工具

• 语义分析（lingting check）、跨时钟域检查（CDC，cross-clock domain check）工具

• 功耗相关（power-aware）仿真工具

• 验证环境软件开发（IDE，integrated development environment）工具

• 支持虚拟原型（virtual prototyping）的仿真工具

• 支持硬件加速（emulation，hardware acceleration）的仿真工具

 

EDA厂商一般是通过电子许可（license）的数量来为客户提供服务的，而对于验证团队来讲，也需要考虑峰值的许可使用情况，来在每一个月调整不同的许可使用量合理给出公司在EDA工具上面的花费。

 

同时面对特性日益增多的EDA工具，我们也需要有经验的EDA支持人员与验证团队一起紧密协作，一方面做一些验证环境、验证效率提高的工作（从充分挖掘验证工具的效率、使用性入手），另外一方面也需要在一些场合为验证人员们做一些EDA新添加特性的介绍，帮助他们及时了解掌握新的工具使用方法。

 

除此以外，EDA支持人员也作为同EDA厂商的接口，日常交换工具使用中存在的问题，以及验证人员对工具的反馈，目的在于让EDA工具商可以及时为验证人员存在的问题作出解答。这一点在验证中由于工具问题严重影响进度的时候尤为重要，因为快速的反馈弧建立有助于快速解决工具带来的问题，另外一些情况下，当验证效率有可能从EDA工具一侧得到提升时，EDA支持人员也扮演着验证加速师的角色。所以，验证人员应该同EDA支持人员一同从验证效率出发，就验证环境本身和EDA工具两方面出发，不断提高产出。

 

时间

没有人会怀疑这一点——因为时间对于人力物力资源的要求是一个系数，对于芯片是否可以按照进度安排流片也是关键。那么对于验证人员来讲，他们需要对时间保持敏感的部分有哪些呢？

• 项目的总体进度安排

• 自己负责验证模块的模块级、子系统级和芯片系统级的进度安排

• 验证计划回顾

• 覆盖率合并收敛

• 验证代码回顾

 

这些重要的部分都需要验证人员可以按时给出结果，而每一位验证人员的努力才会使得验证整体进度可以保持节奏。

 

运算资源和网速

优质的运算资源对于长耗时的测试用例来讲有很好的帮助，这一点在到了门级仿真的时候尤为明显。由于在硅前验证的后期，我们主要通过提交递归测试来大规模测试设计，我们需要一个大型的服务器运算群（server farm）提供运算资源，对于运算资源的考虑一般包括如下几部分：

• 与整体计算量匹配的服务器运算群

• 用来向服务器提交任务的接口

• 统一做运算资源分配的任务管理中心（自动化、可配置）

• 便于用户查看任务运行情况的接口

 

而网速对于用户来讲，也会影响到他们登录服务器的使用体验，理想的情况是低延时的操作，这无论是对验证人员的心情还是效率都有帮助。

 

技术培训

随着验证挑战越来越大，要想在验证上面的取得成功，需要考虑让验证团队保持学习的状态。设计复杂度的提高不但要求设计团队的成长，也需要验证团队可以处理好新的验证任务。对于公司而言，也需要考虑如何让验证团队的梯队可以保持成长，有清晰的职业路线，对于不同的验证人员可以考虑不同的技能树成长方向。

关于验证人员需要的具体技术，我们会在下次内容中详细阐述。

 

 

无论项目经理或者验证经理，如果从这五个资源要素出发，那么对于验证进度的合理估计是有帮助的，同时可以在日常将验证团队进行技术培训、在可允许的范围进行局部轮岗保持团队活力，这些都能够在日益复杂的验证环境当中保持团队的竞争力，做好下一次项目的准备。