摘要：工具的问题在于，许多工具仍然在单处理器内核上运行。例如，功能仿真无法利用无限数量的核心，除非在这些核心上分布进行独立的仿真任务。虽然这有助于提高总体仿真吞吐量，但在时间紧迫的调试周期中，结果产出时间才是关键因素，此时这种方式的帮助就比较有限了。

（本文编译自Semiconductor Engineering）

随着验证团队所承担任务的复杂性和广度不断增加，方法论的改进和自动化正变得至关重要，这有助于弥补工具在速度提升方面的滞后。

工具的问题在于，许多工具仍然在单处理器内核上运行。例如，功能仿真无法利用无限数量的核心，除非在这些核心上分布进行独立的仿真任务。虽然这有助于提高总体仿真吞吐量，但在时间紧迫的调试周期中，结果产出时间才是关键因素，此时这种方式的帮助就比较有限了。

新思科技战略项目和系统解决方案执行总监Frank Schirrmeister表示，有三个领域正在取得进展，但速度和效果各不相同。他表示：“工具引擎的基础速度正在提高，这是一个方面。第二个我们称之为‘更智能的验证’。在这个层面，涉及到验证方法学以及正确的验证范围。在IP层面解决了正确的问题，可能并不一定能套用到SoC层面或系统层面。第三个是自动化和人工智能。这就像一张三条腿的凳子——让验证速度更快，通过方法学实现更智能的验证，然后在此基础上实现自动化。”

更智能地开展工作和应用自动化是向前迈出的一大步。其中包括清楚何时完成验证工作，这是验证领域最棘手的问题之一。

西门子EDA数字验证技术部门解决方案管理总监Bryan Ramirez表示：“了解已经测试了的内容至关重要。将其与需求联系起来将会变得越来越重要。如何实现从需求或设计规范到测试计划以及覆盖率统计的自动化，是业界投入大量资金的一个领域。但这并不能解决如何达成全面覆盖的问题。这个问题的另一个方面是，能够将验证范围内不同引擎的覆盖率整合在一起。有些问题可以用形式验证方法解决，就将其标记为已解决，确保在仿真中不会再尝试去解决它。或者，可以在哪里方面利用仿真或FPGA原型设计来加速部分验证工作，从而加快运行周期。您必须能够合并所有不同引擎的覆盖率结果，这样才能对整个验证解决方案有一个全面的了解”

虽然完成验证是最终目标，但同样重要的是确定哪些测试必须立即运行。“当您对RTL进行更改时，是否需要运行整个回归测试套件？您有成千上万个测试用例，但您不知道哪些测试用例能为您带来最大的回报，”新思科技产品营销总监Bradley Geden表示，“自动化的目标之一是找出哪些是高价值的测试用例，并先运行它们。我们能否使用人工智能来专注于运行仅针对这些更改的回归测试？这是一个非常动态的环境，因为设计在变化，测试平台也在变化。测试方案并非一成不变，因此你必须不断地重新评估并找出哪个是价值最高的测试。现在他们可以更快地达到目标。运行回归测试的目标是发现错误。现在你可以更快地发现错误，并更快地找到那些错误。这样就可以释放硬件资源。”

了解哪些测试无需运行也很重要。“曾经有人对我说，最快的仿真周期就是根本不需要运行的仿真周期，”西门子的Ramirez表示，“那么，我们如何帮助他们在前期更好地确定何时无需运行仿真或模拟加速周期呢？这是我们可以改进的一个领域。”

受约束的随机测试模式生成并不是最有效的方式。Cadence产品管理集团总监Matt Graham表示：“在这方面，我们看到了人工智能带来的最大收益。AI可以帮助优化浪费的周期和冗余测试。哪些测试是有用的，我们能否针对设计中我们真正关心的那些区域进行测试，而不是对设计的其他区域反复测试上千次呢？从本质上讲，这种方式效率极低。但我们也可以通过提高其效率来解决这个难题。”

运行最佳测试用例是第一步。“问题在于，第二天你回来时发现有需要调试的故障，”Ramirez表示，“你如何解决它们？这就是我们真正开始看到人工智能和机器学习如何帮助解决问题的地方。你如何开始以更数据驱动的方式解决这些问题？验证过程会产生大量信息，你如何帮助客户更好地理解这些信息？我们看到客户在过去一两年里非常重视这一点。这让他们在解决验证问题时更加明智。”

目前，调试在验证过程中花费的时间比其他任何环节都要多。“我们在人工智能方面投入了大量资源，用于智能分类，问题分级，并尝试自动化历程，尽可能接近问题的根本原因，”新思科技的Geden表示，“当验证工程师早上来上班时，基于历史数据，能够在开始回归测试之前预测最可能的失败原因及其位置，这将使工作变得轻松许多。”

抽象和层次

