10_验证计划

1. 概述

• 计划制定步骤：
  
• 制定计划需要收集的材料：
  
• 制定计划为开发带来的好处：
  

2. 计划内容

• 影响计划的因素
  

2.1 验证计划内容：

2.2 验证功能

• ABC，次要功能主要是指除了芯片必要功能以外的，为了提高芯片市场竞争力而设计的提高芯片性能的功能。因此在流片之前不验证也可以。有时候流片后验证工作也在继续，首先不能保证一次流片就成功，其次次要功能可能还需要验证，然后芯片版本迭代可能也需要持续验证。

2.3 验证的层次

• 大约有70~80%功能点在模块级别完成验证，更容易观察到细节。

2.4 验证方法

• 在子系统层面也可能要门级仿真，系统层面由于太耗时跑的可能很少。
• 尽量采取灰黑盒，能在边界验证清楚尽量不去碰内部信号。白盒验证不利于人员交接。
• 系统级测试离不开C，而使用白盒验证，这种验证方式不利于向后延用。

2.5 验证的用例

• 随机约束域一开始的时候比较小，是因为一开始设计还不稳定，可以明确告诉随机约束是怎样的，快速完善设计后加大随机约束域；中期约束域随着功能点的增多而增大；超过80%功能覆盖率后， 剩下20%的功能覆盖率，依靠大范围的随机约束测试难以覆盖，因此缩小了以求随机约束测试更贴近于定向测试。
• 测试边界情况更多的还是使用定向测试。
  
• ABD

2.6 覆盖率的要求

2.7 工具选择

• UVM调试手段比SV更多。
• 高层语言systemC可以用于设计、验证。

2.8 人力安排

• 尽量打通全流程，模块级、系统级……

2.9 进度安排

• 加班时间从效率至上的角度不应算做一个乘数，否则可能导致恶意加班，效率降低，项目进度迟缓。如果约定了8小时工作时间并且约定任务，大家都朝着避免加班的方向努力，效率会更好。

2.10 风险评估

• 芯片竞争力不强可能会修改结构
  
• ABCD

3. 计划的实现

• 验证计划每周都可以增添计划完成程度的部分
  如何定计划？
  

3.1 邀请人员：

• UVM的测试用例无法移植到硅后测试，C可以。
• 软件人员知道重点模块，指导验证人员进行验证
• 验证经理关注验证人员给出的节点是否合理
• 其他验证人员一起决定统一的验证环境，便于将来系统集成。
  
• BC。

3.2 开会讨论内容

3.3 确定测试场景

• 如果测试过程中发现性能无法达标要及时反馈，必要时调整系统结构。

3.4 创建验证环境

• 多个激励组件可能是并行也可以是串行发送激励
• 标准总线可能会有验证的IP（复用验证资源）
  
• ABCD。验证计划是动态的，每测试一段时间都需要更新验证计划。包括验证结果等。

4. 验证计划评估

• 概述
  

4.1 回归测试通过率

• 越接近系统顶层，验证平台越复杂，因此不会将所有子系统验证环境都集成进来，这是受到运算资源的限制。
  
• CD。回归测试每次的随机种子都不一样，重复做也有帮助。一个地方修改整个测试表中的测试用例都需要重新跑。

4.2 代码覆盖率

4.3 断言覆盖率

4.4 功能覆盖率

• 功能覆盖率是跑回归测试是否有效的判据。
  
• ABD。功能覆盖率不到100%不能算通过。

4.5 缺陷曲线

• ABD。缺陷曲线记录的是总的缺陷数。