2.1.3 -1【验证计划、进程评估】

计划的概述

验证计划是什么

• 在选择验证方法和构建验证环境之前，我们首先需要清楚验证计划是什么。
• 在展开设计之前，设计人员和验证人员都会阅读功能描述文档以理解设计的各项功能为前提，来考虑如何实现或者验证它
• 因为在实际项目执行过程中，功能描述文档和设计会不断更新，直到流片前都有可能在进行，那么验证人员就需要做好相应的验证计划更新。所以，验证计划的生命在设计被构建之前就诞生了伴随着设计的周期，直到流片

计划的步骤

• 创建验证计划
• 选择验证方法
• 人力资源调配
• 构建验证平台和环境组件
• 开发测试用例

收集的材料

• 结构功能描述
• 设计的各种操作使用模式
• 在正常输入和错误输入情形下设计的行为
• 设计的接口
• 在一些边界情况下设计的行为
• 设计在实际使用中的场景描述

为芯片开发带来的好处

• 使得设计和验证人员对于功能描述文档的理解和翻译保持一致
• 将自然语言描述的功能通过可测试的语言来描述 （自然语言是功能描述文档，后期要知道怎样从功能描述文档中提取出要验证的点）
• 可以更合理地评估出工作量、人力安排和进度节点
• 为验证人员提供清晰的验证目标、任务和进度安排
• 为功能文档提供反馈，修改文档中不明确、有歧义的描述

影响计划的因素

• 会有不同人员更新验证计划。一份充分的验证计划，需要系统、设计验证、软件人员给出意见，共同参与制定。
• 需要更新上百上千的测试用例，并且与计划中的待测功能映射
• 考虑选择不同的验证方法。针对不同的设计，!需要考虑选择动态仿真形式验证或者硬件加速方法，如果采用两种以上的方法，还需要考虑如何实现技术平台上的兼容和跨越式复用
• 如果有新的设计要求，需要更新计划，同时设法对人力和进度的影响降低到最小。在设计的过程中，设计人员仍然会收到新的功能需求，那么一旦确定下来要添加新的功能，就需要考虑额外的人力和进度受到的影响
• 如果有多个组参与验证，需要考虑如何协调。对于大型的SoC项目，一般会有多个功能组参与，甚至他们会在不同的城市办公，这时候去协调组跟组之间的工作，并综合出整体进度结果就很重要了

计划的内容

概述

• 在制定验证计划的具体过程中，我们会将技术部分和项目部分都考虑进来
• 从技术角度而言，我们需要考虑的有验证的功能点、验证的层次，测试用例、验证方法和覆盖率要求
• 从项目部分来看，我们也需要考虑使用的工具、人力安排、进度安排和风险评估。

验证的功能

• 基本功能：通常包括时钟、电源、复位、寄存器访问和基本特性这些可以在模块级完成验证.
• 互动功能：一些需要同其它模块互动的特性，需要在更高层次的子系统级或者芯片级完成验证。
• 次要功能：通常这些功能会在项目后期完成验证，例如性能验证效能验证。即使它们没有通过验证要求，也不会对芯片造成致命影响。

验证的层次

• 结合验证的功能点，需要清楚该功能点是否可以在较低的层次完成验证
• 从验证效率和激励自由度来看，我们应该尽量在较低的层次验证更多的功能点
• 在较高的层次，例如芯片级，应该侧重于系统集成测试

验证的方法

• 需要考虑采取何种验证方法(可以在子系统跑门极仿真，系统级可能跑的少了 )，动态仿真、形式验证还是硬件加速？
• 采取什么样的透明度，黑盒、白盒还是灰盒? （能在边界验证就尽量不要看内部信号 用黑盒验证。 系统级测试离不开C，用C 测试话 UVM 怎样转换成 C， c 怎样转换成 uvm ？ 不建议用 白盒的原因，要查看内部信号，这部分验证对接下来的 fpga 不是那么适合， 做了流片测试是看不到内部信号的， 没办法复用
• ）
• 采用定向测试还是随机约束激励?