验证工程师长期以来一直致力于确保在最合适的开发阶段发现正确类型的错误。“如果你在集成阶段发现IP错误，那么你可以回到IP方法论中，弄清楚为什么没有更早发现它，”新思科技的Schirrmeister表示，“如果你从范围的角度来看，包括IP、子系统、芯片、系统中的芯片（见图1），再从引擎的角度来看——事务级、仿真、仿真加速、原型设计、芯片——我们的客户告诉我们，如果他们在仿真中发现IP错误，IP部门将会进行严肃的讨论。为什么没有提前发现这个问题？从硬件速度的角度来看，这些设计非常庞大。从范围的角度来看，你从IP级别开始，然后到子系统级别，依此类推。”

图1：针对每个开发阶段的相应错误。

（图源：新思科技）

最佳的解决方案是从多个不同角度来处理问题。“更高层次的抽象是其中之一，然后是有针对性，”新思科技高级工程总监Bernie Delay表示，“在SoC级别，您尝试创建的场景不是低级别的IP场景。而是专注于缓存一致性等领域。您需要有专门针对这些问题的语言和方法。您还希望扩大规模并进行更多的系统级激励生成。将激励和覆盖率集中在这些类型的场景上。这是SoC级别和多芯片级别问题的关键所在。通过更智能地生成测试，既关注系统内部的内容，又使用正确的抽象级别来实现，这是整个问题的另一个关键所在。”

在某些情况下，重复可用于简化问题。Ansys产品营销总监Marc Swinnen表示：“重复本质上是一种层次化方法，您可以捕捉重复元素之一的行为，然后对其进行建模并在整个阵列中进行复制。有两个问题使这种方法变得复杂。一是阵列边缘的元素与中心的元素有不同的邻居，因此需要对边缘进行不同的处理。此外，有些元素的顶部可能会有电线，这会产生一定的影响。但很多设计师正是出于这个原因而避免在这些元素上布线，以免破坏层次对称性。”

模型替换具有显著的优势。“黑盒化正变得越来越流行，”Cadence的Graham说道，“黑盒化指你取出寄存器传输级（RTL）设计的一部分，用更高层次的抽象模型来替代它们。由于时序等价性检查技术的进步，这种做法得以实现，该技术可以对C语言算法和已开发的RTL设计进行比较。这就使得我们在使用C语言进行工作，同时也在处理RTL设计时，二者之间有了重叠的可能，而且在开始构建之前，你不必完全验证C语言算法。我们现在可以将这些工作并行进行，因为我们可以保证该流程某些部分具有等效性，从而提前推进各项工作。我们的客户在这方面做得越来越得心应手了。”

随着越来越多的人采用自上而下的开发方法，拥有多个抽象将变得很普遍。“如果有人最初创建了一个C模型，在他们进入实现阶段之前，你可以开始用这些模型替换一些较低级别的模块，特别是在有重复的地方，”Ramirez表示，“这就是你开始看到一些重大性能改进的地方。有趣的是，我们如何才能更好地自动化模型的替换。什么时候使用抽象模型是安全的，什么时候你真正需要RTL？我可以根据测试台或模拟器中发生的活动动态地进行这种替换？”

在考虑诸如功耗等问题时，选择合适的模型和设计精简将变得更加重要。“如果你正在进行特定的用例分析，比如功耗分析，你不会详细地考虑处理器子系统，然后将其映射到整个芯片上并尝试在那里进行分析，”Schirrmeister表示，“你只需要选择与这个问题相关的芯片子集。在验证设置中，你将针对特定的验证任务来进行。对于特定的验证任务，我可能只选择一个单独处理器的功耗模型，而对于PCI Express接口、内存和缓存选择更高层次的抽象模型，这样我就能了解软件工作负载情况。我并不需要整个芯片的模型。”

方法论仍然存在一些问题，例如如何将不同抽象模型的覆盖范围结合起来。“我们看到越来越多的C语言和C++语言来驱动RTL设计，但人们对这种方法的信任程度能达到什么水平，目前还不得而知，”Ramirez表示，“我们还看到客户希望为他们的设计创建抽象模型，并对这些模型进行验证。他们希望对这些模型进行覆盖范围分析，以更好地巩固架构，同时也定义他们的测试环境。”

进行不必要的验证是一种浪费。SmartDV应用工程副总裁Sergio Marchese表示：“约束验证对于确保最佳投资回报率和确保IP在目标项目中正常工作至关重要。例如，如果已知目标芯片将在某个频率或频率范围内运行，则验证应重点关注这些频率场景。当该IP将用于不同的项目时，很显然，必须根据新场景再次执行验证。或者，如果已知接口IP的总线拓扑结构使用的是单个管理器，则验证多管理器场景的优先级较低。IP提供商和IP集成商之间的有效沟通对于确保以最佳方式执行验证非常重要。”

结语

验证是一个过程，而不仅仅是工具的集合。找到最佳方法来充分利用这些工具，在很大程度上取决于正在进行的设计。即使不同公司的情况可能有很大的重叠部分，但对于每家公司来说，最佳的方法学都会有所不同。

新思科技的Delay表示：“你试图在最短的时间内验证一个设计，同时仍要保持最高的质量水平。如果你像寻找一个万能的解决方案，我认为你是找不到的。你会发现，有AI/ML技术、形式验证技术、便携式激励技术，还有基础性能方面的考量。你需要综合运用这些技术，才能达到足够自信将芯片送去流片的程度。”

来源：王树一