验证是一个流(第1部分)

半导体工程坐下来讨论验证从工具的转换与弗拉季斯拉夫•Palfy流,全球工程管理器应用程序OneSpin解决方案;戴夫Kelf,首席营销官Breker验证系统;马克•克拉产品营销经理导师,西门子业务;拉里悟道、产品管理总监、系统&验证小组节奏;副总裁和罗杰Sabbagh应用工程Oski技术。以下是摘录的谈话。

SE:的日子验证作为一个点的工具在我们身后,我们来添加便携式刺激(PS)的混合。流是如何整合?

Kelf:有很多验证引擎被人这些天,他们必须产生刺激或testbenches对他们来说。还有断言为正式的,UVM刺激模拟,很多C测试模拟。它非常断开连接。人重写本质相同的测试在不同的格式。PS是解决这一问题,但它是比这更大的和更广泛。这是关于创建一个高层次的设计意图和规范允许的一系列测试向量的不同部分验证流是来自。验证的主要范式转变,类似于从静态的,指示测试随机测试生成。

悟道:验证不是一个具体的事情了。这是一个流。它是多层次和多引擎。需要的不仅仅是一个模拟引擎来完成你的验证工作。你还必须处理更多的水平——不仅仅是IP验证,但扩展的软件堆栈可能。PS,认识到挑战你看纵向一体化和横向分布的测试平台。这是一些令人信服的理由的建立一个新的标准和PS会攻击。

Sabbagh:作为一个行业我们已经走过了漫长的道路发展的流动,而不是一堆不同的工具。PS可能,在未来,帮助做出更好的和解决的一些问题。但是我认为还是有问题,一些大的缺口。我们的客户在开发和维护流动面临一个巨大的挑战。我们把一个大负担用户流的工作。我们真的应该定义一个流是什么意思。不仅仅是一个过程,它是一个自动化的脚本和各种输入和输出在不同阶段和不同的工具。一些相关的刺激和一些有关报道或调试。我们必须考虑所有这些方面。我们帮助我们的客户在战壕里做验证。客户必须填补空白,他们有大量的基础设施投资,在维护翻译和脚本。这是一个必要开销来完成工作。我们看到的问题合并覆盖是一个尚未解决的问题。合并从正式和仿真——这是尚未解决的。

Palfy:这是伟大的听到PS被新的东西。作为一个正式的家伙,我们不再是新人。我们希望PS不会是一切的来源,尽管有些人希望这种情况发生。集成时,我们也必须帮助我们的客户做这项工作。我们有一个委员会报道(uci),这不是真正的锻炼。但是你必须进入战壕,先解决客户的问题。我们试着听他们需要什么,而不是想出新东西。

Kelf:作为副uci -你是对的。不工作了,我们有几个在过去的几个月里讨论的原因。这就带来了一个很好的观点。它要求所有供应商之间的合作,试图让他们工作。在PS,我们合作。我们要去哪里。在uci没有合作。每个人都有不同的模型,它定义了各种类型的流。没有人能弄清楚如何将它们组合在一起。没有很多的业务驱动,所以确实提出了业务方面。 How much does that weigh in and create discontinuities in the technical flow because of business reasons? This is something EDA has to come to grips with.

悟道:有两个方面,业务问题。供应商的成本。供应商犯了一个巨大的投资发展,发生在这些引擎和嵌入引擎覆盖模型,这些模型需要映射。你能承受多少重新设计与你得到什么回报。

Palfy:公平地说,它不应该火箭科学。应该有一种方式来巩固,如果所有的委员会将一起工作。这意味着人们使用定制的解决方案,这样他们可以继续他们的日常工作,而不是等待一个委员会来解决这个问题。

克拉:有标准或先决条件是一个很好的第一步。我们有一个uci标准,但我们不能合并来自不同来源的报道。我们有UVM标准,更好的迁移,但它仍然不是无痛。你想要从一个模拟器testbench到另一个模拟器。试着设计,编译的三大模拟器和运行在另一个。

Sabbagh:不仅是设计。它是testbench UVM。

克拉:这是整件事情。我们有所有这些标准,这在理论上成为可能。考虑调试。现在,调试是一个主要的问题,因为我们不允许读一定格式(FSDB)。我们正试图找出如何协作共同调试交换格式。

Sabbagh:我们在这里探讨的是关于供应商之间流动,这给用户一个巨大的负担,因为他们通常有一个dual-vendor策略和他们想要的整个流能够与多个供应商的合作。所以他们最终投资大量的时间。我过去做过的——建筑包装工具,使它看起来好像两个工具是一样的。但即使是在一个供应商的流程,仍有差距。如果我发现一个错误在正式和给设计师,他希望能够快速运行相同的刺激导致错误模拟器,然后展现出同样的跟踪将固定设计。这是比它应该更加困难。

