​rockeric.com

译者注：本文中大量的使用了verification和validation及其相应的动词、被动结构，为防止误导读者，统一使用了原词以进区分。

verification和validation是电子系统的创建以及随着时间的推移中的作用的两个重要步骤，但它们如何一起发挥作用正在发生变化。实际上，如今我们看到了重新思考这一流程的重要机会，这可能意味着它们将不再成为许多芯片的设计流程中的独立任务。

然而，正如这个行业中的许多事情一样，将其从流程的一部分中挤出可能只会让它在别的部分再出现然后成为了别人的责任。

首先，我们必须定义术语。“如果我们将verification定义为针对设计场景的ASIC功能的硅前检查，并将validation定义为系统功能与市场需求的硅后检查，那么我们就能理解为什么过去verification和validation被视为不同的任务。”OskiTechnology的验证架构师Michael Thompson说，“这方面存在技术和组织方面的原因。”

让我们从verification开始。“verification是一个有限的逻辑问题，”西门子企业的产品营销经理导师DougAmos说，“我们问的问题是，'我的硬件出现错误的可能性有多大？'现代覆盖率驱动技术可以为我们提供一个基于逻辑度量的问题答案，得到这个答案的目的是尽可能接近'不可能出错'。  我们在verification方面的痛苦是我们永远不会“不可能出错”，因此我们只能决定何时是“足够接近没机会出错”，然后开始良心和实用主义之间的权衡。

Thompson解释道说：“不可能出错”是功率限制产生的。对于很多代的ASIC器件来说，仿真一直是主要的验证工具。仿真方法还没有完成扩展激励生成（stimulus  generation）、响应预测（responsep rediction）和检查系统级环境（system-level environment）或是其他相关方面的任务。”

额外的引擎此时就变成必要的了。“不同类型的设计可能需要不同的verification策略，工具和测试环境，”Aldec硬件部总经理ZibiZalewski说，“大型SoC设计需要复杂的流程，多种工具包括虚拟原型、模拟器、仿真器和原型设计板等理想化地集成在一起并可扩展，并且可以在不同的验证阶段重复使用测试。”

这样导致的结果是validation的需求增加了。那么什么是validation？“validation没有那么客观和合乎逻辑，”阿莫斯警告说，“理想的validation环境可能涉及构建一系列逐步更好的设计版本，并将每个版本暴露给无数只猴子，直到确定它完全符合目的，没有任何东西可以被意外或故意破坏掉。当然那是理想的。但是就像verification的理想“不可能出错”从不可能达到一样，完成validation也是如此。这在一定程度上取决于成本和时间，它们两个无所不在，是任何项目的完美障碍，但也主要是因为validation成功的某些方面是由主观的标准来衡量的，而不是逻辑上的标准。”

在引擎和方法方面都取得了很多进展。“人们自己设计了IP，然后IP成为了重用的对象。然后，子系统——也就是IP块和软件的组合——成为重用的对象，组合后也是IP，“Cadence系统和验证组产品管理高级主管FrankSchirrmeister解释道，“复杂性是推动它发展的动力。在validation方面发生了类似的事情，特别是在涉及场景的定义时。IP级别曾经定义了场景。它上升到了子系统级别。场景的定义和需求的定义随着复杂性而增长。verification和validation正在合并，或者至少在接近，芯片横跨系统和电路板。但是尽管它正在这样做，你进入系统的场景对于系统来说，要复杂难定义得多。”

图1：verification和validation结合在一起。来源：半导体工程。

随着时间的推移，verification已成为validation。“典型的validation任务将成为verificatio计划的一部分，”Cadence系统与验证组的产品管理总监LarryMelling说。“它将向“左”移动，我们将能够在我们愿意发布之前定义我们需要做的事情。”

在成为verification的同义词之前，更高的复杂化被带入validation。“在过去，我们在模拟器知识中心或FPGA原型中连接所有内容，加载软件，打开它以查看它是否有效，”Schirrmeister说，“这是validation的范围。现在我们正在添加智能并定义方案知识中心并定义我们需要validate的案例。是否已对指定的场景进行validation或verification？Verification从哪儿停止？validation从哪儿开始？”

