uvm 形式验证_完美的验证策略并不存在，但我们还是能谈谈如何优化

文章概要： 本文的主要内容类似访谈，引用了知名IC公司验证责任人对于如何优化验证的观点和建议。 “完美的策 略并不存在 ，但提 升依然有充足的空间。 ” 验证工具和方法学以令人咋舌的速度不断改进，这也为验证团队带来了新的问题。 在过去的20年中，验证已从单一语言(Verilog)和工具(simulator)，转变为利用多种语言(testbench languages, assertion languages, coverage languages, constraint languages)，多种工具(simulators, emulators, rapid prototyping, formal, focused apps)和多种抽象层次(system, transactional, RTL, gate)。 最近引入的Portable Stimulus standard(PSS)也可能会为验证过程带来新的变化 。 在此期间验证工程师的数量也越来越多，但是验证不再是一项初级工程师就可以轻松上手的任务，它 需要掌握跨领域的相关知识和多种编程语言。 任何工程师都不可能掌握所有的技能，因此验证人员需要一定程度的专业化，同时对验证领域知识的不断更新习以为常，能够持续学习。 面对以上变化，验证经理的人力、资金预算却是相对固定的。因此，他们必须仔细选择在何处、如何以及何时部署资源从而最大程度地减少bug。 验证工作是一个没有上限的挑战，但 没人能无限度地投入时间或资源 。 由于产品间的差异，以及每个团队在时间，资金及技术实力上的限制不尽相同，并 没有一个能套用到整个行业的“万能公式 ”。 “在工具和技术上我们有非常多选择，”Arm Engineering Services部门总监Tran Nguyen说，“我们最关心的是市场响应的时间，希望每10个月完成一次设计。 小型的设计这个时长是没问题的，但是现在普遍设计规模是数亿门，时间节点却还是一样。 这意味着必须提高输出。你可以循环跑很多次仿真，如果效率不高或者没专注在正确的事情上，这就是一种浪费。那怎么才能知道哪个cycyle有效？怎么定义有效？” 效果不是一开始就显而易见的。“你可能关注跑多少周期能发现bug，”Nguyen接着说，“为什么不换个角度呢—— 专注于确认设计的正确性 而不是寻找bug？只有把握正确的方向，更快更多的技术工具才能锦上添花。不能仅仅通过更多次循环来应对设计规模的拓展。” 每个公司都有不同的策略，即使同一个公司内部，不同的团队也可能存在差异。Intel Graphics Hardware部门总监Raju Kothandaraman指出自己公司中就存在多个(衡量验证的)指标——build，资源利用率，在环境中运行速度，寻找根本原因的时间，这都属于debug的一部分。 “作为验证工程师，我们密切关注这四个指标，”Kothandaraman说。“建立(build)时间，即RTL逻辑的硬软件多快的速度进入系统？将仿真提交到服务器速度有多快？资源的利用效率如何？我们测试平台是否高速高效，堪称业界标杆？最后，验证中最具挑战性的部分—— 怎么用最快速度缩小寻找bug的“包围圈”？ 我们会在整个验证过程中不断衡量这些指标。最重要的是大家能有正确的观念，了解不同领域的知识，持续不断的加快验证周期。” Samsung GPU EMU平台部经理Dale Chang专注于emulation验证。“吞吐量基本上等于可以向EMU提交多少仿真，再通过合理的分时占用，debug团队可以不间断工作，根据输出就可以知道发现bug的效率。达成这个目标需要很多环节的努力：从构建EMU基础平台的角度来看—— 基础平台足够高效，才不会浪费仿真平台的周期。 脚本自动化有助于分类错误信息并且重新提交用例。建立(build)，批量运行，提交进队列都要花时间，要提高效率而不是每步让工程师们都干等着。我们必须与IT，CAD团队，EDA厂商通力合作，提高验证流程的效率。”

衡量成功的指标

