没有错误的设计

从理论上讲，创建一个没有bug的设计是可能的，但这是不切实际的，没有必要的，而且很难证明您所关心的bug。

这个问题很棘手，因为潜在的状态空间对于任何实际设计来说都是巨大的。业界已经设计出了处理这种复杂性的方法，但每种方法都有局限性、假设，并采用抽象问题的技术。

行业最佳实践是尝试识别导致问题的bug并修复它们。主要有三种方法:

• 编写针对特定行为的定向测试，其结果是已知的;
• 采用约束随机测试模式生成，试图探索设计的行为并寻找异常结果;而且
• 部署验证技术，可以证明某些属性适用于设计。

决定对每个问题使用最好的技术是很重要的。Axiomise的创始人兼首席执行官Ashish Darbari说:“一些组织拥有非常先进的正式、模拟和仿真使用模型。“这些公司在这方面做得非常好。他们有来自模拟、正式和模拟的人员组成的团队，他们坐在一起，例行地划分验证关注点。”

定义流程
这需要一个过程。Cerebras Systems的技术人员Mark Glasser说:“你想要写下所有你想要确保正确工作的不同行为。”(Glasser已经转移到elastic .cloud)“我们称之为a报道模型。您需要开发一个全面的覆盖模型，但还需要考虑工作负载。你到底要用这个设备做什么?一个特定的工作负载可能在该设备上运行良好，而另一个工作负载可能在同一设备上运行不良。它是工作量和覆盖模式的结合，然后就是经验。”

这听起来可能不太专业。的销售副总裁拉里•拉皮德斯说:“经验直接与经验有关。治之软件．“你还需要确定设计中的新内容。如果你正在迭代一个设计，仔细查看新部分是很重要的。自从我们首次提出正式书面核查计划的想法以来，现在已经有20多年了。有些人仍然没有把它们写下来，或者至少写得足够详细。这是你将不同的团队聚集在一起的地方，每个团队都有不同的方法，并划分出谁将做什么。”

的存在验证计划意味着采用了一种方法。Mythic的工程副总裁Ty Garibay说:“我们有一个相当具体的功能分级清单。首先，我们研究不可编程状态机，最重要的是，与其他不可编程状态机通信的不可编程状态机。关键是要确保架构确实将这些控制对象指定为状态机，而不仅仅是随机编码RTL。”

有很多因素需要考虑。Darbari说:“你必须从确定风险最高的地方开始。”“然后你可以看看你的时间表，你打算什么时候结束，你可以支配的团队，他们的技能水平，工具，你要投入工作量的计算基础设施，一切都很重要。”

有不同种类的风险。格拉瑟说:“如果你在谈论商业风险，你要考虑的是你是否能够把这一部分卖给你的客户。”“当谈到状态机时，客户是否会使用所有的状态?如果不是，那么所有额外的工作可能会让你更有信心，但这并不一定会降低把零件拿出来卖给客户的风险。你需要考虑客户要用芯片做什么，以及它将如何在现实世界中使用。这样你就可以开始分析风险了。”

增量式设计更容易吗?
大多数设计都是渐进式的，但这种情况可能正在改变。Mythic的Garibay说:“在从头开始设计时，架构师的工作是构思如何将各个部分连接在一起，并指定一个可以验证的架构。“他们指定架构并记录它，以一种干净的方式定义它。这样贯穿整个设计阶段序列的问题就更容易处理了。如果你不这样做，你最终会遇到一大堆人们没有想到的奇怪的极端情况。有些人谈论为验证而设计，但这甚至是为验证而设计。”

这本身可能还不够。Darbari说:“RISC-V是开源架构的一个很好的例子，许多聪明的人正在RISC-V基金会开发这些规范。”“然而，尽管有这么多的智慧，人们仍然会犯错误。RISC-V的弱内存模型就是一个典型的例子。你只有13个公理，但普林斯顿教授却发现了一些不一致之处。现在，RISC-V并不是唯一存在问题的处理器规范。文献中充斥着所有处理器厂商的内存一致性问题。这是一个很难的问题，所以需要有人退后一步，把它写下来。很多挑战都在于不知道。”

所有这些技术都依赖于能够正确地指定我们想要设计的内容，我们知道如何定义任务的完成情况，并且我们有无限的时间和金钱来解决这个问题。这些都没有反映现实。

