不可避免的错误

bug逃脱是不可避免的吗?这是最基本的问题Oski技术最近提交给了一组行业专家。参与者主要是模拟专家，在许多情况下，他们帮助指导一些最大的系统公司的验证方向。为了促进自由讨论，所有的评论都是匿名的，从中提炼出参与者的主要想法。参加者名单可在文章底部找到。

在去年的讨论中，提出了一个形式化的能力成熟模型。今年，奥斯基在此基础上提出了一份正式的签约剧本。他们提出的第一个问题是，“功能性错误逃脱是不可避免的吗?”他们收到的回复多少让他们大吃一惊。虽然人们普遍认为不可能从设计中删除所有错误，但错误的必然性必须与设计的复杂性和设计的熟悉程度联系在一起。一般来说，错误可能是不可避免的，但对于任何特定的错误并不一定如此。

一旦发现了bug，可能是在验证工艺或硅，是否有可能回顾并得出任何关于错误是如何逃脱到这一点的结论?与会者很快指出，就可用于核查的时间和资源而言，所有核查都是有限的。这本身就意味着bug是不可避免的。当时间线或预算确定时，你接受了。此外，排除一些错误可能超出了我们的能力正式的,或模拟．在某种程度上，你必须接受错误会逃到硅中，并希望这些问题将通过软件变通方法来处理。因此，问题的范围缩小到需要在项目期间找到的高影响错误。

图1:bug分类。来源:Oski Technology

另一个问题是:“当发现其中一个错误时，有多少块会受到影响?”普遍的共识是，绝大多数案件可以归结为一个单一的区块RTL这需要修改。这并不意味着有多少块涉及到错误的表现，但通常只修改一个块来解决问题。可以选择要更改哪个块。

原因是这些错误往往是在后期或硅中发现的。跟踪问题的根本原因可能涉及多个块，但是由于您在项目时间轴上所处的位置，您希望将对系统的破坏最小化。人们普遍认为，这种类型的修复通常不是真正的修复，而是一种硬件变通方法。这意味着，如果可能的话，要使修复成为本地化的，即使这意味着放弃少量的性能。在某些情况下，可能会根据备用电池的可用性做出决定，或者如果在过程中非常晚，则会限制金属更改。

我们能否预测这种类型的bug会存在于哪里?在很多情况下，我们可以。它可能是最复杂的控制块，用于发送异步事件，并且两端都有运行在不同时钟上的接口。虽然大多数团队都知道这个块可能会带来麻烦，并且他们总是希望他们最有经验的团队成员处理它，但他们从来没有足够的时间来探索所有的角落案例。

这就是用例变得重要的地方。虽然可能会有一个bug隐藏在奇怪的状态组合中，但如果它永远不会出现在将在现实生活中执行的用例中，那么您可能不会关心它。有些人可能把这些情况称为极端情况，如果它们永远不会发生，那么它们就不重要。但是在实际用例中可能发生的事情是很重要的，用例的良好定义也是很重要的。

讨论确定了三个基本问题:

1. 我们能否预测设计中影响较大的bug会出现在哪里?
2. 我们能找到所有的漏洞吗?
3. 我们怎么知道什么时候完成了呢?

这样一说，立刻就有了异议。这基本上是一个谬论，因为它暗示bug是可以从一些黄金来源中找到的，因此您正在验证架构定义。在架构定义中，我们必须是完美的，这样才不会有bug。因此，存在bug。

第二个问题很快被修改为，“我们能在这些块中找到所有有意义的bug吗?”

Oski的Shirley提供了一个行业如何发展到今天的历史回顾，其中重要的元素是，当频率缩放和功率效率缩放结束时，我们转向了并行。这反过来又引起了状态空间的爆炸。并行性可以存在于处理器空间中，存在于系统各个方面的通信通道中。这受到了一些阻力，因为添加更多的核心并不一定会增加复杂性。无序的、超标量的机器增加了复杂性。复杂性就在这些机器的流水线上。为了获得1%的单线程性能提升，需要的状态空间远不止增加更多的内核。

其他人同意最初的说法，说我们增加了不同程度的复杂性，当我们放入数百或数千个核心，并试图控制并行性，这些核心的同步，以及进行资源共享，并拥有多个通道和多个端口，以便数据包分布在多个通道上。最后，一切都必须结合在一起。

但讨论的重点仍然是单核和这些核中的复杂块。人们认为，这些区块的验证问题仍然比soc级别的验证更困难，尽管有可能实现知识产权只有当它们与完整的互动时才会出现的bugSoC．这就引出了一个问题，“你应该能够在IP级检测到这些吗?”这表明块的用例没有被正确定义。或者，这是一个规范问题，其中两个或多个块不能正常工作，即使其中任何一个块都没有实现错误。

讨论又回到了bug“不可避免”的概念。这个词让很多人感到困扰。有人建议说，“有理由”或“失望但不惊讶”可能是更适当的说法。一个典型的反应是，考虑到工作量，我们认为它不会逃脱，但它确实逃脱了。与此同时，我们不能感到惊讶，因为我们没有投入无限的工作。这不是不可避免的，因为如果我们坚持下去，我们就会找到它。

这归结为定义了一个好的验证方法这是最有可能在项目时间内找到您所关心的bug的方法。当bug出现时，您进行事后分析，并决定将来是否需要更改方法。也许这是一个覆盖漏洞，或者使用了错误的工具来解决一类潜在的问题。

在设计的某些领域，如果我们发现bug，我们会很震惊，因为它们太简单了，这也是我们最失望的时候。这有时与错误的人事决策有关。团队确实确定了最可能存在漏洞的地方，以及他们将在芯片上面临的最棘手的问题，并让他们最好的人员负责这些问题。如果他们忘记了简单的东西，那么就会出现可以避免的错误。

