核查落后了吗?

每年摩尔定律实际上是指验证任务变得越来越大，越来越复杂。在一个极端情况下，验证的复杂性是按设计复杂性的平方增加的，但这假设设计中的每个状态都是可用的和唯一的。另一方面，验证并没有像设计之间和设计代之间的设计重用那样奢侈。此外，验证团队现在必须扩展到功能验证之外的任务，包括低功耗验证、性能、安全性和安全．

无论你如何看待这个问题，验证的复杂性大约每年翻一番。虽然验证团队正在扩大规模以解决这个问题(参见图1)，但他们还必须依赖于提高生产率，以保持对芯片将被带出的信心水平。根据哈里·福斯特，首席验证科学家Mentor是西门子旗下的企业，设计工程师也花了大量的时间在验证上。2016年，设计工程师平均花费53%的时间参与设计活动，47%的时间用于验证。”

图1:每个ASIC/IC项目峰值工程师的平均数量。资料来源:威尔逊研究集团/西门子旗下的Mentor。

有几种策略可用于提高验证效率。每一个都涉及验证工程师花费时间的一个或多个领域。(见图2)一种策略是在流程中更早地发现错误，从而减少花费在流程中的时间调试．另一个是简化测试的创建。第三个策略是改进引擎或改进引擎解决问题的方式。大多数工程团队使用所有这些策略的各个方面。福斯特还指出，自他们进行调查以来，花在每项任务上的时间百分比并没有显著变化。

图2:ASIC/IC验证工程师花费时间的地方。资料来源:威尔逊研究集团/西门子旗下的Mentor。

人们非常期待今年的核查工作将会因该文件的发布而有所提高便携式刺激Standard from getentity id= " 22028″e_name= " Accellera "]。虽然这并没有发生，但这一领域正受到越来越多的关注，甚至在标准发布之前，用户就开始采用解决方案。

将离开
最好的策略可能是首先确保设计中没有bug。“左倾的方法提供了更快的上市时间，”Kiran Vittal说，产品营销总监的验证Synopsys对此．“在传统的设计和验证流程中，您编写测试向量并执行模拟，模拟或者原型，但你可以在设计周期的早期做一些事情，并尽早发现错误。静态和正式的允许您不必编写测试向量就可以捕获错误。”

的总裁兼首席执行官OneSpin解决方案完全同意。“正式已经为左倾范式的转变做出了重大贡献。在这里，验证意图的范围从实现问题(隐含意图)到完整的块级功能覆盖(规范意图)。便携式刺激计划也将解决报道从系统的角度来看，越来越难以以机器可读和人类可理解的方式捕获设计和验证意图。如何弥补区块层面的正式刺激与系统层面的可移植刺激之间的意图差距，仍有待观察。”

在静态验证方面也取得了进展。公司产品管理总监皮特•哈迪表示:“除了结构检查外，我们还对棉绒工具类型增加了功能检查。节奏．“通过lint，我检查了代码的结构、语法等，但现在我们将其扩展为有限状态机的活锁和死锁检查，自动化添加公平性约束等。这让设计师更容易获得它。”

左移最大的生产力收益之一来自于减少的迭代循环。Synopsys负责验证的产品营销经理Vaishnav Gorur表示:“如果你在下游发现了一些东西，你可能必须回到流程的上游，并重复一系列步骤。”“然后你会发现另一个问题。因此，当验证更接近设计时，迭代的数量和复杂性就会减少。”

选择合适的引擎
现在人们普遍认为，在某些特定的任务中，正式的着装更能胜任工作。”时钟域交叉(CDC)不会被设计评审、功能验证或静态定时验证发现，”Vittal说。“这个问题需要一个单独的解决方案。在过去几年里，由于设计整合了许多IP，它们也都具有异步重置功能。因此引入了一个新问题-重置域交叉，需要工具来解决这类问题。”