Cerebras的Glasser总结了这个问题。“在验证领域，我们谈论的是确保设计符合规范。这是黄金参考。我们有规范的一些模型，然后看看我们的RTL，我们的实现是否与之匹配。我想说的是，我们不知道这个规范是否正确。这也出现在正式的世界中。你永远不知道你是否拥有正确的属性。”

验证和确认
这就引出了第二个问题。验证告诉您实现是否与规范匹配。验证告诉您规范是否正确。这些都是定义不清的。Darbari说:“我们需要把所有的关键技术结合在一起，但我们需要在正确的时间提出正确的问题，并以正确的理由使用正确的技术。”“是的，我认为验证是渐进的，我们永远不会造出一个完全没有bug的芯片。但是我们将非常接近于此，然后能够忽略任何可能仍然泄漏的小缺陷。我们无法详尽地验证。这是一种风险管理练习。”

这样够了吗?加里贝说:“我们正在制造数百亿个晶体管器件，其中大部分都能正常工作，这几乎接近魔术的水平。”“我们已经取得了巨大的进步，但我们所处的行业往往每18个月到2年就会发展一次。挑战越来越大，也越来越有趣，这就是我们坚持做下去的原因。”

今天肯定有更多的事情需要考虑。格拉瑟说:“它不仅需要工作，还需要很好地适用于使用模型，适用于客户将要使用的用例。”“不管它将被用于什么用途，你都需要检查它。”

性能验证
可以正式的用于性能分析?Darbari说:“虽然正式测试不被认为是性能验证的实际技术，但在很多情况下，你可以应用正式测试。”“许多性能分析都是基于计数器，确保事情在一定范围内发生，或超过一定范围。我知道人们可能会持怀疑态度，但如果你真的想要建立一个可靠的证据来证明这些计数器是否可以超过某个界限，那么你应该考虑正式的。”

性能不仅仅是硬件方面的问题。它还涉及到软件，并且假设有真正的软件可用。Garibay说:“我最近的项目是一个基础开发项目。“没有软件。我们在做硬件开发的时候甚至没有编译器。在我们使用硅的时候，几乎没有编译器。我们尽了最大的努力。现在我们正试图利用这种学习来培养第二代。即便如此，也不会有软件来驱动真正的性能分析。我们用建模，用高级模型，试图对性能的发展有一些感觉。”

弹性设计
在这么大的压力下，你还能跟上吗?“当我们增加复杂性时，增加设计IP的使用是否真的有助于减少bug的数量?拉皮德斯问道。“从验证IP的角度来看也是一样的。将在高级节点上构建的芯片，它们是否会因为设计的本质而具有更强的弹性?”

这可能取决于你工作的领域。Darbari说:“弹性可能适用于手机和非关键芯片基础设施，但如果你为安全关键领域提供芯片，我们就不能容忍这种失败。”“我们可以进行更多的软件更新，我们可以激活鸡肉，但这不能成为验证的前提。当我们验证下一代芯片的时候，我们是不是一开始就说，它大部分都能工作，因为它已经在现场部署了20年，所以它是硅验证的?它可能已经被硅验证了，因为它被部署在另一个领域，但它满足这个领域的要求吗?”

如今，当系统级优化变得越来越重要时，公司希望软件成为验证方法的一个组成部分。“许多公司一直在使用敏捷拉皮德斯说。“其中一些已经开始使用敏捷的硬件开发．他们所做的是带着RTL和虚拟原型，这样他们就可以同时带着他们的软件。现在，当他们在规范中遇到错误或模糊时，每个人都同时在同一页上。你不需要硬件人员切换上下文，回到他们三个月前的工作，因为现在的实现，驱动程序和用于验证的虚拟原型都是同步的。这使得整个过程更加高效。”

并不是所有人都相信这一点。加里贝说:“对我来说，这听起来像地狱。”“在设计过程中尝试与软件团队进行实时协商听起来令人生畏，但我明白你的意思。我可能得重新考虑一下了。”

结论
构建一个没有漏洞的设计可能是不可能的，而且考虑到每个公司都面临的时间和资源限制，这当然是不切实际的。做得最好的公司都有明确的流程和实践，以确保他们的设计在预期领域内运行时不太可能出现使人衰弱的问题。超过这个数字就被认为是浪费。