【路科V0】systemVerilog基础21——从功能描述到覆盖率

概述

要实现功能覆盖率的收敛，就需要按照以下步骤考虑:

• 哪些功能需要测试
• 明白在什么条件下需要测试对应的功能
• 为了测试这些功能，需要提供什么样的测试平台组件以便提供激励和监测
• 测试平台如何检查这些功能正常工作

由于功能覆盖率不是自动的过程，因此它需要将功能描述同设计实现对应起来。

提取功能点一般遵循从外部接口到内部功能再到边界情况的方法。

提取功能点 

提取接口功能点

对于要验证的设计的各个接口，可通过以下问题来获得接口功能点:

• 必须应用哪些传输?
• 什么样的取值范围?
• 什么样的传输顺序?
• 相关的传输带宽是多少?
• 设计能够承受哪些协议违规?
• 此接口与其他接口或内部设计结构之间的相关交互是什么?
• 接口上的事务是否需要与另一个接口的事务同步?

提取内部功能点

遵循设计的主要数据路径，可通过以下问题来获得内部功能点:

• 所有相关配置是什么?
• 可以对数据执行哪些可能的转换?
• 可能的转换顺序是什么?
• 触发转换的敏感数据值是什么?
• 影响每次转换的敏感值是什么?
• 转换后的数据应该在哪里结束?
• 数据序列如何受到影响?
• 存在哪些错误检测机制以及它们是如何触发的?
• 错误机制如何报告错误?
• 错误数据会导致什么?

提取结构功能点

        最后，基于对设计架构的详细了解，确定将设计推向极限的条件，可询问以下问题来获得基于体系结构的功能点:

• 我可以溢出或下溢缓冲区吗?如果是这样,会发生什么?
• 资源瓶颈在哪里?
• 可以同时发生对这些资源的多个请求吗?
• 数据转换路径是否可以影响或者阻止另外一个模块?

标记功能点

        功能点应被标记并有简短说明，根据需要验证的条件和预期结果来描述该功能，而不是如何实施。

        每个功能点都应该与功能描述文档中描述它的部分交叉引用。指定验证该功能的验证层次。

        发现违反时，应在错误消息中使用功能标签。

        在错误消息中包含功能标签，将有助于识别出错的内容以及评估设计行为是否确实不正确。

验证分层

        在例举功能点时，请注意为它们指定适当的验证级别。

        某些功能在块级别可以得到更好的验证，而其他功能必须在（子）系统级别进行验证。

        通常会有大量功能点与设计中的某些关键功能或单元有关。如果实现该功能、或者包含该单元的设计没有被单独验证，那么，可能是时候重新考虑你的验证计划了，因为这可能表明该单元需要独立验证，以达到必要的验证完备性水平。

优先级划分

         对于一些设计必须具备(must-have）的功能，才能正常运行来满足市场需求，完成对这些功能的验证可以成功完成项目，而验证这些功能的测试平台通常也位于关键路径上。

        对于设计的商业成功而言，应有(should-have）的功能是次要的。他们可能只是提供扩展能力帮助在竞争中脱颖而出。对于这些应有功能,主要验证其操作的基本功能。

        一些功能仅仅是建议的(nice-to-have)）。它们仅在时间允许的情况下被验证，不过从目前的项目压力来看，这些功能很少在第一次流片前被“照顾”到。

        在项目进度很紧张的情况下，可以需要在验证过程中对验证计划和功能点做出调整。有的时候，需要删除一些必备功能的验证来追赶项目节点

从随机测试到功能覆盖率

         随机测试所产生的激励数量和功能组合场景要远远多于定向测试。定向测试与待测试功能点联系紧密，而随机测试则不仅与待测功能点，还可能同时测试其它功能。

        因此衡量随机测试的进程不应该以测试是否通过为准，而是应该通过功能覆盖率模型，在项目初期到结束一直收集随机激励的类型。也只有通过覆盖率模型，才能让随机约束的历史产生轨迹变得有迹可循。

覆盖率实现之考量

考虑哪些数值是重要的?

哪些变量之间是有联系依赖的?

不同的功能有哪些边界情况需要检查?有哪些非法的情况需要考虑?

是否可以区别哪些是重要的功能，哪些是次要的功能?

在什么条件时适合去采样?

• 只有对某些功能检查时，才可以使能对应的覆盖率收集。
• 当变量有效时或者稳定时 

验证例子——MCDT

 MCDT测试功能清单