Palfy为客户:我们这样做。我们可以生成一个波形,进入正式的任何模拟器引擎。

Sabbagh:是的,这是一个实用程序,。使用反例和创建一个模拟testbench。但在单一供应商的流程,提供了一个正式的工具和仿真工具。很难得到流动工作,或者是不存在的。这是一个差距,用户必须填写。另一个问题是贵宾。我们还没有谈到重用。人们想要重用他们的贵宾,它不会工作无缝地从正式的模拟仿真和实验室。

悟道从消极的一面:转变什么不工作和差距,让我们退一步,看看客户的验证和流的重要性和它是什么做的业务。验证是关于创建可见性和可预测性的问题当产品是要做时,它会满足我的质量目标,我能做我的人数。这是很重要的。这是重要的。如何给我门的产品吗?如果我试着这样做,把多个变量,将集成问题,我将不得不处理。这是野兽的性质,即使有标准。我们不能忽略游戏结束。新标准如PS可能有助于解决这个问题。我如何停止复制工作如重写测试跨平台工作? We are trying to take care of the gaps that we can take care of in the overall flow, but we will not come together as competing vendors and say – how do we make our stuff plug in seamlessly with yours. We are trying to provide a solution to our customers that will help them get their job done.

Sabbagh:你正在谈论一个流或脚本工具,但现在我们正在谈论的方法验证和验收和管理你的资源。这是一个工具或语言不能解决。通过多年的经验提供验证大型出类拔萃。

悟道:如果你看看验证管理,推动我们前进的事情交付的可预测性是持续集成等——的想法我建筑的事情,和我建立我测试它们。的数量变化,我看到当我经历的过程是更少的惊喜和更多的可见性,发生了什么,这些都是让不同的客户的成功率。我们正在接近工具开发从这个角度来看。它告诉我们他们需要的可见性。

Sabbagh:我不是想过于消极,行业已经走过了漫长的道路和工具厂商正在做大量创建流工作。但仍有差距。该工具流不能解决整个验证过程和管理。你还需要大量的经验和专业知识的人员来管理项目,并知道如何使用指标。什么时候你开始做某些任务在项目?

Palfy:这是一个方法,你需要运用正确的方法,正确的类型的问题。

悟道:从产品管理的角度方法指定产品的可扩展性。定制是不可避免的。客户都想做不同的事情,你必须思考能力交付和客户想要扩展它。它需要可扩展的哪里?他们想要访问什么数据?和他们想给访问什么数据?


Kelf:我看到在过去的几年里改变了最终用户的交互与EDA供应商。PS是有趣,因为我们有这个大委员会的最终用户和EDA供应商。我已经注意到,客户倾向于把工作留给EDA供应商等问题比以往更多的互连与合作。正因为如此,EDA厂商在竞争。我们每个人努力创建我们自己的流,与小公司试图成为不可知论者使用的工具在这些流动。很难建立连接,除非有最终用户的需求。除非客户推动,大的EDA供应商将创建自己的单片流和小的适合在尝试。这将创建动态人们继续鹅卵石的事情在一起,要做定制。这是一个问题。最终用户需要创建至少一些压力让供应商一起工作。 In UCIS we have discussions about some basic verification problem that really should have one or two possible solutions, but many variants exist because each EDA vendor has gone down a path that is different from the others. Why is that? Why can’t we have one model? For UCIS there isn’t enough customer pressure.

Palfy:它必须是面向消费者的。建立一个流安全就是一个很好的例子,比如汽车所需的这些天。我们可以连接到特定的模拟器和simulator-agnostic,和我们有一个流。有些问题可以解决与正式的引擎,但还有其他的,我们只能帮助一个模拟器。有一个清晰的客户需求。从这个意义上说,我们没有竞争。我们互相帮助。在一天结束的时候,这些钱来自解决客户问题。

克拉:我们师的事情,比如刺激和调试,使用我们自己的工具。今天我们在刺激投资、分析和数据挖掘、验证管理和指标尽可能引擎独立。的一部分,这是因为无论如何我们必须这么做,只是为了支持模拟和仿真。不久将包括一个原型系统。它导致我们沿着路径和客户不使用一个模拟器。其中大部分是使用两个或三个。他们有充分的理由,所以你不能成功的新一代技术如果你只支持自己的技术。