最大的验证错误

SoC今天的美国比以前有更多的处理器和更多的嵌入式软件，包括驱动程序和中间件，只是为了让硬件工作。这反过来又要求我们做得更多更好验证．增加挑战的事实是，没有一种方法来进行验证，很容易理解硬件和软件团队从设计过程的最初阶段就接受验证过程和方法是多么重要。

“许多公司低估了验证芯片所需的费用，”英特尔公司验证营销高级总监迈克尔·萨尼(Michael Sanie)说Synopsys对此．“如果你看看半导体设计的发展方式，验证部分会让人们感到惊讶。并不是每个人都这样。一些公司早在10年或15年前就发现，验证可能是一种战略优势。如果你知道如何做得好，你可以投资它，建立基础设施，让你的业务优势。但真正做到这一点的公司并不多。我已经看到，在少数几家公司中，将验证作为一种战略优势的思考水平。这背后最大的驱动因素是上市时间，因为人们已经意识到上市时间，及时推出芯片肯定会带来优势。”

但验证也主要发生在设计周期的末尾，这会影响其对芯片制造商的战略价值。萨尼说:“你因为时间而匆忙，你做得不够，因为你急于得到一些东西，或者你因为想做更多的验证而在时间表上造成延误。”“这总是瓶颈。好的验证不是在设计之后才开始的。它应该在您设计和构建设计环境时开始。团队应该在这一点上考虑验证，而不是等到设计结束。”

的首席验证科学家Harry Foster指出，人们犯的另一个错误是关注工具，而不是验证过程本身导师图形．“这是工具和技术，但也是我们采取的一系列步骤，使其可重复使用。它是在组织内部开发适当的技能来利用技术——这是一个许多组织没有解决的问题。然后，最重要的是，它在流程中构建指标，以便他们能够可见地确定事情是否在工作。很多人都想要一把完美的锤子，但他们却不会回过头来决定自己是否需要一把锤子。”

他说，工程团队也过于关注如何验证，而不是验证什么。“我一遍又一遍地看到这种情况。换句话说，有些人将专注于他们将如何创建一个UVM测试平台，而不是坐下来问他们真正需要验证什么。他们忽略了整个方面。这可以归结为第一个问题——糟糕的验证计划。就是这么简单。”

福斯特说，就像你只需要一辆大众汽车就能驾驶747一样，验证也是如此。“这是拙劣的验证计划，缺乏对他们试图验证的设计类别的最佳工具、最佳技术和最佳方法的理解经验。”

但他说，这需要一套特定的技能，能够退一步，看看设计，了解如何需要和需要什么。“一个组织需要一些东西。他们需要一个验证架构师，然后他们需要实现者——把管道和工具中的基础设施放在一起的人。很多组织都没能做到这一点。验证架构师是有经验的，因为他们可以查看问题并了解需要验证的内容，不仅了解需要验证的内容，还了解哪种类型的工具和技术适合或不适合进行验证。这确实需要一些专业知识。你需要一个更了解建筑的人当然也要了解设计。许多组织没有认识到这一点，所以他们有一群验证人员和领导，领导只是管理，他们没有真正拥有架构视角的人。这里面有很多技巧。你必须深刻理解设计，但你也需要了解哪种类型的方法适合这种技术。” This includes knowing what you are trying to accomplish from a verification perspective and how to measure that goal.

不要只在问题上投入资源
“正确”的验证路径充满了复杂性，在问题上投入资源并不总是最好的解决方案。

虽然顶级半导体公司可能有更多的资源来应对验证挑战，但这并不总是最好的情况。查理·卡尔，设计服务提供商的首席技术官突触的设计，观察到对于大公司如Qualcomm“这是他们拥有的企业，并将继续拥有，他们将继续围绕这一点发展。”因此，他们将在这个问题上投入大量的精力和资金。在这种情况下，资金和公司的规模是齐头并进的，他们会做任何事情——几乎是用尽一切办法——他们会尽其所能。但当你回到大公司，也许它不是主流的部分。也许它是一家大公司的一个部门，但他们不是公司的主流部分。在这种情况下，他们可能不会投入那么多，而会更加注重成本。他们会看看哪里有意义。也许他们只是做了一些知识产权FPGA中的块是新的，并且在FPGA上没有任何进一步的发展，其余的都是用UVM完成的。”

