伴随着复杂SoC系统的验证难度系数成倍增加#xff0c;无论是定向测试还是随机测试#xff…目录

一、概述

伴随着复杂SoC系统的验证难度系数成倍增加无论是定向测试还是随机测试我们在验证的过程中终究需要回答两个问题

覆盖率就是用来帮助我们在仿真中回答以上问题的指标。

如今覆盖率已经被广泛采用作为衡量验证过程中的重要数据。

测试平台必须产生合适的激励来触发一个设计错误测试平台仍然需要产生合适的激励使得被触发的错误可以进一步传导到输出端口测试平台需要包含一个监测器monitor用来监测被激活的设计错误以及在它传播的某个节点内部或者外部可以捕捉到它。

1、概述

的功能覆盖率。

原因在于代码覆盖率并不是用来衡量设计内部的功能运转或者模块之间的互动或者功能时序的触发等。

90%的代码覆盖率。

原因可能在于我们疏漏了去测试某些功能或者一些实现的功能并没有被描述。

从上述关于代码覆盖率和功能覆盖率简单的论述就可以证明如果想要得到全面的验证精度我们就需要多个覆盖率种类的指标。

2、分类

按照覆盖率生成的方法即隐性生成还是显性生成。

按照覆盖率溯源即它们从功能描述而来还是从设计实现而来。

例如功能覆盖率是显性的需要人为定义的覆盖率而代码覆盖率则是隐性覆盖率这是因为仿真工具可以自动从RTL代码来生成。

断言覆盖率以及功能覆盖率分别置入到不同的象限。

但是需要注意目前有一个象限仍然处于研究阶段没有隐性的可以从功能描述生成某种覆盖率的方法这也是为

代码覆盖率隐性覆盖率功能覆盖率显性覆盖率

衡量验证进展的最简易的方式是使用代码覆盖率。

这种方式衡量的是多少行代码已经被执行过(行覆盖率)在穿过代码和表达式的路径中有哪些已经被执行过(路径覆盖率)。

哪些单比特变量的值为0或1(翻转覆盖率),以及状态机中哪些状态和状态转换已经被访问过(有限状态机覆盖率)。

不用添加任何额外的

HDL代码工具会通过分析源代码和增加隐藏代码来自动帮你完成代码覆盖率的统计。

当运行完所有测试代码覆盖率工具便会创建相应的数据库。

许多仿真器都带有代码覆盖率工具。

后续处理工具会把数据库转换成可读格式。

最终的结果用于衡量你执行了设计中的多少代码。

注意,你的主要关注点应该放在对设计代码的分析上而不是测试平台。

未经测试的设计代码里可能会隐藏硬件漏洞也可能仅仅就是冗余的代码。

代码覆盖率衡量的是测试对于设计规范的“实现”究竟测试得多彻底而非针对验证计划。

原因很简单.你的测试达到了100%的覆盖率并不意味着你的工作已经完成。

如果你的代码有漏洞但是测试没找到怎么办?或者情况更差一些,如果你的代码实现中遗漏了某个必要的特性怎么办?所以单有代码覆盖率还远远不够。

四、功能覆盖率

验证的目的就是确保设计在实际环境中的行为正确实际环境可以是MP3播放器、路由器或移动电话。

设计规范里详细说明了设备应该如何运行而验证计划里则列出了相应的功能应该如何激励、验证和测量。

当你收集测量数据希望找出哪些功能已被覆盖时你其实就是在计算设计”的覆盖率。

例如对D触发器的验证计划除了涉及触发器的数据存储外还应该检查触发器如何被复位到某个已知状态。

在你的测试对这两种设计特性全部进行验证之前、你就不能达到100%的功能覆盖率。

功能覆盖率是和设计意图紧密相连的有时也被称为“规范覆盖率”而代码覆盖率则是衡量设计的实现情况。

设想某个代码块在设计中被漏掉的情况。

代码覆盖率不能发现这个错误,但功能覆盖率可以。

五、从功能描述到覆盖率

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

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