什么时候验证完成?

决定何时完成验证正在成为一个更加困难的决定,促使验证团队日益依赖指标而不是中列出的测试验证计划。

这种趋势已经进行了过去的几个流程节点,但这需要时间来发现趋势和确定他们是真实的或只是畸变。威尔逊研究小组进行功能验证每两年研究了解验证团队解决这个随着时间的推移,结果是一致的。

特别需要注意的是越来越多的依赖于什么时候代码和功能覆盖说目标已经实现。换句话说,度量为验证持续增长的重要性,根据哈利福斯特,首席科学家验证导师,西门子业务。

图1:ASIC /集成电路项目验收标准。来源:导师图形/威尔逊研究小组。

发生在相同的转变FPGA验证,只有慢得多,如图2所示。

图2:FPGA验收标准。来源:导师图形/威尔逊研究小组。

“今年有趣的结论是,越来越多的人搬到度量为方法,他们不得不关闭覆盖以达到签字,”福斯特说。“工程师认为成功的功能验证是纯粹的科学,与现实是它不是。它是艺术的结合,科学和项目管理技能。这是人的因素方面。问题的一部分,我们在这个行业,很多项目与明确的斗争过程。事实上,有一个行业研究显示项目集中在工具和技术第一,然后构建过程,实际上最终增加成本6%至9%的范围。和他们没有实现生产力。首先项目,关注过程,然后实施适当的工具,最终降低成本20%至30%。一个度量为方法测试计划过程的一个方面,这是你必须预先定义正确的。如果不做,那么你基本上是接近验证以一种特别的方式。”

很多成功的企业都有定义明确的过程。是什么使他们成功可能是人为因素。

“有非常伟大的项目,有一个明确的过程,在这个过程中,他们包括指标的基本衡量成功的过程,”福斯特说。“度量为验证只是一个方面。有不同的指标你随时需要定义一个过程。然而,为什么有些团队发展比其他谁是特别?这是研究的软件世界回到80年代末创建能力成熟度模型时测量软件项目的成熟。”

那些团队成功的原因是他们最优秀的人才。问题是,他们的方法不明确的,因此不可重复使用。“思考过程的起源可以追溯到软件世界的80年代,我们会发送一个火箭飞船,它会爆炸,我们意识到这是一个软件问题,因为软件创建的方式有点特别,”福斯特解释道。

从一个高水平的抽象,验证是对减轻风险没有无限的时间和资源。验证团队力量权衡选项如什么特性的设计更适合模拟或正式的验证或模拟或FPGA原型。

“这不是放之四海而皆准的,”他说。“有些事情更适合某些方法,和回来的规划过程。然后在规划过程,我必须定义与每一个相关指标衡量进展的方法。任何公司的重大胜利,当他们正在考虑他们的计划过程是什么,有度量,并评论。这是最基本的方面。“是什么”我要验证吗?“如何”是很容易的。“什么”是很困难的。”

太多的数据?
但工程师怎么处理各种工具的结果,和如何分析数据了解验证站在哪里?

“我们不要试图详尽验证什么,”说超音速首席技术官。“相反,我们试图样本。我们发现大部分细菌通过生成随机配置的硬件,然后试图自动验证。我们得到更多的角落更快通过运行别人会是什么样子较浅分析相对广泛的配置。这种方法我们已经在过去的20年。在我们的工作正式的技术,我们最大的作品一直在评估如何调优的输入,进入正式环境。我们知道很多关于我们生成的配置,我们如何调整输入,进入正式环境利用的知识。”

然而,这种方法并不适用于所有人。“几年前它被认为设计师应该写正式的验证断言,自我记录,self-specifying,什么是他们正在做的功能行为,”皮特荷迪说,产品管理系统&验证组的主任节奏。“这从未发生过。它仍然是没有真正发生。设计师使用更正式的,它必须是几乎完全自动化。”

这种自动化可以发生在不同的层次,从静态验证自动正式检查,编纂他们在做什么,建立属性库。

一些工程团队希望千篇一律的图书馆,有一个GPU的挑战的情况下,这是他们想要生成的一组属性。所以他们的正式专家完善图书馆和开始使用它的设计者,荷迪说。这是一样的编纂常见的协议——如assertion-based验证IP设计团队可以使用。

但在决定是否设计准备签字时,必须有一些标准。超音速的方法是生成大约1000随机soc一晚,回归他们使用自己的方法,这是相对较浅。然后公司提供相同的技术用于这些回归顾客,所以当他们有一个配置,这就是他们想要签署。然后他们改变旋钮上的验证。

不过,在构建高度可配置的互连的逻辑,例如,有两个报道必须解决的问题。

