验证记分卡:行业表现如何?

半导体工程公司的销售副总裁Larry Lapides坐下来讨论验证工具和方法如何跟上需求治之软件；Mike Thompson, OpenHW验证任务组的工程总监;保罗·格雷科夫斯基，技术营销经理Arteris IP；Shantanu Ganguly，产品营销副总裁节奏；和Mark Olen，产品管理总监西门子EDA．以下是那次谈话的节选。讨论的第2部分是在这里．

SE:威尔逊研究公司和西门子EDA进行的功能验证调查指出了一些令人不安的趋势。越来越多的问题已经出现在模拟中，现在设计的首次通过硅成功的数量正在下降。核查工具和方法似乎没有跟上步伐。这是怎么回事?

Lapides:作为三巨头的外部观察者，人们一直在关注——尤其是在过去的五年里——用于验证的大盒子和模拟器。它们在核查进程和核查方法中占有一席之地，这很好。但它们是这些公司的高利润产品，重点是销售它们。这种强调可能会偏离涵盖一切的更加平衡的核查流程。从验证的角度来看，我没有数据来支持这一点，但从销售的角度来看，我当然知道这是重点和精力所在。

汤普森:我想知道导致这些重新旋转的错误类型，因为从我的观点来看，验证通常是分层完成的——首先在块级别，然后可能是超级块级别，然后是系统级别。我相信我们已经很好地处理了块级验证，使用模拟和形式化。过去，一个街区的定义是10,000个大门。现在已经接近一百万扇门了，而且还在不断扩大。系统级验证可能是我们做得不太好的地方。大型仿真器是进行系统级验证的好方法。我们缺乏，或者不使用，我们在区块级别，在系统级别上拥有的指标。在块级别上，我们有功能覆盖、代码覆盖、断言覆盖、影响锥，所有这些都是衡量验证质量的好东西。但是在模拟中，我们将所有的块放在一起并将其与软件集成，我们在没有大量覆盖的情况下运行测试。这是漏洞不断出现的原因之一，或者至少是一个关键方面。 When doing the integration of blocks to form the system, we’re not applying any metrics.

Ganguly:首先，关于模拟的一个评论。我和很多客户谈过，每个人都在谈论模拟设计的问题，但没有人愿意投入真正的资金来解决这个问题。我认为这不是什么大问题。模拟漏洞是建模中的漏洞，模拟行为没有被正确地封装在数字级别上。如果我观察一个现代产品，模拟/数字接口是在物理、SerDes、锁相环边界，等等。它是有限的，相对较少的东西。模拟设计师和数字设计师之间总是存在着鸿沟，很多时候他们在建模方面做得不够好。继续讲硬件部分会更有趣。我不同意你关于在硬件上运行覆盖的必要性。那是我最不想做的事。 Run as much content as I can, as fast as I can. I want to run apps, benchmarks, games that a user will run on the phone. If I look at network switches, people will run synthetic content using test generators, but eventually they want a speed bridge to plug it into the wall, because at that point, you’re going to see traffic. You will never be able to program this with network packet generators. So the idea is to run as much realistic content as you can early on. Coverage at the block level is fine. One company had a bug that escaped into silicon, and this happened despite a very good verification technology. It happened after a sequence of events that would take weeks or months to simulate. You will see a concurrency bug, with certain traffic patterns that may not happen for weeks on an emulator. But it happens in four or five minutes when somebody plugs it directly into a PC. You really want to run as much content as possible. There is a place for emulator, there is a place for prototyping, and for virtual platforms. The overall strategy is very important.

Graykowski:当你看块级别，在大多数情况下，这是很好的处理，至少对于较小的块。所有的传统技术，编写UVM，进行功能覆盖，代码覆盖——这些看起来都是很好的扩展。我想指出两件事。在过去的生活中，当我在PCI Express工作时，我讨厌称之为块，因为它太大了，有很多痛苦。当您运行测试套件时，它们是非常长的序列，并涉及大量随机化。当事情失败时，很难弄清楚发生了什么。只是试着诊断它，这是需要改进的地方。我们需要更智能的调试工具。如何将智能引入调试功能，并能够将其抽象出来，以便更快地调试?其次，我看到了更多的系统级问题。 When you are putting big chips together, you can really beat it up at the lower levels, but when you move to that system level, it’s challenging. I’m talking more from the simulation perspective. There are so many combinations. You’re focusing on data flow, you have to make sure that things can interplay, there are issues with timing between blocks, different clock domains, different power domains, all those types of things. And that’s an area where I see folks just cannot spend enough cycles to make sure it is perfect.

Ganguly:这一点很有趣。围绕结构组装子系统，并能够进行功能和性能测试，这是防止错误逃逸的非常有用的中间步骤。从历史上看，当他们进行SoC组装时，他们会确保IP正常运行，并且能够读写。然后他们就会一头扎进事情的深处。但是这个中间步骤是定义产品的非常合理的方法，产品本质上是围绕结构的子系统。我们可以定义CPU和内存组合，然后你可以做推荐流量，你可以测量性能。您甚至可以在bug或有趣的场景、PCIe和其他一些外围设备方面进行一些压力测试。所以这绝对是一个领域，我认为我们可以让所有或许多构建模块变得更容易。另一点很有趣。如果你看调试，5%的人能够快速调试。 And then the productivity falls rapidly. How do we raise that level? Debug is actually the last frontier, making something that happened a half-million clock cycles ago and then went through a bunch of events and eventually caused something to fail. How do we debug that?

