ASIC设计何时停止验证 FPGA和ASIC之间的验证差异分析

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

即便如此，这些设计仍然有bug。只是它们的灾难性还不足以导致重新旋转。这意味着需要更高效的验证。在此之前，验证团队继续用各种方式的刺激来挑战设计。但并没有一个确切的科学方法来表明何时停止验证。

重旋在很多层面上都会造成痛苦。在28纳米上的重旋可能会增加50万美元的新掩模成本，而在较小几何尺寸上的重旋可能会花费100万美元。还有就是失去目标市场的问题。如果一家芯片制造商服务的是一个价值数十亿美元的市场，而在一个只有24个月的产品生命周期中却晚了3个月，损失的收入可能是毁灭性的。但何时停止并不总是显而易见的。

“要想让验证被认为是完整的，首先必须对验证覆盖率有一个坚实的理解，”OneSpin Solutions公司设计验证解决方案产品经理Nicolae Tusinschi说。“如果不知道验证中是否或在哪里存在差距，就很难达到IC完整性标准，也就是确保设计按预期操作，是安全、可信和可靠的。如果没有精确的覆盖率分析，你就无法放心地达到签收。需要的是快速、精确地衡量进度和覆盖率的提高。”

根据开发人员在生态系统中的位置，验证任务因不同程度的挑战而变得更加复杂。“如果你是一家设计硅片、封装、电路板、系统和软件的系统公司，你实际上可以奢侈地完全控制，”Cadence的产品营销总监Michael Young说。“但是想象一下，你是博通公司的客户，或者你正在设计某款芯片，该芯片装在插入计算机主板的PCIe卡中。要了解系统方案是非常困难的。为了降低风险，以及重新旋转的成本，以及发现客户的bug，左移的概念已经开始发挥作用。所有过去在硬件层面做的活动都被转移到硬件/软件中。而这种硬件/软件的开发是在SoC层面进行的，SoC的开发也在尽可能早的进行。这里的挑战是，仿真器并没有像过去那样提供同样的速度提升，所以很多人都在左移仿真或原型系统来做额外的工作，并将更多的工作量转移到验证上。”

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

图1：以系统为中心的SoC视图。来源：Cadence

什么时候能完成？

那么，在验证一个芯片或一个子系统或一个封装时，“完成 ”究竟意味着什么？

“如今，采用功能和代码覆盖是必须的--你必须拥有它，而且你必须投资于它，”Vtool的CEO Hagai Arbel说。“越来越多的公司都在这样做，并且相当严格地遵循它，然而第一次正确的芯片的比例却在下降。如果你检查那些有bug或bug严重到需要重新打磨的芯片，他们遵循了验证中‘完成’的最先进定义，即功能覆盖率和代码覆盖率100%。你会看到不少这样的情况。这意味着它没有帮助。”

Arbel说，事实上，即使在功能覆盖率达到100%，代码覆盖率达到100%之后，高技能的验证工程师也会发现关键的bug。“他们是如何发现它们的？他们怎么知道100%的覆盖率它是不够的？每个优秀的验证工程师都会产生这样的预感：‘它说是覆盖了，但我不放心。我觉得有些东西不对劲’。真正优秀的验证工程师对此有某种第六感。他们就是知道。而如果你是一个非常优秀的验证经理，你就会对别人的验证产生这种感觉。如果你回顾一下覆盖面，我不是说它不重要。但是还不能确定，甚至还不能接近。除了代码覆盖率和功能覆盖率之外，还应该考虑其他指标，比如验证工作的质量。不过，你做这些事情能有多安全呢？有些公司确实在努力解决这个问题。有些公司已经设法制定了更好的流程和内部流程，但作为EDA行业，我们甚至还没有提供一个足够好的解决方案。这里面有巨大的机会，我们要努力把记录信息和做出结论的方法正式化。”

