验证计划的内容

一、概述

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

二、验证的功能

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

三、验证的层次

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

四、验证的方法

• 需要考虑采取何种验证方法，动态仿真、形式验证、硬件加速。
• 采取什么透明度，黑盒、白盒、灰盒。
• 采用定向测试还是随机约束激励。

五、验证的测试用例

• 更随机的测试方法，尽可能遍历可能的各种状态空间。
• 适中的随机约束，倾向于更贴近实际场景的随机激励。
• 采用定向测试，针对一些边界情况可能更有效地完善覆盖率。
  

六、覆盖率的要求

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

七、工具的选择

• 仿真工具
• 形式验证工具
• 验证IP
• 断言IP
• 调试器
• 硬件加速器
• 高层次验证语言

八、风险评估

• 芯片结构不稳定因素
• 工具的不稳定因素
• 人力的不稳定因素
• 模块交付时间的不稳定因素