1_验证任务与验证周期

任务：按时、保质、低耗完成硬件设计的验证。

1. 按时

• 关注项目节点，子系统节点（milestone）
• 以流片为终点逆向向前推算，各个子系统的节点
• 一个模块验证延迟都不能流片，子系统没完成，相关的系统也不能验证，总系统也不能验证。一个模块延迟1天，总系统可能延迟半年。
• 项目驱使导致代码可能很丑陋，因此需要模板、自动化

2. 保质

• 使缺陷尽可能少地暴露在流片后。否则会带来很大的联动成本，对公司和客户都会带来消极影响。
• RTL发现漏洞修复需要半天（包括RTL设计/验证），后端门级仿真时发现可能一星期，流片后发现修复则需要数月，交付后发现修复好再二次交付至少是半年。

3. 低耗

• 正常情况下，期望用更短的时间和更少的人力完成芯片设计任务。
• 但是一些成本是突发的，如缺陷暴露（暴露时机是影响项目成败的关键），成本如下：
  

4. 缺陷增长曲线：

• 给定的激励向量先易后难，发现的缺陷也是先基本后高级。
• 在验证进行过程中，缺陷斜率也应该越来越小。
• 在验证后期，若发现缺陷率在收敛，但是却发现基本缺陷，那说明验证质量较低（验证计划有问题）。
  

5. 验证周期

• 验证团队基于时间差同时进行多个项目，多个项目之间存在借鉴、更新关系，验证环境的复用性不断提高。
• 验证环境准备完毕并有可供测试的激励时，验证人员会对比输出结果，发现对比有误则需要自己调试环境初步定位HDL文件中缺陷大体位置。
• 递归测试（regression），将所有的测试序列都执行一次，测试所有的。
• 四个检查点：
  • 验证计划回顾：联通设计人员和系统工程师一起进行
  • 验证代码检查：回顾验证代码从而发现可能遗漏的测试激励、不恰当的随机约束、代码结构缺陷等。
  • 流片前验证完备性检查：验证经理签字，根据检查清单来量化的验证进度。
  • 吸取教训：防止一个石头绊倒两次。

5.1 验证计划

核心：验证对象是谁？如何验证？

• 验证方法：直接验证（Verilog仿真，定向测试）、随机约束验证、形式验证
• 验证工具：选用不同验证工具支持验证方法
• 验证完备标准：量化参数衡量验证任务是否完成。
• 验证资源：人力、时间、硬件、软件等所有与项目预算有关的。
• 验证功能点： 给出验证功能点、以及在什么层次去验证。更具体的包括生成什么激励，检测设计的何种状态和数据输出。

5.2 开发验证环境

必备技能，但是对大公司来说这项技能在慢慢退化。团队协作要求验证环境标准化，加入一个成熟团队环境可能是完备的。

• 验证人员从搭建环境开始，实现激励产生器（stimulus generator）、参考模型、数据比较器
• 验证环境运行需要软件支持，目前主流仿真工具都可以对仿真验证提供支持。制定验证计划时候就要考虑使用什么验证方法，方法不同验证环境和使用的软件可能不同。
• 随着设计不断完善，验证环境也在不断更新和趋于完善。此时可以进入验证的下一阶段。

5.3 调试环境和RTL文件

在调试上花费时间最多，环境建立在验证早期投入时间较多，而功能的调试是一步步向前推进的。
主要调试点：

• 环境是否有瑕疵
• 测试序列是否合理
• 参考模型是否合理
  上面是对验证部分的调试，下面是对设计的调试
• 硬件设计是否合理

5.4 回归测试

验证硬件在某缺陷修好后或者添加了新功能后，是否能通过之前所有的测试用例和新添加的测试用例。
这些变动包括设计自身的改进、缺陷修复、功能添加、验证环境更新。
回归测试的目的在于：

• 确保本次改动没有引入新缺陷，并且修正之前的漏洞或者安装预定目标实现了新功能
• 随机验证时，随机种子是不同的，因此重复递交一套回归测试表也是有意义的。伴随功能覆盖率，可通过往复回归测试和补充定向测试来提供验证完备性。

5.5 芯片生产

• 回归测试后（RTL回归、门级网表回归），意味着芯片逻辑部分和物理部分全部核查完毕。芯片提交给制造商前，项目经理会同设计经理、验证经理、后端经理一同回顾整个检查表（checklist），通过后进行流片（tape out）。
• 值得注意的是，此时功能验证流程并没完全走完，仍然需要提交回归测试，保持随机测试，在可能覆盖的新状态空间上测试看是否发现新问题。
• 提交给生产厂商后发现问题首先分析问题看是否能通过软件方法解决，不行就提交设计修改意见，下次流片前准备好设计及验证方案。

5.6 硅后测试

• 芯片制造返回后，系统测试人员从底层开始逐步向上级开始测试，测试前将芯片和测试开发板结合起来，或者将芯片植入到待开发的系统。
• 一旦出现问题，首先看是测试方法不当还是实际的硬件问题。
• 硅前人员也要参与，若发现问题首先判断问题的严重性，是否有补救措施。若无法补救那就要在下一个芯片设计周期解决。

5.7 逃逸分析

• 有时难免验证漏洞一直被忽视，直到硅后测试才被发现，这时硬件设计与验证人员需要和测试人员沟通以求在硅前仿真中重现问题。
• 硅后测试补救比客户反馈补救容易很多，因为硬件级别向上堆叠经过驱动、固件再到客户的应用层，问题就越来越难以定位。
• 逃逸分析后，要总结经验：设计如何规避陷阱、完善设计经验；验证如何完善验证方法、产生尽可能多的有效测试序列。
• 对于芯片工程师，每一个关键节点后都要养成总结的习惯，在下阶段有意识去完善，不断成长。

6. 功能描述文档

功能描述文档是设计与验证的基础，是共同参考标准。分别完成RTL设计与验证环境。相当于被实现了两次。验证人员设计参考模型（reference model），使之作出正确的行为和数据输出，通过比对参考模型和实际的硬件设计，来检测是否存在不合预期的情况。功能描述文档包括以下三部分：

• 接口信息：标准接口不需要详尽列出接口时序、命令、数据传输情况，只要给出基本时钟、复位、接口信号名。如是自定义接口，那就需要详细给出。
• 结构信息：各个子模块结构关系与逻辑关系。
• 交互信息：模块与上层系统或平级系统如何交互，包括交互示意图，必要时包含时序图。
• 功能描述文档不包含设计信息。