什么时候完成验证?

即使在EDA工具的研发上花费了数十亿美元，在验证劳动力上花费了数百亿美元，也只有30%到50%的ASIC设计是第一次正确的威尔逊研究集团和西门子EDA。

即便如此，这些设计仍然存在漏洞。它们的灾难性还不足以引起重新旋转。这意味着效率更高验证是必要的。在那之前，验证团队会继续用各种刺激手段挑战设计。但并没有确切的科学来说明什么时候应该停止验证。

旋转会引起不同程度的疼痛。28nm的再自旋可能需要50万美元的新掩模成本，而较小几何尺寸的再自旋成本可能高达100万美元。还有就是失去目标市场的问题。如果一家芯片制造商正在服务一个价值10亿美元的市场，而产品生命周期仅持续24个月，却迟到了3个月，那么收入损失可能是毁灭性的。但何时停止并不总是显而易见的。

设计验证解决方案的产品经理Nicolae Tusinschi说:“要认为验证是完整的，首先必须对验证覆盖范围有深刻的理解。OneSpin解决方案。“很难满足IC完整性标准，即确保设计按预期运行，安全、可信和安全，而不知道验证是否或何处存在漏洞。如果没有精确的覆盖率分析，您就无法满怀信心地完成签名。我们需要的是快速而精确地衡量进展和覆盖率的提高。”

验证任务因不同级别的挑战而复杂化，这取决于开发人员在生态系统中的位置。“如果你是一家设计芯片、封装、电路板、系统和软件的系统公司，你实际上拥有完全的控制权，”微软的产品营销总监迈克尔·杨(Michael Young)说节奏。“但是想象一下，你是一家大型芯片公司的客户，或者你正在设计一种用于插入计算机主板的PCIe卡的芯片。理解系统场景是非常困难的。为了降低风险和重新旋转的成本，并找到客户错误，左移的概念已经开始发挥作用。过去在硬件层面完成的所有活动都转移到了硬件/软件层面。这种硬件/软件开发是在SoC级别上完成的，而且SoC是尽早完成的。这里的挑战是模拟器不能提供与过去相同的加速，因此许多人转向模拟或原型系统来做额外的工作，并将更多的工作量转移到验证上。”

这需要对需要验证的内容有一个清晰的认识。“你只能定义和验证你能指定的东西，”Young说。“你无法指明的是什么会杀死你。一旦你开始规范，如果你做得不对，或者你的设备必须生活在不受你控制的外部环境中，你的风险就会高得多。”

图1:SoC的系统中心视图。来源:节奏

什么时候能完成?
那么，当涉及到验证芯片、子系统或包时，“完成”究竟意味着什么?

如今，采用功能而且代码覆盖率是必须的——你必须拥有它，你必须在它上面投资。Vtool。“越来越多的公司都在这么做，并严格遵循这一规则，但第一次做对的芯片比例正在下降。如果你检查那些有bug或严重到需要重新旋转的bug的芯片，它们在验证中遵循了“完成”的最先进定义，即功能覆盖率和代码覆盖率100%。你会看到很多这样的人。这意味着它没有帮助。”

事实上，高技能的验证工程师即使在100%的功能覆盖和100%的代码覆盖后也能发现关键的错误，Arbel说。“他们怎么找到他们?”他们怎么知道100%的覆盖率是不够的?每个优秀的验证工程师都会有这样一种直觉，‘它说它被覆盖了，但我不放心。我觉得有些事情不对劲。真正优秀的验证工程师对此有某种第六感。他们就是知道。如果你是一个很好的验证经理，你会对其他人的验证产生这种感觉。如果你看一下报道，我并不是说它不重要。但这还不足以确定，甚至还不足以接近这一点。 In addition to code coverage and functional coverage, alternative metrics, such as the quality of the verification efforts, should be taken into account. Still, how safe can you be doing all of that? Some companies are really struggling with this. Some companies have managed to develop better processes and internal processes, but as anEDA我们甚至还没有接近于提供一个足够好的解决方案。这是一个巨大的机会，可以将记录信息并得出结论的方法正式化。”

