芯片验证之验证计划

1. 验证计划必要性

有了验证策略之后，为什么需要验证计划呢？在《》文章里讲过，验证策略是芯片验证的战略性指导文件，验证计划是芯片验证的战术性指导文件。验证策略在高层次上用比较概括的语言描述对项目验证的整体规划，方便大家了解整体方向，具体可以看《》。

有了验证方向之后，就需要进一步把验证策略拆解成更具体的实施计划，详细描述验证是如何进行的，验证计划的存在至少有以下几点必要：

• 可以更清楚知道验证某对象有哪些任务、风险等；

• 方便评估工作量、人力安排和进度节点

• 判断验证何时可以结束；

• 有一份验证环境对应的文档，方便其他人审视和提出改进意见；

• 方便以后人员交接时，有文档可供参考；

• 方便同一小组内任务的分工合作，减少不必要的沟通，也让小组成员做事有依据可循；

• 方便验证收尾时查缺补漏；

2. 验证计划撰写流程

验证计划撰写的流程是怎么样的呢？首先就是要明确验证计划的输入件有哪些，也就是根据哪些文档来撰写验证计划，比如：功能需求文档、设计文档和内存映射表等等。通常要求这些文档是准确无误的，如果描述有出入的地方都算是bug，因为验证是依赖于这些文档来做的，如果源头出错了，那验证可能也就跟着错了。

在明确所有输入件后，就开始撰写验证计划了，期间可能还会反复与其他人沟通确认。等验证计划完成后就开始邀请各方人员(至少包含项目经理、系统设计人员、待验设计人员、资深验证专家)进行评审，然后根据大家所提的各种合理建议进行完善验证计划，最终开始搭建验证环境。

验证计划不是写一次就束之高阁了，而是会随着项目的进行反复更新，比如说待验设计的规格变化，那么验证计划理所当然就要更新了，更新完就需要新的一轮评审和改进，最终实施。或者有些验证计划在实施过程发现某些方面不可行，那也需要进行更新、评审和改进，并不是一成不变的。

总得来说，验证计划撰写的流程如下图1所示，是一个周而复始、循环进行的过程。

图1 验证计划撰写流程

3. 验证计划内容

验证计划需要包含哪些内容？可以划分为两类：技术部分和管理部分。顾名思义，技术部分就是讲如何验证待测对象，确保无问题遗漏。管理部分就是讲人员管理和分工合作等方面的事情。

3.1 技术部分

技术部分建议至少包含这几部分：验证测试点、验证层次、验证方法、验证环境、验证用例、验证检查、覆盖率和验证完备性分析。

3.1.1 验证测试点

建议验证测试点使用Excel表系统整理出来，应包含待验设计接口、内部结构以及与其它模块交互的测试点分解，具体可以参考这篇文章《》和《》。在写完测试点后，需要与架构人员、设计人员以及有经验的人员一起评审，看看有哪些需要增强和补充的，特别是设计重点关注的部分，还要结合历史的问题清单进行举一反三。

3.1.2 验证层次和验证方法

验证层次和验证方法通常在验证策略里已经确定好了，在验证计划需要再提及本验证的层次和方法，并展开陈述。验证层次需要阐述清楚本验证环境覆盖的RTL范围、重点验证哪些功能、有哪些功能无法在本层次覆盖，需要提级验证的。验证方法就是要论证所采用的方法是否可以覆盖本验证层次的验证目标，这些方法有什么优缺点、局限性等，对于缺点和局限性，要如何去解决或尽量减小呢。

3.1.3 验证环境

需要阐述验证环境的框架，是由哪些组件组成，采用什么样的方法学和抽象层次，比如UVM、VMM等。有哪些激励组件、检查组件、覆盖率、寄存器模型等，可以让大家快速了解验证环境的结构。

在这些组件中，需要描述组件是否要全部重新开发、或是在已有组件上进行修改就可以使用、或是购买商用VIP等。

3.1.4 验证用例

验证用例是一块很重要的内容，验证质量的好坏很大程度上有依赖激励是否有能够有高效地产生完备的场景。具体内容可以参考《》和《》。