验证的用例

• 更随机的测试方法，尽可能遍历可能的各种状态空间?
• 适中的随机约束，倾向于更贴近实际场景的随机激励?
• 采用定向测试，针对而些边界情况可以更有效地完善覆盖率?
  
  随机约束最开始不自由是因为最开始设计没那么稳定， 因为后面功能点越来越多，设计更稳定 约束就放宽了， 剩下 20% 没有覆盖到， 随机约束越来越窄 就贴近一个定向测试

覆盖率要求

• 覆盖率是衡量激励生成种类和功能点验证的量化指标
• 无论通过何种验证方法，我们都需要采用覆盖率来确保给出了足够多的激励类型，并且设计的边界和内部穷历了可能的状态
• 覆盖率可以分为代码覆盖率、功能覆盖率和断言覆盖率
• 除了给出合法的激励之外，也需要考虑给出一些错误的激励，来测试设计的稳定性和纠错能力。

工具的选择

• 仿真工具
• 形式验证工具
• 验证IP
• 断言IP
• 调试器
• 硬件加速器
• 高层次验证语言 (High-level Verification Language，HVL)

人力的安排

• 在确定下来验证方法后，验证经理就可以考虑该投入的人力了
• 由于不同验证方法存在显著差别，除过考虑个人的实际经验以外，也需要考虑他们是否熟悉该模块。验证人员的知识和技术背景越贴合，我们越倾向于选择这样的验证人员
• 一般在一个完整项目周期内，我们会考虑让固定的人员跟踪同一个设计模块，从搭建环境开始，经历模块级、子系统级和芯片系统级验证过程，这样对于项目的风 险较低，人员的成长也更快。

进度的安排

• 在安排人力的过程中，我们同时也将进度考虑了进来。一般而言，进度是从上向下传达的，验证经理事先会有一个大致的时间表，通过简单的计算：工作量 = 人力 x 时间
• 验证经理往往陷入的境地是，人力不够充分，或者时间不够宽裕面对这样的困难，时间是没有弹性的，更多地需要在人力角度上考虑如何恰当地安排人力，做好动态的人力分配，实现高效的资源配置。
• 对于验证经理而言，进度是否是不可修改的，必须严格遵循呢? 这样的问题可能难以给出一个是或者否的答案。但是如果可以在计划中将设计的交付时间验证的验收时间、不同模块的集成时间等等重要信息拆分开来，做到更细致的量化和评估，那么项目执行中的风险就可以在早期发现，同时朝着按时交付的目标迈进

风险评估

• 芯片结构不稳定因素。如果在项目执行后期，突然面临结构的变化，这肯定会给相关设计带来很大影响，而验证任务量和时间也需要发生改变
• 工具的不稳定因素。在新的项目中，我们倾向于使用新的工具版本，因为它们会带来新的性能提并和特性，而在新版本工具使用中也会有适应期，并非一帆风顺。如果我们需要替换工具，那么面临的工具替换成本环境流程更新、技术培训都要更大一些
• 人力的不稳定。因素我们都希望在项目中人员结构可以稳定，这样就不会出现模块的验证人员被临时替换，加大验证风险的问题。同时，如果一个人投入到两个以上的项目，那么他在不同项目中的精力分配也需要考虑进来。（谢验证计划文档的一些习惯，方便复用你的方法）
• 模块交付时间的不稳定因素。由于验证的展开与设计的交付时间密不可分，所以HDL设计的交付时间对于验证进度的影响非常大，所以在计划初期，验证经理应该从设计团队那里获取清晰的交付时间，然在在此基础上做进度和人力安排。

计划的实现

概述

• 一份细致的验证计划也包括项目动向、更新内容和工程进度，面对人力资源总是紧张的窘境，只有清晰的计划才能够合理运用人力资源，保证时间和人力的平衡
• 验证计划需要时常保持更新，给出合理的安排，这样的过程就蕴含着从计划到实践再到反馈，最后到修改计划的周期。
  