可移植激励

最近对可移植激励的关注推动了这两个方向的整合。“可移植激励是一个强大的概念，旨在让芯片设计团队一次制定verification and validation场景，然后在开发周期的任何阶段使用该单一规范，”UltraSoC首席执行官RupertBaines说，“所有的EDA公司都采用了verification/validation模型的概念，该模型可以在整个开发过程中进行端到端的扩展，从设计到simulation,emulation,再到硅后和系统validation。Synopsys将此称为“验证连续统一体（verification continuum）”，但每个人都承认需要它并正在努力完善它。”

OneSpin Solutions的技术营销顾问Tom Anderson就此更进了一步。“一个便携式激励工具可以从一个单个高级模型生成针对每个verification和validation平台调整的测试。这些测试包括在嵌入式处理器上运行的代码，并在需要时通过每个平台的可用机制访问芯片输入和输出。这样就可以在validation平台上检查已验证的功能（verifiedfunctionality），从而减少运行软件所需的时间。它还允许在验证过程中发现错误——甚至在芯片启动期间发现的错误——以在仿真中重现，便于调试。

记录下经验是可以有所作为的。“可移植激励意味着你有一个场景的定义，以可执行的形式写下并且是可重复的，”Schirrmeister说，“这使它成为verification。就像过去作为RTL参考的书面规范一样，您可以使用测试平台验证（verify），现在您正在转换过去在SoC级别进行验证（validation）的内容，并且它将成为验证（verification）。现在我将验证（validation）转移到更高级别——多芯片级别。”

这提供了一个可以在硅前执行的丰富的验证（validation）套件。“许多验证（validation）套件是经典的生活的佐证。”Melling说，“你经历并解决所有组件，并确保你可以与他们交谈，读写他们的寄存器。通过可移植激励，我们可以针对一致性和这些活动的交叉进行一致性测试和电源管理测试。现在，当我们第一次流片时，大大增加了成功的机会。”

引擎扩展

推动发展可移植激励的因素之一是现在可用于verification的引擎系列，其中一些仅在过去用于validation。“基于FPGA的原型设计和仿真相互跨越，”Schirrmeister说。“它们被用于verification和validation，但是有一个灰色区域，它们重叠。我们正处于一个他们携手并进的地方。如果您查validation的DNA并将其与verification的DNA进行比较，它们非常相似。但它们需要不同的速度和不同的调试功能。”

eSilicon营销副总裁MikeGianfagna说：“emulation和FGPA原型设计已经出现了爆炸式增长，因为软件耗时太长。”“这会影响成长，并且基本上是两个阶段的批准。其中一部分是verifying，'它是否摆动？'如果摆动，你可以在扫描链模式下运行它并以高速运行吗？在那之后，你有一个非常长的验证周期。“Verification和validation也与测试的某些方面一起提供。 Schirrmeister说：“在引入真正的芯片时，它与人们在测试领域所做的事情相结合。”“考虑从设计到测试- 在实验室的后期，它们将成为您在NationalInstruments Labview中运行的测试。当你将它与可移植激励结合在一起时，它会将validation/test与verification结合。”

不是每个人都愿意走这么远。“Verification和Validation不是关于有什么引擎可用，而是关于需要完成哪些任务，”Amos说，“emulation之类的引擎确实可以准确地运行软件，但由于执行速度不够而无法全部运行。即使是FPGA样板，最快的硅前引擎，也可能缺乏全堆栈操作所需的速度。通常使用混合技术;将一些系统功能放到一个事务级近似中，例如一个ArmFast Model。通过这种方式，仿真器可以运行足够的软件来进行一些严格的硬件- 软件协同validation。极端情况下，整个系统可以在事务级别建模，创建一个虚拟原型，这不仅仅是一个硅前的，而且也是一个RTL前的; 事实上，这是一个验证用户界面和美学的良好环境。”

引入软件

当软件的主题被引入时，它开始变得更加复杂。“考虑一个最低级别的软件堆栈，比如启动代码或最依赖于硬件功能的板级支持包——并且堆栈的上层，例如应用程序和用户空间，完全脱离它。”阿莫斯说，“通常，verification只需要足够的软件堆栈来运行硬件，而validation需要所有这些——整个芯片，整个堆栈。”