归结到本质，验证是一项风险管理工作。“如果你看看FPGA和ASIC之间的差异，以及他们对待验证的方式，从风险管理的角度来看，你开始明白为什么他们对待事情的方式不同，”西门子EDA的IC验证解决方案营销总监Neil Hand说。“在FPGA中，他们承担更多的风险，因为他们可以在事后修复它，而在ASIC中，你不能。因此，如果你开始把验证看成是一项风险管理工作，它就不再是一个何时完成的问题，因为你永远不可能完成。那么问题就变成了，”我什么时候达到了我的风险承受能力？什么时候我已经到了我觉得可以放心地签下这个设计的地步？“

可以帮助的是拥有数据和工具来更快地完成覆盖。”你有覆盖率，这是今天很多人衡量风险的方式，但覆盖率不是全部，“Hand说。”你可能有覆盖面的漏洞。你可能没有定义覆盖范围。可能有很多差距。但如果有一套你定义的指标，你可以根据这些指标进行衡量。另外，可以利用工具和技术来确定这些指标是否良好。你可以有一个覆盖方法论，你已经定义了1000个覆盖点。你击中了这1000个覆盖点，但这1000个覆盖点只击中了你设计的10%。那么你的风险暴露是什么？“

这些都是必须要解决的问题。但这并不是那么简单。定义风险边界是一个移动的目标，因为它取决于设计，以及该设计在系统内的背景和与其他系统的交互。

”有一个权衡，但对于每个芯片来说，它是不同的，“他说。”可接受的风险对于每个设计都会不同。你要做的是给工具，不管是通过验证管理、需求管理、覆盖率可追溯性，还是通过机器学习，了解你看了什么与没看什么。当我们在某一个领域看的时候，我们往往会变得盲目。我们没有看到右肩上那个准备扑过来的怪物。我们可以利用机器学习技术来识别你做的都是正确的事情，但那个怪物还在那里。“

这在异构系统中尤其如此，随着摩尔定律的耗尽，异构系统越来越常见。这迫使设计团队使用新的架构作为各种应用和市场的差异化因素。这既为定制加速器打开了大门，也推动了RISC-V的部分发展势头。但这也使设计变得更加复杂，更难验证。

”我们在使用开源内核的设计中看到了这一点，其中有我们以前从未见过的新的角落案例，“Aldec的营销总监Louie de Luna说。”验证也是如此。我们看到了新的UVM用例，我们也发现了很多错误。“

De Luna指出，这也推动了很多相关的活动，比如虚拟建模和多核调试。实际上，工程师们正在利用一切可以利用的东西来应对不断上升的复杂性。

不像听起来那么简单

虽然这其中的大部分都取决于设计和用例，但也有越来越多的共识，即验证需要是一个连续的过程，而不仅仅是设计流程中的一个单一步骤。

”这个问题的一个非常简单的答案是，‘当你证明设计没有任何缺陷时，验证就完成了’，“Valtrix系统公司首席执行官Shubhodeep Roy Choudhury说。”这时你就可以称你的验证完成了。但这是一个NP硬问题，永远也做不完。你有空间。测试的数量和覆盖率是无限的，所以从技术上讲，你永远无法真正完成你的验证活动。“

还有一些其他因素需要考虑。”你必须确保功率和性能目标得到满足，并且你的最终用例向你设计的东西是按预期工作的，“Roy Choudhury说。”其中一些标准可以用来判断验证已经接近完成，比如当你拥有所有的代码，代码覆盖率和功能覆盖率都达到了你的设计和验证团队可以接受的数字。通常情况下，所有这些设计都是在你已经有的一些以前的设计之上的迭代，所以从验证的角度来看，很多努力都花在了开发测试上，这些测试行使了设计三角洲，以及新功能与旧功能的交互。这意味着要花费大量的精力来编写测试。你需要确保这些测试按照预期工作，没有任何故障或失败。你需要优秀的验证工程师来判断是否满足了意图，以及设计是否按照预期进行。有一些活动，比如在设计的某些部分，你可以应用形式化模型，得到设计真的没有任何缺陷的证明，也可以在任何可以应用的地方使用。“

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

