系统覆盖未定义

当设计可以录音吗?一直是一个棘手的问题要面对每一个设计团队,这是一个验证工程师失眠。

详尽的报道自1980年代以来已不可能。定义了几个指标和方法来帮助回答这个问题和提高信心,一块已经验证的重要方面。但这些指标和方法难以跟上日益增长的复杂性,和他们不规模系统的水平。新框架的理解报道和完整性是必需的。

功能覆盖定义约束随机验证块级别的,不是一个合适的指标。它是基于未经证实的活动在一个设计的观察。覆盖模型基于这个概念很难定义,和完整性只能确定回代码覆盖相关的设计。与此同时,代码覆盖率十年前作为一个被抛弃的不足主要覆盖指标,因为它没有考虑数据依赖和合作等概念。

简而言之,两个不完美的指标被依赖于今天提供必要的信心,设计已充分证实。

的出现便携式刺激标准从Accellera应该启动新一轮的讨论要回答这个问题,对未来的尺度。目前,行业主要集中在工作如何改造现有概念和想法到新的领域。

在这样一个时代,芯片是由添加块,重要的是,系统级验证集中在块级别没有得到证实。但问题是:什么是强烈的良好指标与系统级问题?

改变焦点
几件事情改变了验证环境SystemVerilog和UVM被创建。其中的一些相关验证的机制,而其他相关报道空间。”知识产权和子系统验证,使用UVM和约束随机的,目标通常是验证设计的所有功能详尽,或尽可能详尽,独立于任何SoC背景下,”迈克Stellfox说,研究员节奏。“设计特性很好地映射到功能覆盖组和跨越的。它不是为大规模建造soc,你通常验证跨多个平台和集成软件,如模拟,模拟,FPGA原型和硅”。

虽然报道可能已经定义为每个块,可能不提供答案系统级覆盖。“覆盖率模型在系统水平不仅仅是一个聚合模型所做的所有的块,“断言马克·克拉产品营销经理导师,西门子业务。”,只会让你重复所有的工作和更困难的环境中。所以,一定是些不同的东西。”

事实上规模呈现一个不同的维度。“系统级覆盖和大数据有一些重叠,”状态,公司的首席执行官Breker。“一个非常简单的手臂系统有10 ^ 93通过便携式刺激可能的路径图。我们可能还需要看所有可能的组合。所以当便携式刺激可能定义覆盖空间,它回避了问题的报道意味着什么。我们也没有办法知道如果这是完整的。”

Stellfox表示同意。“在SoC级别,你是处理稀疏覆盖。没有人会试图验证每一个交互的SoC设计特点。规模太大了。”

定义覆盖空间
便携式刺激图定义了目标函数,设计是为了执行。这些通常被称为场景或用例。它本质上是一个可执行的需求文档和被定义为一种工具可以生成用例图。这些完成自检测试点和测试点可能会生成运行在多个执行环境。

图为部分规范,它不需要完整的可用。一旦一个路径设计被定义,它可以用来生成测试用。如果图覆盖每一个目标设备的系统级功能,那么图定义覆盖空间的一个方面,但不是全部。

图1:覆盖空间。礼貌Breker。

除了每一个可能的路径,我们还必须包括所有并发活动相结合,通过图。如果只有两件事可以同时发生,那么总覆盖空间X (X - 1),其中X是路径的总数。这假设所有路径都是独立的,这可能并非如此。事实上,有方面,不能从PS图。

PS不模型的硬件是什么,只应该是能做什么。所以它并不总是能够提前知道给定测试会做。考虑这样一个测试,两个线程每个需要访问资源,只能服务一次。PS工具可以安排当每个线程应该访问,但测试生成器不知道多久前的任务可能需要,因此可能不知道订单或来自两个线程的方式请求可以重叠。必须有一个信息路径的测试执行PS工具以便覆盖率数据注释。

还有其他方面的测试生成的原因也可能推迟到执行时间内,这些决策目标还必须得到传回给覆盖工具。

完整性
PS图的完整性是难以评估,因为它涉及需求文档,这可能是用自然语言写的。“你需要确定系统的主要事情是能够做的,”哈米德说。“然后你就可以开始先后分解他们,这样你认为通过所有的使用模型设计可以通过反复核对,对功能列表”。

在过去,完整性验证了通过比较对一种不同的覆盖度量。例如,功能覆盖验证了通过查看代码覆盖率和识别部分的设计并没有行使。这将显示测试没有书面或覆盖点人失踪。