从本质上讲，核查是一项风险管理工作。“如果你看看两者之间的差异FPGA而且ASIC以及他们处理验证的方式，从风险管理的角度来看，你开始看到为什么他们对待事情的方式不同，”IC验证解决方案的营销总监Neil Hand说西门子EDA。“在FPGA中，他们承担了更多的风险，因为他们可以事后修复，而在ASIC中则不能。因此，如果你开始将验证视为一种风险管理练习，它就不再是什么时候完成的问题，因为你永远不可能完成。那么问题就变成了，‘我什么时候达到了我的风险承受能力?我什么时候会觉得在这个设计上签字很舒服呢?’”

有数据和工具可以帮助关闭吗报道更快。“你有保险，这是今天很多人衡量风险的方式，但保险并不是全部，”汉德说。“你可能有保险漏洞。你可以不定义覆盖范围。可能会有很多差距。但如果你已经定义了一组指标，你就可以根据这些指标进行衡量。此外，还可以利用工具和技术来确定这些指标是否良好。您可以有一个覆盖方法，其中您已经定义了1000个覆盖点。你击中了所有这1000个覆盖点，但这1000个覆盖点只击中了你设计的10%。那么你的风险敞口是多少呢?”

这些都是必须解决的问题。但事情没那么简单。定义风险边界是一个移动的目标，因为它取决于设计、系统内设计的上下文以及与其他系统的交互。

“这是一种权衡，但每一个芯片都是不同的，”他说。“每种设计的可接受风险都是不同的。你要做的是提供工具，无论是通过验证管理、需求管理、覆盖可追溯性，还是通过机器学习，来了解你已经看了什么和你还没有看什么。当我们看一个特定的区域时，我们经常会失明。我们看不到我们右肩后面准备扑过来的怪物。我们可以使用机器学习技术来识别你所做的一切都是正确的，但那个怪物仍然在那里。”

在异质系统中尤其如此，随着摩尔定律的失效，异质系统越来越普遍。这迫使设计团队使用新的架构来区分不同的应用程序和市场。这为定制加速器打开了大门，并推动了RISC-V的发展势头。但这也使得设计更加复杂，更难以验证。

“我们在开源核心的设计中看到了这一点，那里有我们从未见过的新角落，”路易·德·卢纳(Louie de Luna)说Aldec。“核实也是一样。我们看到了新的UVM用例，我们发现了很多bug。”

De Luna指出，这也推动了许多相关的活动，例如虚拟建模和多核调试。实际上，工程师们正在利用他们所掌握的一切手段来处理日益增加的复杂性。

事情没有听起来那么简单
虽然这很大程度上依赖于设计和用例，但越来越多的人认为验证需要是一个连续的过程，而不仅仅是设计流中的一个单一步骤。

“对这个问题的一个非常简单的回答是，‘当你证明设计没有任何缺陷时，验证就完成了。’Valtrix系统。“这时你就可以称验证完成了。但这是NP困难问题，永远都做不出来。你有空间。测试的数量和覆盖率是无限的，所以从技术上讲，你永远无法真正完成你的验证活动。”

还有许多其他因素需要考虑。Roy Choudhury说:“你必须确保电力和性能目标得到满足，并且你设计的最终用例能够按照预期工作。”“其中一些标准可以用来判断验证是否接近完成，比如当你有了所有的代码，代码覆盖率和功能覆盖率达到了设计和验证团队可以接受的数字。通常，所有这些设计都是在您已经到位的一些先前设计之上的迭代，因此从验证的角度来看，大量的工作都用于开发测试，以实践设计增量，以及新功能与遗留功能的交互。这意味着编写测试需要付出大量的努力。您需要确保这些测试按照预期工作，没有任何错误或失败。您需要优秀的验证工程师来判断意图是否得到满足，以及设计是否符合预期。有很多活动，比如在设计的某些部分，你可以应用正式的模型，并得到设计确实没有任何缺陷的证明，这也可以用于任何可以应用的地方。”

这可以一步一步来。“在功能验证中，每当我们被要求验证一个特性时，一切都从测试计划开始，”他说。“因此，我们确定了进入设计的不同变化，然后我们创建了数百个场景，以确保特定功能按预期工作。然后，在设计可用之前，我们花一些时间来编写测试，确保它们在虚拟模型或功能准确的模拟器上正常工作。一旦测试人员准备好，设计可用，我们就开始运行，并尝试确保没有故障。通常，在程序接近尾声的时候，设计错误的比率可以作为总体验证情况的一个很好的指标。当你完成整个验证任务时，它会趋于稳定。”

所有这些都必须与功能和代码覆盖工具齐头并进。每当设计的新版本可用时，通常会有一个涉及代码和功能覆盖分析的阶段，以确保所有预期的场景都得到满足。这些是用于确保设计得到验证的指标。