在决定用正式技术而不是动态验证更好地验证哪些区块方面仍然存在问题。哈迪说:“有大量的客户证据表明，他们希望选择完全可以正式签署的服装。”“其中一个重要因素是状态空间。如果某个东西的状态空间过深，那么它们很有可能走向模拟而不是形式化。但是由于可伸缩性的改进，形式可以做比以前更多的事情。通常情况下，formal将应用于面向控制的块，可能还应用于一些数据传输，但不应用于转换。现在我们可以用算术数据路径来处理更简单的数据转换。你可以将正式应用到的领域已经扩大了很多。”
选择正确的抽象概念
抽象变得越来越重要。“你需要一种依赖于层次结构的方法论，”维塔尔说。"你验证知识产权然后引入一个抽象的IP模型来做SoC验证。你不希望一遍又一遍地解决同一个问题。为了解决与验证SoC相关的容量问题和长时间运行问题，您可以创建一个抽象模型，现在您可以处理更大的设计。在SoC级别，你只需要寻找IP之间的接口问题。”

当软件成为系统不可分割的一部分时，抽象的使用变得更加重要。Cadence产品管理高级集团总监弗兰克•施迈斯特(Frank Schirrmeister)表示:“人们希望更快地获得信息，他们愿意放弃一些准确性。”“我们将功能扩展到前端，在那里你只需要查看切换信息，并从中获得热点的位置。人们希望它更快、更早可用，他们愿意在准确性上妥协。它是为软件开发人员准备的，这样他们就可以看到他们的软件在相对变化的环境中是如何执行的。其他人不愿意冒险使用抽象，而是想要更准确。整个多域执行也在这里。他们希望系统中的互连是准确的。否则，您可能会错过缓存一致性的某些仲裁效果或方面。但随后你可以通过模拟来获得足够的数据。”

提高发动机
供应商一直致力于对核心引擎和周边软件的改进。Schirrmeister补充道:“我们在验证重用方面已经取得了很大进展。”“过去，核实工作是零散的。帮助人们的第一个轴是重用验证，这样在不同引擎之间迁移时就不必重新构建验证环境。我们的目标是能够尽可能快地从一个引擎转移到另一个引擎，并能够根据需要获得更多的调试可视性。”

调试是时间的最大消耗者。Synopsys的Gorur说:“调试是一个横向的过程，它跨越了所有的验证技术。“拥有一个通用的调试平台可以缩短学习曲线。这提高了工程师的工作效率，缩短了周转时间。”

随着设计变得越来越大，违规噪声也可能成为一个问题。维塔尔说:“你最终可能会遇到很多问题或违规行为。”“这意味着你需要足够智能的工具，不仅可以列出问题，还可以找出问题的根本原因，这样如果你解决了这个问题，那么许多其他违规行为也会消失。”

的使用增加了测试平台的复杂性UVM也会产生另一个问题。“调试测试台架是一项艰巨的任务，”Gorur说。“在移交之前，验证团队必须查看所有故障，并确定每个故障是测试问题还是设计问题。”

测试台的调试与设计调试有很大的不同。“我们已经为交互式测试台调试启用了一种新的使用模型，它看起来更像一种软件调试方法，”Gorur补充道。“现在你可以逐级检查代码，以确定哪里出了问题，所有变量的当前状态。这与传统的调试方法不同，在传统的调试方法中，您运行大型模拟并将所有信号转储到数据库中，然后在模拟后进行分析。我们还允许工程师向前和向后推进，这节省了大量迭代时间。”

工具改进可以通过几种方式进行。“有三件事会影响正式的可伸缩性，”Hardee解释说，“算法改进、并行性和应用程序机器学习就学习哪种算法或引擎最适合解决哪种问题而言。这是引擎编排。引擎中算法的组合，可以使用的抽象的组合-引擎选择-将机器学习应用于那个问题，这样我们就知道哪些引擎在设计上取得了进展。然后，对于回归，我们可以取得比第一次更快的进展。”

验证重用的其他方面正在系统级别上变得可能。“一个SoC可以以n种不同的方式配置，我需要有效地验证所有配置，”他说。“如果你将大量VIP与IP结合使用，你需要将它们集成在一起，形成一个系统级的测试平台。我们已经基于设计和vip实现了试验台构建的自动化，这为第一次测试提供了一种快速的方式。第一次测试的时间通常是几周到几个月。它可以缩短到几个小时，甚至更少。”

