日志
验证的计划篇之一：计划的概述
| ||
在选择验证方法和构建验证环境之前，我们首先需要清楚验证计划是什么。在展开设计之前，设计人员和验证人员都会阅读功能描述文档，以理解设计的各项功能为前提，来考虑如何验证它。如果功能描述本身不清晰，则需要同系统人员沟通来修改功能描述文档；如果设计和验证双方人员对于某一项功能理解有不同的地方，也需要最后同系统人员的解释保持统一。
那么一旦完成了验证计划书，还需要对其进行修改吗？答案是需要。因为在实际项目执行过程中，功能描述文档和设计会不断更新，直到芯片到流片前都有可能在一直进行，那么验证人员就需要做好相应的验证计划更新。所以，验证计划的生命在设计被构建之前就诞生了，伴随着设计的周期，直到流片。
伴随着验证计划的创建，计划流程可以分为若干个步骤，它们包括：
- 创建验证计划
- 选择验证方法
- 人力资源调配
- 构建验证平台和环境组件
- 开发测试用例
创建一份验证计划是首要的任务，通过收集下列材料可以更好地组织出有价值的计划：
- 结构功能描述
- 设计的各种操作使用模式
- 在正常输入和错误输入情形下设计的行为
- 设计的接口
- 在一些边界情况下设计的行为
- 设计在现实中使用的场景描述
通常上面的这些资料可以从硬件功能描述和系统文档中找到，同时，也可以从硅后测试、固件开发人员那里得到设计的实际使用配置情况。
通过合理的验证计划，可以为芯片开发带来很多好处：
- 使得设计和验证人员对于功能描述文档的理解和翻译保持一致。
- 将自然语言描述的功能通过可测试的语言来描述。
- 可更合理地评估出工作量、人力安排和进度节点。
- 为验证人员提供更清晰的验证目标、任务和进度安排。
- 为功能文档提供反馈，修改文档中不明确、有歧义的描述。
从更宽泛的意义上来看，一份验证计划几乎可以囊括所以跟验证相关的东西，这其中不单单包括要验证的设计功能，还包括验证方法、人力安排、进度评估等等。由于验证计划的生命期很长，在实际环境中，有很多因素会不断影响计划的更新，这些可能的因素包括：
- 会有不同人员更新验证计划。一份充分的验证计划，需要系统、设计、验证、软件人员给出意见，共同参与制定。
- 需要更新上百上千的测试用例，并且与计划中的待测功能映射。
- 考虑选择不同的验证方法，如果有多种方法并用还需要使得它们之间保持兼容和跨越式的复用。针对不同的设计，需要考虑选择动态仿真、形式验证或者硬件加速方法，如果采用两种以上的方法，还需要考虑如何实现技术平台上的跨越复用。
- 如果有新的设计要求，需要更新计划，同时设法对人力和进度的影响降低到最小。在设计的过程中，设计人员仍然会收到新的功能需求，那么一旦确定下来添加新的功能，就需要考虑额外的人力和对于进度的影响。
- 如果有多个组参与验证，需要考虑如何协调。对于大型的SoC项目，一般会有多个功能组参与，甚至他们会在不同的城市办公，这时候去协调组跟组之间的工作，并综合出整体进度结果就很重要了。
通过在早期制定出一份验证计划，并且伴随着设计更新和验证过程不断修改和跟踪，就可以提高验证的质量，同时降低项目的风险。同时对于人力和时间进度的合理估计，也使得验证进度和流程更加透明。下一篇我们会来阐述《计划的内容》，感谢你的持续关注。
/2 
eetop公众号
创芯大讲堂
创芯人才网