这里要考虑的另一个问题是决定测量什么，以及如何测量。西蒙·大卫曼，首席执行官治之软件他以最近的RISC-V项目为例。“我们刚刚与OpenHW集团一起参与了一个32位RISC核心的项目，首先发生的事情之一是编写了一个测试计划，上面写着，‘这些是已经经过良好测试的设计部分，这些是新的部分，这些是我们担心的部分，这些是可能隐藏在我们没有意识到的部分。他们提出了测试计划，投入了资源，然后可以说，‘这是我们将使用定向测试的部分设计，而这部分我们将使用随机测试。对于这一部分，我们将使用异步步骤-比较测试，对于这一部分，实际上我们将使用形式化来测试如何进入和退出调试模式，这在传统上是相当困难的事情。你基本上要看你所面临的设计挑战，然后找出你知道什么，不知道什么，以及风险是什么。因为你不能证明游戏中没有漏洞，我要达到什么水平才能满足于“足够好”?你只能说它足够好，可以发布了。”

分享知识
Vtool的Arbel表示，另一个障碍是如何与其他团队成员分享这一成果，这也是整个设计和验证过程的一个重要方面。“通常不止一个人参与其中。我是一名验证工程师，我想我遇到了一个问题。我正把它寄给设计师。他要把它送回去。架构师介入其中，软件团队参与其中。有很多人参与其中，主要是把棍子从一个人转移到另一个人，不能真正合作，一起解决问题。验证工程师必须学习如何使用他们的综合知识以提高效率。今天，调试是一条孤独的道路——孤独的意思是很难让人帮助你，但也很难教它。”

在这一点上，罗伊·乔杜里说，彻底记录已经做过的事情是有帮助的。“如果你对整个验证活动有很好的记录，就会有很大帮助。在我之前的一家公司里，我们曾经保存整个硅后验证过程的日志，这些过程过去是在我们用来验证的服务器设计上完成的。它非常详细。例如，我们曾经有负载存储单元的区域所有者，用于CPU测试等，每个人都有一大堆遗留测试，他们被分配N个小时来测试设计，只要测试器可用。随着时间的推移，我们有了所有这些验证活动的记录。根据新特性的加入，例如，如果有很多特性发生，那么负载存储单元面积的所有者，例如，将有更多的时间进行测试。在那之后，如果你有完整的记录，如果你有完整的历史计划，一切就会变得无缝衔接。”

当然，一定的知识是必需的，他指出。“你需要了解工具，并有适当的方法来做得更好，以及可以投入的效率，如功能验证。这是一个很大的领域，我们所有人都对它感兴趣，以确保我们拥有的整个刺激是完全可移植的，这样我们就可以在设计的多个阶段无缝地使用它，无论是硅的模拟还是其他。这将实现大量的重用，当然也会带来更高的效率。”

OneSpin的Tusinschi指出，可以通过基于形式的突变分析、基于模型的错误注入和对源代码的精确映射来实现对进度和覆盖率改进的快速而精确的度量。“其结果是可靠地识别了核查空白和盲点。当然，最佳的解决方案是将所有验证指标，如模拟和正式的验证指标纳入一个视图，以便更好地理解总体验证工作和进展，”他说。

结论
Imperas的大卫曼说:“最后，当你觉得自己完成了时，你就完成了。”“你必须进行测量，你必须进行分析。当出现问题时，您需要了解流程是什么。这都是经验的问题。你需要很多经验才能搞清楚如何做到这一切。”

此外，新技术正在出现，团队希望在生成测试时使用AI来帮助。“你可以使用人工智能来查看测试的有效性，查看测试在设计中的探索位置，以及什么是更好的方法，从而帮助提高你正在进行的测试的质量。如果操作得当，这可以节省完成所有测试和回归测试所需的时间，并提高产品质量。目前，我们还处于使用人工智能帮助我们进行验证的早期阶段。”

最后，Cadence的Young强调要确定何时完成验证。“你基本上是想让覆盖率达到100%，在你的老板告诉你，如果你不胶带，团队就会处于危险之中之前，尽可能多地运行。这显然是基于经验的，但是您需要使用基于规范的覆盖模型。你需要运行尽可能多的回归测试。你要确保即使发现了一些勘误表，也可以通过软件进行处理，而不是重新进行检查。”