“一个是传统的模拟覆盖的问题,“你的逻辑的一个实例,你完全覆盖它吗?”首席运营官戴维•帕里表示Oski技术。“另一个是,‘你覆盖了构型空间如何?”,实现的方式超出了任何标准工具的能力;因为你没有实现你的可配置性纯粹SystemVerilog使用参数化。你需要做一些更高级的软件覆盖实现可配置性。和你必须要有一个框架评估(配置空间的覆盖)当你选择你的随机配置或折叠回到客户配置。”

少了什么
更复杂的情况是缺乏规范,或一个不断发展的,指出Sean Safarpour CAE主任正式的解决方案Synopsys对此。“在正式的世界是如此的有趣,因为我们谈论完整性和穷尽性等等。但是一旦有问题,你让你的属性表,你会发现这些都是证明。客户只是看着,说,‘我想要100%的证明,他们把我们如此努力。你做的所有工作,退一步,你问规范在哪里。我们花了那么多时间最后五个属性来证明,然后你发现没有规范,努力错了方向,因为指标和数据,但我们都是工程师,我们关注。”

除了这个,荷迪认为覆盖率指标应该测量后一定期限的设计由于大量的迭代设计。

这并不总是可能的,并不是每个人都同意这是必要的。“你不需要等到你的计划,因为你永远不会得到这个计划,因为你永远不会得到规范,“Darbari说产品管理主管OneSpin解决方案。“设计师的工作是编写一些代码。我是一个直接测试的人。阿施施走过来,告诉我写断言。我爱我的断言。这是一个断言,运行范围。我实际上覆盖30%的这种设计这个断言。好的,另一个发现我现在为50%。哦,不,我现在有一个错误,因为这张支票我添加了暴露一个错误在我的设计和我的覆盖率下降了。的覆盖需求开始设计窗口的第一个小时。如果你不这样做它不会帮助。”

这是整个推动“左移位”,许多的设计并行完成,而不是按顺序。在理论上这是伟大的,但实际上它并不总是明确的迭代,因为一些事情发生,特别是当有问题。

“在功能验证很难说,“我完成了”,因为实在是没有一个好的模型来预测,做完了,”说,公司的首席执行官真正的意图。“你可以试着让这个过程更高效的基于经验,和我们可以体验远离它。”

不影响验证的目的,最终是降低风险。说:“完整的验证是一个神话Synopsys对此Safarpour。“我们其中的一个应用,人们已经签署了块除了正式的在过去的几年里。大约30%的错误没有检测到,他们说,“嗯,我们将签署。他们有经验,已经实现了几年。即使你告诉他们所有的数据,他们知道,去发现,他们将需要四个月。”

Narain也有类似的观点:“在一天结束的时候,它是关于资源和进度。你只能做这样一份好工作,许多资源的时间和数量,和你的角落,你会冒险,这是从来没有完美。”

对于某些应用程序,这是最好的信心,你可以得到在给定的时间。但高安全性的应用程序时,在汽车、医疗电子等市场,是一个完全不同的故事。

“你要有可追溯性,你必须有一个更完整的想法,当你完成“荷迪说。“我们定义验证签字没有检查失败,而达到定义的覆盖水平。为了显示声明,它从来没有充分证明的声明。它总是对这句话的信心。但那正是我所需要的自信程度。这是一个基于应用程序决定。和关键的应用程序,要求那些有很多困难。如果你想见面ISO 26262,你需要跟踪,需要故障注入,你需要能够传播分析这些错误。你绝对需要知道如果这些故障传播功能输出,这些缺点总是会检测到的跳棋吗?”

结论
好消息是,数据显示行业作为一个整体是成熟和识别代码覆盖率的重要性,功能覆盖或其他指标来衡量我们的进步在验证,福斯特说。“关键是,我们必须定义,所以指标不发生特别的。你必须计划。越来越多的公司正在使用这些度量为方法签字表明他们是给它很多认为正确的计划。”

在工具方面,事情似乎是在良好的IP功能验证,他指出。“方法很明确的。我们有UVM标准。我们有能力通过UVM真正走出去,获得外部IP和填补它在相对容易。之前有一个标准,这是极其困难的。所以我们在相当不错。”

应对未来挑战是在系统层面上,和SoC集成水平,传统指标IP通常不工作。“比如我们使用代码覆盖率和功能覆盖率在IP层,”福斯特说。“那些有效的系统层次较低。的部分原因是,覆盖水平更多的统计性质,所以有机会开发新的解决方案更关注系统和SoC集成级别。”

有关的故事
验证是必要的多少?
解决问题要使用哪些工具是一个必要的第一次迈进的一门艺术。
验证统一
专家在餐桌上,第3部分:电力、安全、安全便携刺激和正式如何帮助所有这些。
验证在云中
是半导体行业作为服务EDA终于准备好了吗?
验证和物联网
专家在餐桌上,第3部分:转移,延长;使用机器学习和数据挖掘寻找新的bug和开辟新的使用选项。