衡量效率的指标并不直观，但很重要。 “我坚定地认为没有控制，也就谈不上优化。”Paul Cunningham，Cadence VP兼验证部门负责人说，“吞吐量的概念非常直观，但是使其可以衡量不是一件简单的事。就像人们通常着重于汽车的性能，而忽略驾驶员的水平。每秒的周期数、波形生成的时间等就像拥有最好性能的法拉利，但是如果驾驶员水平不够好的话，是达不到物尽其用的。因此 正确的观念是对于高层次的指标 ，例如找出一个bug的根源(root cause)耗时多少、每人/天能找出多少bug的根源或者找出一个bug的根源消耗了多少资源，要做成树形或者层次结构来查看，不同的指标基于同等优先级，以免遗漏。“ 当验证不仅限于功能验证，也会使事情变得更复杂。 Dale Chang表示：“我们有好几个关键指标。一个用于功能，另一个用于性能和功耗。您必须确保GPU能够完成任务，您还必须确保您的GPU将与内核和驱动程序一起运行，以确保一切都能正常运行。内核和驱动程序在计划和调度作业以及处理结果方面起着至关重要的作用。 驱动程序、内核、固件、RTL不同层次之间的通信会引发许多错误。 实际上，我们开发了多个不同的测试平台，以满足每个验证团队的需求。为了运行内核，我们实际上需要一个混合环境。” 很多产品上要运行多个应用程序。“我们现在在做的事是将工作负载作为架构定义的一部分。 设计和验证团队通过紧密合作来确保从一开始就理解需求。 这样从底层验证时就可以确定我们需要的功能，并且拓展到整个芯片。“ Kothandaraman补充道。 考虑得长远些也有不少益处。来自ARM的Nguyen说“交互性也是效率和吞吐量的一部分。你会选用多种技术因为每种都有不同缺点。为了在这些技术之间切换， 测试平台需要尽可能多的复用。而且 不同项目间，不同产品间也可以尽可能复用。 基础架构，测试平台，测试用例——这些也可以。验证工程师数量稀缺，我们需要尽可能在项目中复用，提高自动化程度和减少不确定性。这是获得良好吞吐量的关键。”

抽象层次的级别

验证过程中另一个变数是抽象层次。“开关级，RTL级，门级，软件级…每个不同的设计层次都不同验证工作要做" Cunningham说，"充分利用这一点，对获得最佳吞吐量非常重要。 抽象是工具，要使用正确的工具来完成正确的工作。 就像你肯定不想开着法拉利去越野。” “软件开发通常在虚拟的测试平台模型上进行，然后在EMU平台上用真实RTL进行仿真” Nguyen说。“这时已经是RTL代码非常稳定的后期阶段了，所以刚启动时期的工作至关重要，要在很短的时间范围内交付很多东西。” 业内还有其他的重要推动力来推进抽象化。“IBS的数据显示， 软件以远超硬件的速率发展。 ”Cunningham说，“如果你想在硅前阶段(pre-silicon)完成更多的软件验证，这份压力会驱使你同时进行硬件验证和软件bring-up。” 工具时常推陈出新，验证团队要了解工具变化可能带来的影响。“与EDA厂商合作的时候要确保他们了解你的战略意图，而不是纠结于战术细节。”Kothandaraman说。“和他们沟通你面临的挑战以及对未来的期望，了解即将推出的新工具。目前而言，与EDA厂商的密切合作是提高吞吐量的最佳方法。你要对EDA厂商持开放和诚实的态度，把他们当做团队的一份子。 比如，我们公司也一直考虑应该用更多的形式验证还是更多的EMU验证。” 在这个问题上，Intel的观点不乏共鸣。”形式验证这个例子很好“Cunningham赞同道，”动态验证工作量很大的事，使用形式验证可以更高效地完成。形式验证还处于发展初期，我们还有更多工作要做，它是解决某类问题的利器。现在，我们在更高层次的验证平台尝试引入PSS。面对未来的情况，有时我们需要更换“驾驶员”，有时我们需要更换“汽车”，没有什么固定套路。 唯一不变的是我们会持续推动吞吐量的提升。 ”  

结论

验证工具和方法学将继续快速发展，这意味着 验证经理需要不断评估验证流程的效率 。对于验证工程师来说， 要想保持竞争力就要做好持续学习的准备 。 最重要的是： 随着PSS开创了验证进化的新篇章，验证从未如现在这般激动人心。   相关单词表：

verification methodology 验证方法学Universal Verification Methodology, UVMdeploy 部署throughput 吞吐量outset 开始critical metrics 关键指标protion 部分iteration 迭代infrastructure 基础设施optimize 优化intuitive 直观的notion 概念mindset 心态dispatch 调度hybrid 混合，混血Interoperability 互通性scarce 稀缺“bottom line”常用意思是“the most important thing that you have to consider or accept; the most basic fact or issue in a situation”，也就是“最重要的事；要点；关键之处”例句：The bottom line is that we have to make a decision today.savvy 领悟，精明root cause 根本原因，来龙去脉

原文来自： semiengineering BRIAN BAILEY - 2019.7.29 往期精彩：30w+还送股送房？60+家IC企业2019应届 薪资全面攀升！我们准备做第二期线下培训，依旧认真且严肃 如果你突然被裁员了，你的Plan B是什么？ [彩虹糖带你入门UVM]理解UVM-1.2到IEEE1800.2的变化，掌握这3点就够Verification和Validation傻傻分不清楚？面经重点！