虽然可移植激励委员会一直致力于解决这个问题，但该委员会尚未充分参与。“需求文档中指定的一项功能是需要硬件/软件抽象接口（HSI），”BrekerVerification Systems首席执行官AdnanHamid说。“这不是最新的草案，但需要在此问题得到彻底解决之前完成。”“需求文档中指定的一项功能是需要硬件/软件抽象接口（HSI），”BrekerVerification Systems首席执行官AdnanHamid说。“这不是最终的方案，但在此问题得到彻底解决之前我们需要它。”

“HSI不在那里，但这并不是1.0spec的限制因素，”Melling说。“有一个设施可以插入您拥有的驱动程序和序列。HSI是关于我们需要什么样的自动化才能使工作更容易创建这些drivers，并且一但描述它时具有可移植性，并且具有UVM序列或C代码驱动程序或您想要进行的测试所需的任何内容。我们不会因为在这些级别进行测试而停滞不前，我们只需要插入一个序列或一个驱动来启用它。在1.0中，我们专注于硬件validation，而不是硬件/软件系统的validation。”

不幸的是，真正的人生是迷乱的。“最终，所有系统都必须处理模拟世界，最全面的verified的设计永远也可能被其他不可预测的、可能是恶意的系统（和人）破坏，”Amos说。“仅靠Verification是不够的。一个人的验证场景越完整和准确，设计在第一轮被击倒的可能性就越小。”

此外，verification可能过于干净和可预测。“通常情况下，真正的问题——无论是显示停止错误还是更微小的问题，只会降低性能或仅将功耗提高几个百分点——只能在真正的芯片中出现，”UltraSoC的Baines表示,“它们只在实际代码在现实世界中全速运行时才表现出来。”

Amos指出，今天validation的最大驱动因素是安全性和安全性。“功能安全要求是系统规范的一部分，包括最终产品必须要面对的随机错误，例如一个α粒子翻转存储器位，”Anderson说,“正式的故障注入工具可以分析设计，以确定哪些故障不会影响操作从而是安全的，哪些可以传播并造成麻烦。后者必须被检测并进行纠正或发出警报，以便系统采取适当的补救措施。因此，在verification阶段，validation的一个关键方面可以与仿真并行的正式检查。”

促进未来发展

“通常说，只要不是ASIC，将verification和validation结合起来将减少系统的整体上市所需时间，”Oski的Thompson说，“如果我们假设这是真的，那么可移植激励如果可以加速将激励从系统级别移植到ASIC级别，甚至可能的话移植到块级别，似乎可以增加价值。需要注意的是，这与大多数人假设的方向是相反的。为了实现这一目标，业界需要找到一种方法，在ASIC verification团队获得RTL代码之前就将所有的系统组件准备好。”

一种新兴方法是将嵌入式监控结合到硬件中，这将提高硅上运算的可见度。相关的分析系统会提供有价值的信息从而使工程师能够微调性能并理解复杂的硬件/软件交互。“从测试试验甚至实际使用中收集和利用数据的能力提供了强大的反馈能力，”Baines说。“这将整个开发流程从上到下以及从端到端联系在一起，不仅使系统和软件工程任务变得更加容易，还为芯片团队提供了可操作的信息分析。这使他们能够修复芯片或IP本身的错误，提高性能，降低后代芯片的成本。”

有些人选择将目光投向更远的未来。“我们开始问的问题是，是否可以通过深度学习缩短这些问题？”eSilicon的Gianfagna问道，“对于这类问题，这将是一个很好的工具。深度学习解决了一般性问题，也就是越来越多的系统设计人员需要做出芯片来实现他们的梦想然后他们才可以将算法映射到硅片。”

很明显，verification团队正在使用validation的某些部分。这是否会导致validation团队被淘汰？当然是不可能的。更有可能的是，它会使validation团队免于查看保密性、安全性以及越来越大的集成方面的问题。

原文来自Semiengineering Merging Verification With Validation

https://semiengineering.com/merging-verification-with-validation/