让引擎物尽其用

特别在当今商业上有着各种各样可用的验证方法的情况下，于工程团队而言，准确地理解每台引擎可以、应该在哪里使用是非常重要的，这种定位更像是一门艺术而不是一门学问。

Cunningham认为这可能是艺术和科学的结合，而且一定是个生态系统问题。“这是否取决于你使用的芯片类型呢？我认为有一些方向可以帮助我们理清这件事，比如，你是在进行IP的块级验证？还是子系统级别的验证？你有没有研究过SOC层的验证？你有没有尝试过模拟一个真实的世界，在那里可能拥有软件生态组织或者软件堆栈？或者你正在做一个很糟心的验证？很明显如果设计开始变得更加稳定，并且开始尝试去调试使用该设计的软件的时候，就应该有不同的需求设置，使其更加适合我们所谓的传统原型，以及基于硬件加速的验证市场。如果你仍在尝试去解决设计本身的冷却功能问题，那么就会产生一组不同的要求，使用硬件仿真处理器或者仅仅基于Intel Xeon阵列的一个常规逻辑仿真器可以更好地满足这些要求。”

“这就是一个存在差异但需要整体编排的案例：如何将多引擎覆盖的概念结合在一起？关于这个问题，我们还有很多工作要做，因为在这个领域没有很强大的工具组，这也说明了该行业的创业形势。在这个生态系统中，并没有那么多的空间也没有任何合适的主要解决方案，就整体多引擎覆盖管理而言，这个领域仍然有很长的路要走。”

Lacey说，此外，大多数工程团队正在使用不同类型的引擎，实际上，对他们来说更聪明的验证是开始大胆地使用其他引擎。“即使在我们的团队里，通常也很难说服管理层去做我们从来没有做过的事情，所以在某些情况下这会是明智的选择，这样你就会有一个比较概况性的概念，比如在哪里使用不同的引擎以及如何从这里迅速地拿到结果值。从这个角度来看，这无疑是门科学。你可以找到适合引擎使用的区域，并在很短的时间内得到结果。一旦你将其加入到你所用的流程中并且已经开始使用，就可以将验证提升到一个新的层次，看看如何真正开始从不同引擎中获得下一层次的值，又如何开始研究怎样去消除这些引擎覆盖空间的冗余？一个简单的方法就是只使用形式验证运行你所有的仿真，这样肯定可以消除更多的错误。但是有个疑问‘我获得了更多的价值和生产力吗？这仅仅增加了我的工作量，对于缩减我的日程并没有帮助’这就是下一步需要解决的。如何在一些区域使用形式验证，一些区域使用仿真验证然后还能够把来自不同领域的数据汇集在一起，并展示这一点，‘是的，我在这里完成了一个完整的验证工作。’”

Hogan指出，这在某种程度上，激发了便携式激励的讨论，“事实上，拥有如此智能的测试平台是件了不起的事，这是一种跨域的方法。想一想，如果你拥有所有的这些引擎，那么有一个能够兼容这些引擎的激励或者TB不是更好吗？而且对于你需要做的验证，这些断言是否有效，是不是可以让你可以避免没完没了的仿真。”

他继续说，如果有可能，验证工程师真的要永远仿真下去。自动驾驶汽车就是一个实例。“如果出了任何问题，就一定是硬件或者软件的问题，而且具有伤害到个人的潜在可能性。所以一定要保证我们做了足够的仿真，我们又怎么知道我们做到了这一点呢？”

接下来，当讨论起混合形式验证，Lacey观察到设计团队对此持有不同的态度。“一些逻辑工程师非常墨守成规，不愿意尝试新事物而有些人肯定对新机会持更加开放的态度，显然，想要得到他们的支持，就要找出一些用例吸引他们，比如使用精简的命令就能得到结果值的用例。”

Cunningham提出了一个不可达性分析的实例。“实际上，你可以使用形式化工具来覆盖空间，因为设计空间的某些特定部分是无法触及的，试图覆盖它们并没有任何意义。另外一个即将可以应用的形式验证特性是关于复位的。围绕着复位有许多不同的行为，针对这些行为开展了大量验证工作，但是能够进行形式化SOC级别的复位证明就可以消除很多问题。”

他说“在更基础的层次上，我们使用一种静态的方法，仅仅通过一个基本的结构分析，来检查行为。这种静态方式广泛应用于低功耗设计，我们不需要通过仿真或者形式验证，利用这种方式便可以在跨时钟域、电平转换、隔离等方面可以发现许多问题。”

大数据的管理

各种各样的验证方法生成了大量数据，到了这一步，我们成功的关键就是掌握如何汇聚、管理和利用这些信息。

Lacey断言另一个要关心的问题是应该收集哪些数据。“我们已经有了工具提供的简单数据，使用仿真器，你最有可能从中得到覆盖率，但是其他的数据就没有用了吗？你可以通过你是否得到了你希望访问的所有数据，来确定是否从这个工具中获得了最大的价值。我们花费了大量的时间来定位我们想要定期收集的不同类型的数据，以便我们可以访问这些数据，并且能够返回查询分析，解决实际问题。”

这也是AI和机器学习将大展身手的地方。“当我们讨论AI和机器学习时，大部分内容是关于我们如何获得大量数据及如何利用这些数据？这个问题的关键在于弄清楚获得训练数据的方法，识别使用定向搜索排序的训练数据。识别要保留的数据需要花费大量的时间和精力，并且这种训练数据最终会定义你要搜索的垂直域。所以，与其说AI是一个产品，不如说是一个功能，我们需要学习如何去部署它。明年再来这里时，我们将把AI当作一个我们需要部署的功能来讨论，紧接着就会出现一些小公司，这些公司拥有领域（domain）专业知识或训练（training）专业知识。”

涉及到半导体验证时，云空间将在数据的存储和处理方面发挥作用。

Hogan说“我们曾经讨论过云上工作的成本，事实证明，将数据发送到云端不需要花费任何成本，但是如果要将数据从云端拿下来，就要花费极大的代价，所以，我们不会通过与云交互的方式来处理一个验证问题，相反更希望能够在云中完成所有工作，最终只返回一个答案。如果要采用这种经济模式，我们就需要研究在何处使用这种模式。”

Lacey总结说，在云中工作或者与云空间交互工作完成验证的工作模式都将归结为消耗成本来提高生产力的处理方式。“云空间有一个主要营销策略，即如果要运行5000个测试进行回归仿真，我需要一整天或者整晚的时间才能完成这样的工作，现在我可以把它扔进云端，让这些测试并行运行，在十分钟内完成，或者在最长的测试运行时间内完成。我更感兴趣的是这种方式怎样帮助我的工程团队提高工程生产率，更迅速地拿到最终结果值——可是这就是云能够带来给我的吗？难道仅仅是为了让回归测试跑得更快一些从而早点得到测试结果？恐怕我还没有准确的答案，不过这也正是云服务目前对验证的意义所在。因为对于我们大公司来说，我们拥有完全私人的数据中心解决方案，不会出现计算机容量不足的情况。对于小公司以及没有中心化数据解决方案的公司来说，云肯定会成为可行且有用的一个东西。但对我们来说，我们需要权衡是投资私有云还是进入公共云。”

原文来自Semiengineering "Faster Verification With AI, ML"

https://semiengineering.com/driving-smarter-faster-verification-with-ai-ml/