如何制定验证计划

• 邀请相关人员参加会议 （关注硬件底层，设计人员、验证人员、硅后测试人员、软件开发人员、系统人员、验证经理 (或项目经理) ）
  

开会讨论

在开会讨论前，作为会议的组织者，需要搞清楚开会的目的和议题分别是什么?
验证计划的内容组成
需要确定的验证功能点

• 份验证计划的模板 (或者组织结构) 应该包括下面的结构
  设计功能简要描述
  硬件实现框图
  待验证的功能点
  验证环境搭建 （准备一份）
  测试用例构成 （开完会做）
  编译脚本和回归测试
  覆盖率分析

确定测试场景

• 针对某些功能点，我们如何给出特定的测试场景。 这些场景 是否同实际情况一致或者类似， 比如我们给出的时钟信号频率是否同设计要求的频率一致，不同时钟之间的同步异步关系是否参照系统要求。
• 需要测试的场景、需要待验证设计的哪些功能模块参与进来。 这种情况一般在模块级测试中， 往往需要较多的子模块参与进来， 而随着测试的层次升高， 我们需要唤醒使能的模块数量就逐渐减少了 。 我们在构建测试用例前，心中已经模拟出测试序列， 明确了参与进来的模块， 以及如何配置寄存器、等待某些状态信号完成下一步功能设置， 直到最后完成整个功能测试
• 一些场景如果涉及电源开关， 我们需要考虑是否需要再PA（Power Aware）场景中完成测试。
• 一些场景如果跟性能有关，我们需要考虑如何发送大规模的数据量实现压力数据传输场景
• 针对不同的功能点， 我们需要考虑选择合适的验证层次， 以及对应的验证方法

创建验证环境

• 构建环境时，针对设计模块的接口信号需要实现对应的激励发生组件，通过控制协调不同的激励组件来构建场景
• 在实现激励发生组件中，需要考虑接口信号是标准总线还是系统控制信号。如果有可以复用的验证资源，那么会节省构建平台的时间。
• 我们也要考虑收集数据和对比结果，这就需要监视信号组件和检查组件的实现。监视信号组件的主要任务是监视设计的接口信号以及内部信号，如果是总线接口，那么需要在解析总线的情况下将观察到的数据打包整理，如果是控制或者其它信号，也需要按照信号的定义，在特定的事件下捕捉有效信号
• 监视信号组件最终会将分析整理好的数据发送给检查组件，由检查组件进行数据比较，给出比较信息和报告，最终判定测试是否成功。

计划的进程评估

概述

在验证过程中，我们需要不断地更新验证进度，从各项参数综合评估验证的完备性。我们通过收集以下信息来评估验证计划的实施进程:

• 回归测试通过率 (regressioin pass rate)
• 代码覆盖率 (code coverage)
• 断言覆盖率(assertion coverage)
• 功能覆盖率 (function coverage)
• 缺陷曲线 (bug curve)

回归测试通过率

• 一份回归测试表是将测试设计所有功能点的用例合并为一个测试集.
• 回归测试表的主要功能就是用来在设计经过缺陷修复或者性能提高后测试原有的所有功能点，确保设计仍然可以正常工作
• 这种往复的测试方式不仅在于确保新的设计变化不会影响之前的功能，也可以用来避免修改后的设计对于别的模块造成的功能失效。
• 设计的维护不仅在于按照设计需求提供新的功能，而且也需要保证新功能不会影响原有的功能。
• 回归测试表中的测试用例需要确保是可以重现激励场景的
• 这一点对于定向测试方法 (例如C/C++) 是容易实现的，而对于随机约束测试而言，我们需要在测试中显示出每次测试使用到随机种子 (random seed)， 只有通过这个特定的种子，我们才可以重新产生之前的激励，跟踪调试失败的用例。 对于随机测试而言 要知道测试用例名称、知道测试随机种子是什么
• 
• 如果在某一个层次的回归测试通过，我们接下来可以向上迁移到新的验证层次，展开新的回归测试流程，或者在设计需求发生变化时，重新从模块级开始递交测试表。
• 不同层次的回归测试表，每个测试用例的仿真时间消耗也不一样。 一般而言，模块级是最快的，到了芯片级，一个回归测试表如果包含数千规模的测试用例，往往需要若干天时间才能最终运行完毕得出结果
• 不同层次、不同设计规模、不同测试场景复杂度，都会影响测试用例的仿真时间。递交测试表的重要因素就是仿真速度，由于考虑到递交测试表主要依靠计算资源和验证结构的性能表现，我们对验证平台的优化和运算资源都会在此时提出更高的要求。因为只有更快速地往复递交和得出结果，才能更快得知新的设计变动是否是可靠的。