所有这些都必须与功能和代码覆盖工具相配合。每次新版本的设计，通常都会有涉及代码和功能覆盖分析的阶段，以确保所有预期的方案都能被击中。这些都是用来确保设计得到验证的指标。

这里的另一个考虑因素是决定衡量什么，以及如何衡量。Imperas软件公司的首席执行官Simon Davidmann以最近的一个RISC-V项目为例指出。”我们刚刚和OpenHW集团一起参与了一个32位RISC核的项目，首先发生的一件事就是写了一个测试计划，说‘这些是设计中已经测试好的位子，这些是新的位子，这些是我们担心的位子，而这些位子可能有一些隐藏在翅膀上的东西，我们并不知道。他们提出了测试计划，投入了资源，可以说，’这一点的设计我们要用定向测试，对于这一点我们要用随机。对于这一点我们要用异步和比较测试，对于这一点其实我们要用正式的来测试东西如何进入和退出调试模式，这在传统上是相当难的事情。你基本上要看你所面临的设计挑战，然后计算出你知道什么，不知道什么，以及风险是什么。我必须达到什么水平才会对 “足够好 ”感到满意，因为你无法证明没有bug？你只能说它足够好，可以出货。“

知识共享

Vtool的Arbel说，另一个障碍是如何与其他团队成员分享，这是整个设计和验证过程中的一个重要方面。”通常情况下，不止一个人参与。我是一名验证工程师，我认为我有一个问题。我把它发给设计师。他要把它发回来。架构师在中间，软件团队也会参与进来。参与的人很多，大多是互相推诿，不能真正协作，共同解决这个问题。验证工程师必须学会如何利用他们的综合知识来提高工作效率。如今，调试是一条孤独的路--孤独在于很难让人帮你，但也很难教你。“

对于这一点，Roy Choudhury表示，彻底记录下所做的任何事情都是有帮助的。”如果你对整个验证活动有很好的记录，就会有相当大的帮助。在我以前的一家公司里，我们曾经保留了整个硅后验证过程的日志，这些日志曾经在我们用来验证的服务器设计上完成。这是非常详细的。例如，我们曾经为负载存储单元、为CPU测试等设置了区域负责人，每个人都有一大套遗留测试，只要测试人员有空，就会给他们分配N个小时的时间来测试设计。随着时间的推移，我们对所有这些验证活动都有记录。根据新功能的到来，例如，如果有很多功能发生，那么负载存储单元区的所有者，将获得更多的测试小时数。在这一点之后，如果你把所有的东西都记录得非常清楚，如果你有整个历史计划在身边，那么就会变得非常无缝。“

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

OneSpin的Tusinschi指出，通过基于形式的突变分析、基于模型的故障注入以及对源代码的精确映射，可以快速、精确地衡量进度和覆盖率的提高。”其结果是可靠地识别验证差距和盲点。当然，最佳的解决方案是将所有的验证指标，如来自仿真和形式化的指标纳入一个视图，以便更好地了解整体的验证工作和进度。“他说。

结语

当你觉得你已经完成了，Imperas的Davidmann说：”你必须把测量到位，你必须分析。当有问题时，你需要了解流程是什么。这都是关于经验的。你需要大量的经验来研究如何做到这一切。此外，新的技术正在出现，希望在生成测试时使用AI的团队正在涌现新技术。您可以使用AI来查看测试的有效性，查看测试在设计中的位置以及什么是做事的更好方法，以便它可以帮助改善正在执行的测试的质量。如果做得正确，这可以节省完成所有测试和回归测试以及改善事物质量所花费的时间。目前，我们正处于使用AI协助我们进行验证的初期阶段。”

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

编辑：hfy