新需求
验证团队现在的任务不仅仅是功能正确性。性能需要不同的方法。“你需要确保满足延迟和带宽目标，”Gorur说。“我们已经自动生成性能刺激来驱动这些测试，以及对它们的分析和调试。所以如果你想验证从主机到从主机的延时，系统会提取信息，并将其绘制成图。然后，如果发现问题，就可以进行调试，并找出根本原因。”

安全是另一个日益受到关注的领域。高可靠性的应用导致了正式工具的新应用故障注入布林克曼说。这些应用范围从安全机制的功能验证到SoC级别的正式诊断覆盖分析。在安全环境中，严格的功能验证，包括彻底的验证计划和跟踪，已经成为强制性的，正式的与客观的定量覆盖措施相结合，充分发挥其力量。”

正式可以在几个方面有所帮助。“你有一个统计错误列表，”哈迪解释道。“你不能把所有可能的故障都注入到每个节点，所以必须减少故障。您将得到统计生成的故障列表，通过可测试性分析可以进一步减少故障列表。这节省了故障模拟时间，并意味着您不会在可证明不可测试的故障上浪费时间。更重要的是，形式化可以做故障后的模拟分析。这是一个四象限图，其中一个轴上是，‘我的检查人员发现故障了吗?’，另一个轴是，‘故障是否传播到功能输出?，从而变得有潜在的危险。最糟糕的一类故障是会造成损害而检查人员却没有发现的故障。”

Hardee解释说，当与模拟相关联时，这是有危险的。因为测试平台不是详尽的，您可能已经很幸运了，有些东西没有传播到输出。我是不是很幸运，被收银员发现了?对于一些错误，你想要做更深入的分析，你可能想要用形式证明，如果有可能我没有在测试台上找到一些东西。是否存在将此错误传播到函数输出的路径?类似地，我希望能够证明，‘检查者总是能发现这个错误吗?’或者在某种情况下检查人员漏掉了它。”

覆盖关闭
那你什么时候核实完?这是所有开发团队的噩梦，它给覆盖率带来了很大的压力。Vittal表示:“通过模拟，你可以很快达到80%的覆盖率。“然后你要花很多时间把它弄得更高。在最后的20%中，有5%或10%的设计是无法实现的。预先使用的正式技术可以清除那些不可触及的空间，设计团队现在不必针对它们。”

但是正式的覆盖和模拟的覆盖是不一样的。“当使用正式形式时，他们想要完全证明，与模拟相比，这是一个非常高的门槛，”Hardee说。“模拟信心并不能完全证明。我想要确保我的测试平台不会产生进一步的失败，并且我想要测量覆盖率以提供一些信心，即测试平台已经检查了所有地方。这是验证终结的一般定义。”

该行业正在花费大量精力寻找正式努力可以影响覆盖关闭的方法。Hardee说:“考虑一下寻找虫子。”“我不是在寻找证据。我要证明这一点。我在寻找反例。我正在寻找模拟无法找到的bug。现在回到签名的定义，我们不希望在定义的覆盖级别上有更多的失败。事实上，我找不到更多的反例——这就够了吗?不，我要知道我去过哪里，找过哪里。今年的一项创新是从漏洞搜索中获得报道。”

结论
核查团队必须不断创新，寻找新的、更有效的方法，以更快地关闭覆盖。没有单一的方法可以做到这一点，必须考虑方法和工具使用的所有方面。

抽象越来越有吸引力，尤其是涉及到软件的时候。当Portable Stimulus发布时，它应该提供一个行业范围的框架，围绕这个框架可以重用大量的测试，并且验证工作的合并将得到加强。它还可能在验证意图定义和测试综合方面为行业提供最大的生产力提升。然而，行业不能把所有的鸡蛋放在一个篮子里，努力继续花费在整个工具、模型和流程上。那些坚持他们所知道的东西的人很可能会被落下，增加了漏洞逃跑的危险。