克拉我想谈谈调试部分，但我想从你最初提出的关于模拟的问题开始。我不认为我们声称完全知道任何答案。但是在模拟中，如果有什么比数字RTL模拟更消耗cpu的话，那就是SPICE——模拟模拟，而世界上可以利用的cpu只有那么多。它的规模并不大。我想把它与调试联系起来的原因是，这是一个机器学习可以在模拟模拟中提供10倍或100倍收益的领域。我们开始看到这个，调试与此相关。我们正在与客户交谈，并进行研究，表明调试是一个成熟的领域，可以获得机器学习类型的好处。你一遍又一遍地做某事，对设计进行ECO更改。有很多机会可以训练它，节省很多时间。在仿真方面，这是关于三大推动模拟器的评论，但这里是真正的问题。 Are we just responding to demand, or are we pushing it because it is a lucrative business?

Ganguly如我们正在响应需求。很明显，没有人会开出这么大的支票，除非他们完全被说服。

克拉:当从块级到系统级时，可能他们不想在系统级以完全相同的方式进行覆盖。没有人想从我的块级别获取覆盖点，并在系统级别上运行它。但我确实希望能够利用基础设施。如果有覆盖模型显示我在块级模拟或正式验证中所做的事情，我希望能够在系统级重用这些信息。从我们在市场上看到的情况来看，我认为没有人很好地解决了这个问题。在仿真领域，我们的客户告诉我们，他们的软件开发人员是硬件开发人员的10倍，甚至更多。仿真和FPGA原型设计有多种用途。一种是进行系统级验证，您希望尽可能多地重用块级别的数据。另一个领域是软件开发，能够在硬件开发的同时进行软件开发，而不必等到有了芯片。

汤普森当然，如果你能利用一些软件来验证所设计的芯片，那就更好了。

克拉:现在把所有这些都加进去，你想知道为什么每三个设计中就有两个需要重新旋转吗?

汤普森:最大的一个原因是使用模式——在你开始生产之前，把你所有的硅后材料都清理干净。最近，我们得到了越来越多的设计公司，虽然有些公司已经做了很多年，但其他公司正在接受这个想法。这个想法是，当你的硅回来，你有一个故障，你知道在硅里面发生了什么，因为你把调试基础设施放在硅里面，测试硅，实际上是工作的。这是一个非常重要的实践，随着越来越多的公司意识到他们需要这样做，我们将开始看到重新旋转的数量下降。你会得到更健康的第一块硅，在那里你可以非常非常快地完成你的第一套裸金属验证。这个过程非常重要。

Lapides:您谈到了暴露bug所需要的周期数。这是一个虚拟平台可以真正发挥作用的地方。为了说明我的观点，一位客户试图提出Linux。他们确实得到了Linux引导提示符，这很好。但是他们继续使用虚拟平台并运行更多的测试——不仅仅是Linux上的应用程序，而是运行多个应用程序。在执行了几十亿条指令后，他们发现了一个问题，Linux中的抢占式切换，任务切换有问题。但你必须得到数十亿条指令，你必须运行多个应用程序。因此，在系统级别上，有一个测试平台的质量问题开始发挥作用。

Ganguly:虚拟平台绝对有其一席之地。然后最终能够利用这个虚拟平台创建一个混合，在那里你有一个IP，实际上是RTL，以模拟器或原型形式，并连接起来。这增加了一定程度的现实主义。虚拟平台非常好。他们没有捕捉到的部分是一些较低级别的交互，比如中断序列，被软件模型抽象出来的非常低级的硬件。

Lapides:另一方面，有些团队正在取得成功。有一家公司正在建造一种先进的人工智能加速器，可以插入数据中心。他们对硅有非常严格的DV方法。他们有一个非常严格的软件虚拟平台方法论。他们拿回了硅，几天内就开始运行了。所以优秀的团队，如果有严格的方法，有充分记录的计划，并有正确的度量标准，就能成功。

汤普森OpenHW与开源社区进行了大量的合作。我在开源社区中看到了很多关于验证的天真烂熟的想法。我们不应该太聪明，因为这和30年前整个行业的幼稚立场一样。那时候我们会制作出1万个带有大量漏洞的大门设计。我们现在可以做100亿个第一次就能成功的门设计。因此，老牌游戏公司已经付出了代价，吸取了教训，回头购买了模拟器，现在取得了成功。他们知道需要付出什么，也愿意花钱。新进入的公司还没有意识到这一点。他们正在上速成班。

相关的
验证方法有多成熟?
这个行业正在不断发展，有新的参与者，有新的问题，也有新的挑战。这就是核查工作似乎举步维艰的原因吗?
EDA的下一个化身
EDA行业是否即将出现重大颠覆，并伴随着领域特定架构的新兴时代?学术界当然是这么认为的。
谁负责处理器验证?
异构设计和AI/ML处理暴露了现有方法和工具的局限性。
自定义、异构集成和暴力验证
为什么需要新的方法来设计复杂的多芯片系统。