代码覆盖率

• 代码覆盖率是用来衡量RTL代码是否被充分运行的指标，目前的仿真器也都提供方法来收集代码覆盖率，并且进行合并和分析。
• 通过回归测试表，我们可以产生基于测试用例的代码覆盖数据，并且在回归测试完成后，通过合并数据，生成总的数据来分析各个模块的覆盖率情况

常见的代码覆盖率包括

• 语句覆盖率 (statement coverage) ：指的是程序的每一行代码是否被执行过
• 条件覆盖率 (condition coverage) ：指的是每个条件中的逻辑操作数被覆盖的情况
• 决策覆盖率 （branch coverage）：指的是 if, case, while, repeat, forever, for 和 loop 语句中各个分支执行的情况
• 事件覆盖率 （event coverage）：该覆盖率用来记录某一事件被触发的次数
• 跳转覆盖率 （toggle coverage）：用来记录某个设计边界信号数据位的 0/1 跳转情况， 例如从 0 到 1， 或者从 1到 0 的跳转。
• 状态机覆盖率 （finite stage machine coverage）：仿真器的覆盖率可以识别出 设计中的状态机部分， 记录各种状态被进入的次数， 以及状态之间的跳转情况

断言覆盖率

• 断言描述本身也支持覆盖率收集，一般可以通过仿真或者硬件加速的方式来收集，也可以通过形式验证的工具来收集。
• 在常见的仿真中，仿真器会记录断言的先决条件是否被触发，以及判断语句成功或者失败。
• 根据选择的验证方法不同，我们可以将断言覆盖率分为：
  基于动态仿真或者硬件加速的断言覆盖率
  基于形式验证的静态断言覆盖率

功能覆盖率

功能覆盖率是为了衡量设计的各项功能是否都实现了，并且按照预想的行为执行。功能覆盖率会关注设计的输入、输出和内部状态， 通常它会通过如下方式来描述信号采样要求：

• 对于输入而言，它会检测 数据端的输入和命令组合类型，以及控制信号与数据传输的组合情况。
• 对于输出而言，它会检测是否有完整的数据传输类别，和各种情况的反馈时序
• 对于设计内部而言，需要检查的信号会跟验证计划中需要覆盖的功能点相对应。通过对信号的单一覆盖、交叉覆盖或者时序覆盖来检查功能是否被触发、以及执行是否正确。

缺陷曲线

• 在验证过程中，我们会不断地发现新的设计缺陷，通过缺陷记录表或者已有的商业工具记录下来，进而提交给设计人员。
• 设计人员在分析了缺陷，并修复以后，也会修改该缺陷的记录并且通知验证人员
• 验证人员会递交原有的回归测试，在有必要的情况下添加新的测试用例， 直到所有的测试通过以后， 才能宣布新修复的缺陷是成功的。
• 在缺陷被记录的过程中，我们通过时间坐标和特定时段的缺陷数量绘制出缺陷率曲线
• 如果我们可以尽早地将缺陷曲线收敛，这意味着我们后期发现缺陷的数量和可能性也就越小。
• 有些时候，我们需要当心的是，如果到了验证后期，我们发现了一个基本功能存在重大缺陷，这就是一个危险信号，意味着我们很可能在之前验证过程中遗漏了一些重要的测试场景