仅仅是有可能的,因为功能和代码覆盖率都是与实现,因此自然重叠模型。但实现覆盖和意图覆盖率是两个不同的东西,在系统层面上,意图覆盖率,是很重要的。“我们使用实现覆盖代替意图覆盖率在过去的20年里,“继续哈米德。“验证是证明一个实现匹配的意图。目的是我们需要的芯片。100%的实现覆盖率并不能保证你有任何意图的报道。”

那么,我们如何确保覆盖空间的完整性?我们知道,一个现实的覆盖目标不能覆盖空间的所有方法。稀疏覆盖,没有期待的所有部分的设计将由系统级测试。这仍然是块级验证的作用。所需要的是一个方式来定义总覆盖空间的子集被视为足以在系统级验证。

“你不能看它以同样的方式作为当前方法,代码覆盖率,FSM覆盖,等等,”说阿施施Darbari,产品管理主管OneSpin解决方案。“虽然他们提供增量增值,需要整个覆盖空间的整体视图,你不能获得的部分。”

定义覆盖的目标
这就是行业今天陷入困境。系统级的范围不仅仅是看功能。它是性能和权力的地方必须验证,。

“在SoC验证,力量和性能成为同行功能的重要性,“Stellfox说。“考虑汽车芯片与视觉识别处理,和你有一个用例,你不能得到足够的带宽之间的相机接口和加速器。可以是一个灾难性的失败,这是一个性能问题。我们需要的是能够构建环境压力性能和功率,和跟踪取得了用例,你想要的。”

似乎合理的要求最坏的场景的组合是什么?“如果你设计的产品坏的情况下,你最终得到的产品是如此严重的过度设计,这不是有趣的经济,”说,首席技术官超音速。“最坏情况的简化的假设太保守。艺术是试图找出在时域什么事情不会发生在同一时间,说服自己,这是安全可靠的。这是一个困难的问题。这使得架构师的工作更有趣。”

该行业目前正在试图定义的一些最佳实践。“我们如何给SoC验证带来一个更系统化的方法,以类似的方式UVM带来了系统的最佳实践方法的应用约束随机在IP和子系统层面,“Stellfox说。“PS的可能性将相同类型的soc和大系统方法。”

定义一个覆盖模型
所以工作组应该来定义一个覆盖模型寻找便携式刺激?“标准协议的语法,格式和语法,”克拉说。“这不是想要什么一个标准化。会有标准化的方法写指标?今天我们有机制,允许我们的客户建立这些指标。他们可能会使用一个标准的语法(SV覆盖组、模型、点),但它们很特别适应目标可衡量的。我们设想类似,有标准的方法来描述这些措施。”

我们甚至需要覆盖在系统级别吗?PS主要是关于创建指导测试的模型,虽然他们可能会雇佣一些随机化,测试区域是由用户定义的。“我没有见过很多人做测试他们担心覆盖,“Darbari说。“大多数时候他们只是写测试。”

Stellfox补充说:“大部分的你正在试图做的是确保你有某人与应用程序知识清晰地定义什么是最重要的测试用例,甚至应该如何把那些用例串在一起的方式可以很容易地近似结束软件应用程序如何使用系统。”

我们必须承认,公司今天正在做系统级验证。“他们有很多本土的东西,所以这意味着我们作为供应商不提供一个标准的工作做得不够好,”克拉说。“作为一名工程师,如果我找不到适合我的市场,我建立我自己的。一旦一个人有一个可伸缩的、可重用的选择,那么我不能浪费我的时间做了。”

实施范围,供应商已经在自己的方向,使得用户很难聚合覆盖从多个工具。统一的覆盖标准的互操作性定义,试图让那些指标达成一致,但每个供应商的覆盖语义是不同的,这是有问题的。

很可能用户将采用多个PS工具,因为每个供应商可能excel在某些领域,如针对仿真或芯片启动。这意味着他们会想要回到原来的图覆盖所有数据相关,是一种常见的模式,提要的所有工具。

系统级覆盖需要定义,或者至少,机制来定义它需要共同的所有供应商。没有,该行业将会做伤害设计社区。

有关的故事
什么时候验证完成?
答案取决于越来越多的非常复杂的因素。
FPGA原型的进展
流行的设计方法使更复杂的硬件/软件验证之前第一个硅可用。
便携式刺激状态报告
早期版本的20年来首次新语言正在审查随着最后期限的临近。