我们能说有些bug是模拟无法发现的吗?即使部署模拟，可以提供更彻底的检查，可能无法接触到他们。如果漏洞有20层之深，并且需要发生许多事情的组合，那么即使你怀疑它们在那里，它们也会逃脱。仿真可以让您更快地创建原型，但是当它用作仿真增强器时就不那么好了。有些时候你必须使用更高级的方法，比如正式的，它有机会找到它。

如果您没有合适的工具或合适的人员，那么错误是不可避免的。所以，如果模拟团队无法发现这个错误，因为它是如此极端的极端情况，那么它是否应该被认为是不可避免的?一些团队在使用正式形式时发现了在模拟过程中遗漏的问题。这就带来了ROI，这可能是一个棘手的问题，因为当分析是事后完成的。如果给我们更多时间或资源，我们便能够很容易地呈现出模拟是如何捕捉到它。但有多高呢?

这需要仔细检查模拟方法。可能一个约束随机解算器把你带到那个特定的场景了吗?这和说如果给定无限时间，我们就能找到它是很不一样的。当使用formal来查找错误时，它会生成一个简明的反例，可以在模拟中重新创建。当你知道窃听器在哪里，你就能击中它。

模拟方法在公司内部已经高度建立，并且有更多的资源可用。生态系统更好了，模拟基础设施已经存在了。但当你看到一家新公司，有全新的设计，有没有机会做一些不同的事情?

现在模拟和正式的启动成本相似。成本方程通常倾向于模拟，因为它已经存在了。当你从零开始时，等式就不一样了。

但这也存在一些问题。很少有系统是100%经过正式验证的。在设计中可能会有一些经过正式验证的核心块，但对于大多数设计，也将使用模拟。一个完整的验证方法将需要建立这两种基础设施，但两者之间的分割可能非常不同。

Oski介绍了几个例子，试图细化bug类别之间的区别。复杂性再次成为讨论的重点。

图2:涉及GPU管道的案例研究。来源:Oski Technology

除非管道有足够的深度，并且出现错误的要求涉及异步事件的注入，否则错误应该被认为是令人失望的，而不是不可避免的。这是因为受约束的随机应该能够提供好的结果报道．有一组条件，约束随机指令序列生成器应该能够在合理的时间和模拟资源内生成，你应该期望有这样一个项目。

另一个例子涉及到多路缓存。有更多的人接受这个例子确实有一些非常棘手的方面，并且它将是抵抗模拟的。然而，也有人认为，一些用于协助正式验证的技术也可以同样应用于模拟案例，这使得发现错误的可能性大大增加。

图3:指令缓存的案例研究。来源:Oski Technology

方法是不断变化的。在最低层次上，它是随着团队对设计的熟悉而调整覆盖模型。没有人能够获得100%的功能覆盖率，但是你必须不断地评估目标是否是你所需要的。当在开发过程的任何阶段发现bug时，您都需要不断评估是否需要进行调整。门槛越来越高。你的方法必须适应那些你被限制随机找不到的错误。曾经的超级细菌变成了普通细菌。

我们是否应该将覆盖率模型视为一条分界线，将您无法找到的内容分隔开来?当我们发现这些所谓不可避免的错误时，并不是说它真的不可避免。只是我们在错误的地方画出了覆盖模型的边界。

所有的方法都有一个致命的弱点。他们都认为核查环境是完美的，但事实并非如此。刺激方案可能是完美的，但在检查程序中可能存在漏洞，或者覆盖模型不足。形式验证是基于定义一组特定的属性和假设。但是ROI案例中的一个重要因素是可以多快地分析可疑的错误。是设计中的bug还是testbench？要花多长时间才能理解发生了什么并找到根本原因?

使用正确的工具是方法论的一个重要方面。例如，一些人尝试着使用模拟来检测死锁，而另一些人则试图使用形式化的方法来解决这个问题，还有一些人努力使用更好的设计原则来避免这个问题。

如果您有预期的并发性，那么您可以很好地处理它。当出现意外并发时(通常来自异步事件)，您可能会遇到问题。当这种情况发生在设计的深处时，生成所有的组合就变得越来越困难，当对设计进行微小的更改时，这些组合就会发生变化。如果设计只进行了小的修改就被重用，这也会产生意想不到的问题。必须仔细考虑这些变化的影响。

总之，该小组认为，与模拟相比，有一类块更容易用正式方式关闭。然而，公司已经在模拟方面取得了成功，他们应该仔细考虑如何继续验证风险最高的区块。ROI是一个重要的考虑因素。已经接受正式价值的公司更有可能积极采用它，推动模拟和正式之间的界限，以实现更高的验证“物有所值”。

这需要时间，但当正式发现一个错误，并提供了一个简明的反例，确定了根本原因，设计师往往会印象深刻。但他们需要看到一些能建立这种信念的东西。只要正规不发现假阴性，就会获得信誉。Oski断言其假阴性率仅为9.1%。与典型的模拟假阴性率(在验证过程的早期阶段可高达60%)相比，这个数字非常低。

参加讨论的有AMD的Wayne Yun;Mark Glasser，《大脑》;思科的Anatoli Sokhatski;Shuqing Zhao和Hari Krishna Reddy, Facebook;英特尔公司Erik Seligman和Vinod Bhat;Ty Garibay, Mythic;英伟达的Ambar Sarkar;Jay Minocha《Provino》;Jacob Chang, SiFive;Carlos Basto, Synopsys。 Presenting from Oski were Craig Shirley and Roger Sabbagh.