Synapse Design的总裁兼首席执行官指出，他们看到许多公司采用传统的验证方法，并且已经这样做了很长时间。这种方法通常包括投入太多人力、资源或购买太多工具，但仍然不能降低风险因素。相反，“我们会说，‘让我们跳出固有的思维模式。让我们看看你在做什么设计。让我们分析一下做FPGA有什么意义，做不同类别有什么意义。’”

他表示:“即使是在前10大半导体企业中，Synapse的验证情况也不太理想。”“我们已经进入并查看了他们的验证环境，告诉他们有多少漏洞，并进行了事后研究，以确定为什么第一次尝试不起作用，为什么第二次尝试不起作用，漏洞是如何通过的，以及他们在设计验证环境时存在的根本缺陷。这不仅仅是用尸体来解决问题。尽管他们在这个问题上投入了资金，但他们仍然没有构建它。它一开始就设计得不对。在一天结束的时候，如果你想用最少的努力得到正确的芯片，这都是关于ROI的。这就是为什么根据你想要做的事情，验证设置需要完全不同。”

沿着这些思路，节奏研究员麦克·斯特尔福克斯指出，核查计划的一个关键部分是正确估计核查任务。但这仍然是一种艺术形式。“这是我们看到人们努力制定一个全面的验证计划的一个领域，他们可以用这个计划来真正跟踪他们的进展，并确定何时完成，因为验证完全是关于风险管理的。你不可能完全验证某件事。你必须尽自己最大的努力来降低风险，而做到这一点的最佳方法——就像其他任何事情一样——就是制定计划，并通过指标来管理你的进展。”

Stellfox关注的另一个领域是对UVM和受约束的随机覆盖驱动的验证的极大关注，这已经成为工具供应商在过去两年中与客户一起工作的主流方法。“这种方法实际上是为我所谓的自下而上的IP验证而构建的，也许是子系统验证，在这种验证中，你试图验证独立于任何特定SoC或应用程序上下文的硬件。”

“在这种验证中，”他继续说，“你真的想要尝试彻底验证，因为你不知道它将如何被使用。这些ip可能位于许多不同的芯片中。这应用得很好，但我看到很多错误的地方是，当你看一个带有软件的SoC时，没有太多的关注，每个人都只是在做SoC集成和用例验证的临时方法，你想验证所有这些IP是如何在某些特定的应用环境中协同工作的。”

Tom Anderson，营销副总裁Breker表示同意。“我们在soc方面看到的最大问题是，人们只是因为他们在验证单个区块方面做得很好，就假设把它们插在一起，并期望它们工作。我们有一个早期的客户，他有一个很大的SoC——一个处理器和一大堆不同的块——他们实际上已经很好地验证了这些块是正确集成的。他们从未做过的是将数据块流到一起，形成我们所说的用户场景。这个客户有一个场景，他们有两个区块在交换数据，它们在总线上相互交谈。它们都被独立验证过，但他们从未在现实模拟中将它们联系在一起。他们是反向的，所以他们必须让第一个块把数据写入内存，运行软件算法翻转所有的位，然后让数据到第二个块。这是一个非常昂贵的软件补丁，它在那个特定的操作中扼杀了性能。”

考虑到目前soc中嵌入式软件的数量，以及验证用户场景的需求，所有迹象都指向自顶向下、软件驱动的验证技术，而不是目前流行的自底向上方法。这些技术多快能提供给用户，多快能被采用，还有待观察。

哈里·福斯特对核实的最佳建议是:

• 工程团队必须锁定硬件和软件之间的API。“如果做不到这一点，我们今天遇到的大多数问题都会产生。如果我们能达成一致，团队就可以分开去做他们的设计。只要他们坚持API——硬件和软件之间的通信——团队就可以独立地设计和验证他们自己的组件，因为他们没有违反为硬件和软件通过API通信而建立的规则，所以他们知道自己的组件是可以工作的。”
• 不要只得到硬件，得到软件，把它们都放在一起，扔进去，然后开始验证，尝试启动操作系统或高级功能。相反，增量地检查事情。“我有硬件和软件:软件能与硬件的适当方面对话吗?将验证划分为适当的阶段或阶段，目标是确定在特定阶段或阶段验证什么。