要提前把用例按类规划清楚，列出大致需要的用例类别和个数，最好整理成一个表格，写清楚每个testcase所要产生的验证场景。一方面做到心中有数和排计划，另一方面也方便别人审查。

3.1.5 验证检查

验证用例产生期望的场景后，能否找出RTL bug，直接取决于验证检查(checker或reference_model+scoreboard)是否完备。具体内容可以参考《》。

要阐述清楚有哪些验证检查手段，这些手段分别检查什么features。是使用端到端检查、仿真断言检查、formal证明还是self-check等。然后介绍下每种检查手段的结构和检查流程等。

3.1.6 覆盖率

覆盖率包含代码覆盖率、功能覆盖率、断言覆盖率和统计覆盖率。在指定EDA工具的选项后，代码覆盖率会自动被收集，这一块不用过多操心人为引入错误。对于其它三种覆盖率，一定要百分百重视，它是衡量我们是否充分验证到期望场景的重要依据，它们一般不会直接发现RTL bug，但对于增强激励起着关键作用。

统计覆盖率可以统计激励的分布情况，让我们早点发现是否哪里约束有问题导致激励走偏，做很多无用功。功能覆盖率和断言覆盖率可以让我们知道是否有什么场景是未覆盖到的。对于这三者要尽早开发，而且多轮审查，确保覆盖完备且实现正确。一旦漏掉或实现错误它们中的某些点，就可能直接导致漏验证了某些RTL功能特性，而且还不一定好发现。

CDV(coverage driven verification)，也即基于覆盖率驱动的验证技术，是基于覆盖率的一个闭环。如果覆盖率实现有问题，将直接导致闭环被破坏掉了。

覆盖率也是衡量验证进度的关键指标，是重中之重，要万分谨慎。

图2 CDV流程

3.1.7 验证完备性分析

这一节需要论证验证环境是否可以支撑覆盖当前验证层次的所有特性，既要定性也要定量。定性从验证流程规范、波形检视等环节去论述，定量从测试点清单、覆盖率数据、回归数据量等方面去论述，两者一块组成完备地证据链，用以说服项目经理、验证经理等同事，让他们和自己对验证质量有信心。

3.2 管理部分

管理部分建议至少包含这几部分：工具列表、验证进度安排、每阶段验收标准、人力需求和风险评估。

3.2.1 工具列表

说明当前验证环境工具的需求情况，比如需要哪些EDA工具及其版本，需要开发和复用的脚本、UVM版本、代码管理工具、Python等软件的版本，等等。统一的工具可以使同组成员之间动作的一致性，不至于某些代码在A同事可以跑的通，到B同事就报语法不兼容错误。

3.2.2 验证进度安排

这一块要结合项目和验证策略的进度时间表，把当前验证环境的所有任务分阶段细化到各个时间节点上。写清楚在什么时间点需要做完什么事情。比如验证环境开发程度、回归通过率、覆盖率数据达到多少、质量审视及验证报告完成度等。

验证进度安排需要提前和验证精力、设计人员对齐，让别人了解你到什么阶段会做什么事，心里有数。

3.2.3 每阶段验收标准

这里需要结合验证策略中规定需要验收的材料和数据与本验证环境的进度安排，把它们细化到各个阶段点上，比如到A节点ccov为50%，fcov为60%，到B节点ccov为80%，fcov为80%等。

而且这些每阶段的验收标准也是需要提前和验证经理、设计人员对齐的。

3.2.4 人力需求

根据前面评估的工作量和时间进度，规划完成验证需要多少人以及每个人的技能点等。

3.2.5 风险评估

风险评估也是很重要，要提前理清楚当前验证可能存在什么风险，及时上报。比如：

• 待验设计某功能存在延迟交付风险；

• 人力风险；

• 能力风险；

• 工具风险

4. 总结

完整的验证计划是做好验证必不可少的条件，一定要用心写好，而且也要多沟通、多对齐和review，这不只是验证工程师的事情，更需要其他相关领域的同事共同参与完善。千万不要怕麻烦，好的验证计划是成功的一半。

创芯大讲堂芯片验证课程推荐