基于敏捷的IC验证实践

授权转载自：公众号“萌新来啦”

不知道在验证中煎熬数年的你有没有遇到以下场景：

• 设计怎么又改设计方案了，我这环境刚改完啊
• 什么，这个功能不要了，为了它验证环境可是改了好多啊
• 喂喂喂，你怎么不早说啊，我还以为我们的主要功能是xxx
• 下个月TO，是在开玩笑吧，还有这么一堆case要做，项目经理是xx吧
• 大哥求求你不要加功能了，再加环境只能重写了
• 经历过N遍验证环境出同一个问题后，设计终于忍不住了把验证打了一顿
• 大哥您别改了，regression很慢的
• 这个问题都找了一个星期了，啥时候才知道问题发生在哪啊

上面的场景可以总结为以下几条：

• 花了大功夫做的环境最后却不用了，导致进度又变成初始阶段。 不停的在改环境使得应该进行的测试迟迟不能开始，影响了速度。
• 验证环境越到后期越改不动 面向对象的一些设计原则、设计模式都对进行可复用性的设计有较大的指导意义 在过程中不断的重构也可以降低代码熵增的速度
• 任何设计的变化都需要经历长时间的regression 验证分层、分治是一个比较有效的手段
• 无法保证验证的正确性，尤其是遇到大量修改时，需要花费较多时间来确认到底是验证还是设计的问题 利用完善的ut验证验证的正确性
• soc debug缓慢 复用下层模块的验证环境作为当前环境的内部check，加快问题定位

基于上面遇到的问题，结合敏捷针对VUCA的改善措施，将验证分为三大流程、四个阶段、四个评审里程碑、六大验证过程。如下图：

启动阶段

• 通过需求收集与分析，并根据历史总结checklist形成初步验证plan。 checklist越完善越能避免一些小事故的发生，有的时候一个reset验证不充分也会出现大问题。 checklist有利于经验的总结与传承，帮助牛人避免小错误，帮助新手发现大问题
• 启动阶段需要完成原型设计。 不可综合的架构性原型验证设计并不需要花费太多时间，部分也可以通过参数化类、脚本生成实现，快速达到验证想法是否可行的目的 为后续以case为基础的端到端交付提供基础环境，保证任务的顺利进行
• plan以case为基础，将覆盖率等验收标准绑定到case上，并进行初步的优先级划分。 case作为载体会比覆盖率等有更强的端到端的价值，可以防止前期花费过多时间在环境建立上而没有给出应当的反馈。 针对case较容易进行优先级的划分。
• 验证架构设计方面要做到向上可复用、向下可集成。 向上复用作用是当组成soc、subsystem的模块较多，debug难度比较大，可以使用下层的验证环境进行对应模块的check，达到更快的缩小出错范围的目的，在做底层模块时需要想到上层怎么可以更方便的使用，通过增加一些底层工作量达到降低复用工作量的目的 向上复用另一方面是进行interface agent的全局复用 向下集成是希望尽可能多的寻找可复用单元，不断分层，降低验证的复杂度，提升可靠性（模块过于复杂很容易想不清楚）

迭代阶段

• 定义迭代时间盒，假设2周
• 以优先级和价值点作为评判标准从已有plan中选取2周可以完成的case

• 进行case拆解，并将工作量精确到天，组内进行任务分配
• 确认当前环境是否可以较顺利的支持功能添加，如果不可以进行重构 重构需要以ut作为验证的保证，保证修改不会引入新的问题 满足oop设计原则、设计模式是提高可否复用性的重要手段
• 时间盒结束，case验收 通过之前定义的验收标准查看对应case是否通过 单个case的覆盖率会比整体覆盖率更精准，减少整体覆盖率互相交叉覆盖引起的功能没问题的错觉
• 回顾 发扬优秀做法 改进不足
• 如果有特别紧急任务或者特别重大的改变，可以打断当前迭代

收敛阶段

当plan中的case完成的差不多了，或者剩余的重要性很低时收敛阶段

• 覆盖率定向收敛
• 长时间的无目标随机 视机器资源、人力资源情况而定

收尾阶段

当项目完成或者被强制停止时进入收尾阶段

• 总结
• 资料整理存档
• 满意度调查

评审milestone

在进展过程中，有四次较大规模的评审，以进行团队级别的目标对齐milestone评审需将需要的点包括不仅限于plan、验证架构等进行详细评审以保证方向正确性。

新需求加入

• 启动阶段后的新需求加入，需要经过评审后加入plan，并在下次迭代参与任务选取
• 如果新需求对验证架构影响较大，需拿出专门时间以ut为基础进行大规模重构