IC验证工程师高效战斗手册--如何制定高效的验证方案

路科验证 2021-06-23 12:04 1108浏览 0评论 0点赞

GaN电机驱动设计“避坑”指南 4.23杭州！半导体产业链测试全链路解密

来都来了

不关注一下吗

来源| 杰瑞IC验证（ID:Jerry_IC）

|原创作者| Jerry

在《IC验证工程师高效战斗手册》专辑前面的文章中，我们一起探讨了“提问之道”、“接到验证任务后的高效行动”、“前期如何高效学习”、“如何高效提取测试点”等等话题。很多新入行的粉丝表示这些话题对他们的工作很有帮助，也有向Jerry催更的，今天我们就接着这个主题继续展开讨论。

当我们完成了前期的充分学习，对验证对象有所理解、有了初步验证思路、提取出了验证feature，就到了制定完善具体的验证方案了，验证方案如同作战方案，是行动高效的保证，从作战意识到作战策略，都很重要。

如何才能制定出高效的验证方案呢？

意识上具备验证项目“高效”的全局观

先强调一点，我们谈到“高效”，千万不要片面的理解为“快”，一定是又“好”又“快”。如果不“好”，“快”有何用？

“好”是第一位的，在“好”的基础上，从流程上或从工作细节出发，减少弯路，节省不必要的时间浪费，才能做到“快”。

话又说回来了，“好”指的验证工作质量好，这点比较容易理解。那“快”指的到底是什么快呢？

搭建平台快？case造的快？平台跑的快？

想来想去，这个问题的本质其实是一个验证格局和视角的问题。

“不谋全局者，不足谋一域。”，Jerry建议大家要尽可能站在更全局的视角思考验证方案，多考虑验证的整体进度和项目的整体进度。

A.心中装着最理想的时间节点来制定验证计划

正如ESL（Electronic System Level，电子系统级）设计流程所展示的思想，从算法、设计、验证人员工作的协同方式和并行度层面考虑，以求减少整体研发时间。

想象一下，等设计同事的RTL代码已经完成了，然后验证人员才介入学习、提取feature、搭建平台等等，这样的配合，即使这个验证人员动作再快，也是和设计“串行”的。

与之相反，验证人员和RTL设计人员同时开始学习，设计人员出文档写代码的同时验证人员也出文档写代码，等设计人员RTL写完，验证平台就准备好直接“趁热”冒烟调试。这样即使这个验证人员再慢，也是和设计“并行”的。这就是前面说的格局视角问题，后者验证人员也许做具体的事情都比前者更“慢”，但是总体验证进度和项目进度，可能更快。

现实情况可能更加复杂，你可能多任务并行、可能你接到任务的时间点就已经很晚了、或者相反你收到的时间点很“宽松”。但是不管怎样，希望初入行的朋友至少心里清楚：在你所在公司的流程之下，什么时间节点做什么事情是最理想最高效的？并且可以努力尝试按照自己的“理想”时间节点推进，可能会有不同的收获和感触。

B.整体快才是真的快

我们接着上条再举例一种场景，当验证人员无精力精确定位bug的情况下，交给设计同事精确定位和解决。这个bug藏的很深或数据量大很难分析，设计同事对这个问题的调试苦不堪言，按这个势头评估修改完这个bug可能会花3天时间，这个时候设计同事提出需求：构造一个特殊的checker来作为监控器，有了这个checker设计同事就可以10分钟之内迅速定位解决。验证人员手头很忙，设计提出的这个特殊checker并不会影响验证平台的完备性，不是非加不可的，而且加这个cheker可能还需要一定的时间。

如果你是验证人员你会加吗？

Jerry建议这种情况应该尽快帮忙加上，还是如上的全局观，虽然验证人员放下本来的工作，“慢”了一下，但是要清楚：设计定位和修改bug的时间本质也是属于验证时间，假如这个bug阻碍后续测试和回归是直接拖慢整体进度。退一步，即使这个bug不阻碍测试和回归，释放出设计人员的人力最终也会作用回质量的提升和验证效率的提高。整体快才是真的快，制定验证方案时候需要考虑到类似提高debug速度和设计修改bug速度的策略。

验证方案紧紧把握“完备性”与“实战性”

完备性是最重要和最基础的，验证环境要能覆盖住所有验证测试点。简单说就是验证环境可以发出各种测试点和场景下的激励、同时可以检查和报出各种RTL不符合预期的错误。这个完备性就是上一节中说的“好”的重要体现之一，如果验证方案不能完备，其中的难点问题没有想清楚，便有可能导致在执行过程中出现问题，突增工作量或一定程度上的返工、甚至可能使bug逃逸造成更大的后续时间浪费。所以从这里也可以看出：其实“好”本身就是一种“快”！

完备性是验证方案的基础，但是对于完整的验证方案来说，这可能只是“入场券”，因为更重要的是需要与“实战性”结合。

对于实战性的考虑我们简单抛出几个不同角度的思考案例：

首先，验证方案大的前提条件在实际中是否成立？

比如你的验证方案是需要有一个时钟精确的参考模型来和RTL做对比，但是恰好没有这个参考模型，而且时间人力上也不允许你从零编写这样的参考模型。

再例如，你的验证方案中对某些单元规划为使用形式验证工具保证，但是你们的形式验证经验不是很充足、人员紧缺，无法很好支持。

这些时候相当于你的验证方案前提就被否决了，这种情况，你再完备的方案，也是站不住脚的，你必须接受现实寻找其他的可实现解决方案。

其次，平台是否需要“递进式生长”？

例如，你设计出来了一个完备的验证平台总共有20个不同的checker，但是综合考虑项目进度，急需验证平台出来先测着。

这种情况下，20个checker因时间限制不可能一次性加上。此时可能需要“递进生长式”的完善验证平台，这20个checker，先加哪些后加哪些，什么时候加，为什么这个顺序加？都需要在方案阶段想清楚。

然后，是否考虑了项目的移植性和case的继承性？

如果你的项目是升级项目，要考虑是重新搭建平台还是可以部分继承之前的平台，同时case是否可以一部分继承？这是工作量和风险的权衡。

即使是从零开始的项目，也可以考虑是否有别的项目的公共验证组件或VIP可以移植和复用。

接着，验证前期中期后期和不同验证层次侧重点是否有规划？

我们在之前提取验证feature讨论的时候提到标出feature的优先级以及不同测试点更适合的测试层次。在验证方案阶段需要进一步的思考一下，因为这个feature和你验证平台的结构紧密相关，一方面，如同前面的“递进式生长”，什么时候增加什么激励的组件以及增加checker。另一方面，考虑了不同时期的规划，可能你的方案中就需要更多的灵活性，如增加可配置选项，便于平台不同状态切换。

再次，是否有值得参考的历史验证记录或bug单可以了解一下？

出于实战性考虑，如果是升级项目，老版本的RTL一定被验证过。如果是新的项目，可能有类似设计结构的RTL验证过。他们一定都有验证记录或者bug单，如果你可以搜集到相关信息，建议学习了解一轮，看看哪里容易出bug，你的验证方案能否抓住类似的bug，或者哪些地方加强随机或检查。

此外，验证平台仿真速度的思考、精力时间分配等等。都是基于“实战性”的思考范畴。