覆盖率的要求
覆盖率是衡量激励生成种类和功能点验证的量化指标。无论通过何种验证方法，我们都需要采用覆盖率来确保给出了足够多的激励类型，并且设计的边界和内部穷举了可能的状态。
覆盖率可以分为代码覆盖率、功能覆盖率和断言覆盖率。除了给出合法的激励之外，也需要考虑给出一些错误的激励，来测试设计的稳定性和纠错能力。
在验证过程中，我们需要不断地更新验证进度，从各项参数综合评估验证的完备性。我们通过收集以下信息来评估验证计划的实施进度：
※回归测试通过率，一份回归测试表是将测试设计所有功能点的用例合并为一个测试集。回归测试表的主要功能是用来在设计经过缺陷修复或者性能提高后测试原有的所有功能点，确保设计仍然可以正常工作。为了能够保证测试出来bug的场景可以重现，我们需要在测试中显示每次使用到的随机种子，只有通过这个特定的种子，我们才可以重新产生之前的激励，跟踪调试失败的用例。
※代码覆盖率，代码覆盖率是用来衡量RTL代码是否被充分运行的指标，目前的仿真器也都提供方法来收集代码覆盖率，并且进行合并和分析。
※断言覆盖率，断言描述本身也支持覆盖率收集，一般可以通过仿真或者硬件加速的方式来收集，也可以通过形式验证的工具来收集。
※缺陷曲线，在验证过程中，我们会不断地发现新的设计缺陷，通过缺陷记录表或者已有的商业工具记录下来，进而提交给设计人员。
※寄存器覆盖率
验证的不稳定因素
※芯片结构不稳定：如果在项目执行后期，突然面临结构的变化，这肯定会给相关设计带来很大影响，而验证任务量和时间也需要发生改变。
※工具的不稳定：在新的项目中，更倾向于使用新的工具版本，因为它们会带来新的性能提升和特性提升，而在新版本工具使用中也会有适应期，并非一帆风顺。如果我们需要替换工具，那么面临的工具替换成本、环境流程更新、技术培训都要更大一些。
※模块交付时间的不稳定：由于验证的展开与设计的交付时间密不可分，所以HDL设计的交付时间对于验证进度的影响非常大，所以在计划初期，验证经理应该从设计团队哪里获取清晰的交付时间，然后在此基础上做进度和人力安排。
验证计划
一份验证计划的模板应该包括下面的结构：设计功能简要描述硬件实现框待验证的功能点验证环境搭建测试用例构成编译脚本和回归测试覆盖率分析。
创建验证环境
在实现激励发生组件中，需要考虑接口信号是标准总线还是系统控制信号。如果是标准总线，那么应该有对应的总线验证IP的复用资源，这样会节省构建平台的时间。
我们也要考虑收集数据和对比结果，这就需要监视信号组件和检查组件的实现。监视信号组件的主要任务是监视设计的接口信号以及内部信号，如果是总线接口，那么需要在解析总线的情况下将观察到的数据打包处理，如果是其他控制或其他信号，也需要按照信号的定义，在特定的事件下捕捉有效信号。
监视信号组件最终会将分析整理好的数据发送给检查组件，由检查组件进行数据比较，给出比较信息和报告，最终判定测试是否成功。
验证的周期
芯片框架和模块功能定义完成，指定验证的策略。
模块和子系统的功能信号定义完成，定制需要的存储模型。
完成芯片系统的连线集成和验证，覆盖所有的功能验证点。
GLS：完成门级网表的验证。
Tape-O：回顾验证的各项检查清单，最终流片。
回归测试指的是每次将所有测试用例提交到服务器上运行，并且检查测试结果。对于模块级的回归测试，这种方法在时间和计算资源上也许是可行的，然而对于芯片级，这种方式每次要消耗的时间和资源恐怕需要重新考虑。
回归表
提升回归效率
在可实现的情况下，考虑切分测试场景，讲一个场的测试序列切分为多个序列，并为之创建多个测试用例。这么做的好处是避免过于冗长复杂的测试，划分为多个用例可以实现并行提交测试，用计算资源来节省时间。
而对于一些比较难切分的测试场景，例如芯片级仿真需要首先完成上电、复位、时钟使能，同时芯片处理器需要完成初始化、搬运执行代码的过程。我们可以考虑通过在完成上述操作之后的时间点比如500ns设置一个快照保存当前的变量和状态，在之后的仿真可以直接跳过前面的步骤直接到500ns，读取快照接着仿真，这样可以减少很多时间。
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论