每当一种标准模式，如SystemVerilog and UVM ，被广泛采用时，无疑对用户和工具开发商都是有利的。对于用户而言，终于可以在多种工具中采用统一的代码准则了。而对于工具开发商，开发的工具也只需要支持一种特定的语言或者库就可以了。

但是呢，标准这些东西毕竟也都是人定的，标准不断发展衍进的过程中，缺点自然也是有的。

标准制定的缺点就在于所有的标准最终会到达一个使得收益递减的点，在这个点时，标准往往可以满足大多数用户的需求，而这时，标准制定委员会会受到一些非典型用户的驱使，这些不安分的用户会追求那些更优秀的功能，使标准不断创新“进步”，变成“更好”。但是不幸的是，这些功能经常使标准变得相当复杂，而且效率低，并且可能与以前版本的标准不兼容。标准的主要目标是为用户提供一个稳定好用的平台，而这些鸡肋的新功能点可能对用户的意义真的不大。

本文分上下两篇，上篇主要分析一下SystemVerilog与UVM标准的发展历程。下篇会谈到对UVM标准未来的发展动向的看法。

验证语言的发展

IEEE标准协会主席KarenBartleson 简要介绍了EDA发展的理想准则——“在标准上合作，在产品上展开竞争”。SystemVerilog和通用验证方法（Universal VerificationMethodology，UVM）

就是这一原则下较理想的产物。在这些标准出现之前，用户不得不使用诸如Verilog或者VHDL等硬件描述语言（HDL）来创建它们的测试平台，或者使用专用硬件验证语言（HVL），但HVL将会将用户和特定的EDA供应商绑定，因为不同工具商支持的HVL都有所不同。HVL的产生，说明了HDL本身实在没办法对越来越复杂的设计，进行有效的建模验证。HVL主要由有这样两个关键的特性，使他们能够推广开来。

其一是HVL描述对象的能力，对象可以在运行时具体分配，这使得描述testbench时更为灵活，而HDL的所有组件在初始时刻时就被静态地实例化了。其二是HVL带约束的随机化能力。将二者结合，就意味着验证环境可以依据算法创建，并且允许随机化的环境结构和随机化的激励数据。

 在SystemVerilog标准的开发过程中，委员会明智地决定不对具体解决算法进行标准化，这就使得不同工具商间产生竞争，都力求在最短的时间内实现最大的解决空间覆盖率。这种竞争机制推动了工具开发这个重要领域的创新，对用户生产率具有深远的影响。HVL的开发，部分原因是由于认识到SOC功能验证实际上是软件问题而不是硬件问题。当HDL只能描述芯片中的静态硬件时，芯片操作却很期待一个“真实世界”，这个“真实世界”需要有很多动态行为，这些动态行为需要描述语言具有随机化、对象和其他HVL特征才能实现。另外，用户很快意识到，这些行为的环境可能相当复杂，并从头开始为每个项目重新开发新环境不是很可行的策略。因此诞生了验证方法的概念，以促进验证IP的重用。

 第一种验证方法是由特定语言编写的，并只有特定的工具才能用，早期HVL自身就是基于不同工具特定的。一旦用户选择了一种语言与相应的模拟器，就非常难换到另一个家供应商了，因为这意味着必须要基于另一种语言，重写测试平台代码。不过后来即使出现了SystemVerilog，这种情况也并未改变太多，EDA供应商有一些专有语言扩展或底层PLI代码，因此仍然会锁定用户选择特定的工具和供应商。即使许多供应商声称支持SystemVerilog标准，即使用户也坚持使用所有的EDA供应商都支持的SystemVerilog公共子集，EDA工具还是会不支持由不兼容的方法编写的IP。

不过标准化的UVM解决了这些问题，如今，所有主要的模拟器供应商都支持UVM了。

SYSTEM VERILOG的发展

SystemVerilog源于一种名为SUPERLOG的语言，SUPERLOG是1999年由Verilog的原创者开发的。开发者的本意是替代verilog成为更现代化的描述语言，然而用户并不愿意从头开始使用一种新的语言，用户的Verilog设计和验证平台代码数据库已经很庞大了，所以他们显然只接受进化的方法，而不接收革命性方法。所以SUPERLOG语言只好被重新设计定义，以100％向下兼容Verilog。

最后，SUPERLOG赠给了Accellera，并成为2002年第一版SystemVerilog 3.0的基础。SystemVerilog将包括Verilog，Specman和Vera在内的许多不同语言融合成一个统一的设计与验证语言。在过去十年里，SystemVerilog已经集合了许多功能。开始时只作为Verilog加强版的140页面说明，到现在是一个1400页的手册了。

当然，一般人是不会注意到SystemVerilog各种功能的发展的历史因素了，想从SystemVerilog中删掉一些功能还是很困难的。比如always_comb与always @ *等。

在Verilog-2001标准发布之前，SUPERLOG创建一些方案解决自动生成敏感列表问题，而且比verilog更进一步，SUPERLOG还解决了一些其他问题。如当A和B是常数的情况时，这样输入就没有变化，out也一直没有初始化。SystemVerilog的always_comb语法解决了这一问题，always_comb保证在0时刻会执行一次。SystemVerilog中现在有了这样的两个构造几乎完全相同的东西，可能很多人大概并不知道always_comb。

UVM 的发展

 用户一直在努力期望实现“模块化，可扩展和可复用的通用验证环境”，最终就形成了UVM标准。此前，基于SystemVerilog的验证方法学主要有两种，一是由Mentor Graphics和Cadence公司共同开发的OVM，另一个是由Synopsys开发的VMM。在开发互用性库2时，为了使OVM和VMM基类库能够同时使用，委员会决定开发UVM。

在用户驱动下，委员会很快达成共识，使用OVM作为UVM的基础，使用SystemVerilog作为HVL来实现UVM基类库。2010年5月发布了UVM 1.0EA的“早期使用者”版本，随后于2011年2月发布了UVM 1.0。从那时起，UVM委员会继续发展，致力于实现UVM1 .2。 在此期间，UVM库在规模和复杂性上继续增长，如表I所示。

 1.0p1和1.1之间规模增加的主要原因是，1.1中包括了“phasing”。 这一版本尝试提供一组预定义的方法来细分run_phase，这是在UVM测试平台中所有组件都执行的唯一的基于任务的方法（见图1）。

runtime phasing机制的初衷是为用户安排一组任务，这些任务将以预定义的顺序自动调用，以便用户可以将跨多个组件的类似功能分到同一个phase中。然而，当UVM委员会试图详细定义在每个阶段应该做什么操作时，结果并不很如意，所以最后这部分留出来了，不同的团队或公司可以自行开发，以便在不同阶段执行不同的具体操作。

另一个更长远的想法是允许用户定义自己的phases，或者创建可与原始phases集合并行运行的单独“schedule”的phases，或者在预定义的调度中插入他们自己的phases。但运行阶段（runtime phasing）的可用性的重要要求之一是phase之间向后和向前跳转的能力。但是这个实现起来还是很有难度的。由于phase跳跃可能会导致仿真过早终止，这种情况下，不能对给定phase中的序列和其他可能产生的行为进行有效的控制，UVM委员会建议run-time phase方法仅从test开始sequences时使用，诸如drivers和monitors之类的组件只实现其中run_phase（）阶段。不建议在phase之间跳跃，特别是向后跳跃。

有趣的是，从一开始，phase的引入就被认为是UVM的“最高优先级”的功能开发，虽然在几年后，我们仍然没有非常满意的run-time phasing解决方案，但也并不排斥使用它。缺乏这一特定功能似乎并不影响UVM的性能。

UVM1.2复杂度的有有较大跳跃主要是由于UVM的消息和transaction记录能力的增强。

事实上，由于一些复杂的功能打破了向后兼容性，它们实际上可能产生负面影响。因此，重要的是理解何时一个标准才能被视为“完成”。我们将在本文探讨其他UVM改进的变化的影响。

UVM面临的问题

A. UVM Messaging

UVM 通过一组宏来处理UVM消息，这些宏允许用户发出与其相关联的ID消息，以及特定的严重性消息。这些消息被委派给一个名为uvm_report_handler的核心组件，这些组件可以进行配置，进而控制将某些消息打印到输出或日志文件等。报告处理器还允许用户定制消息的外观和布局，并且宏本身允许包括最初创建消息的文件和行号。命令行选项和UVM方法允许在每个组件或每个层级基础上进行详细设置，以抑制某些消息的报告。另外，可以基于消息ID和严重性为消息定义具体动作。UVM已使用这种机制多年，用户也都很熟悉了。

UVM1.2的一个增强的改进是可以在消息中包含多个字段，需要为每个消息使用多个宏：

它还包括指定“上下文”（即，要打印的消息中的uvm_report_object）的选项。 由于消息可以是INFO，WARNING，ERROR和FATAL类型，这是十六个新宏，另外四个宏用于向消息对象添加字段。这些宏允许用户添加整数、字符串、和uvm_objects作为消息对象的字段。

这种改动只是加入了有限的附加功能，但复杂性明显大大增加了。新添加的功能的价值也有待考察。UVM1.2中向消息添加附加字段，现在可以对消息的不同部分应用不同的操作，因此也可能显示消息的一部分，而另一部分不显示，也可能引入错误条件。这是将功能复杂化的另一个例子，它没有对大批用户进行现场测试，或者没有完全理解可用性的意义。

另外，与1.1d相比，打印消息时，我们的测量结果表明，使用建议的扩展方法来打印消息时，由于需要一些额外处理，所以会产生20%的性能损失，这完全是额外的开销。

 B. UVM Transaction Recording

在UVM中，transaction记录可以将特定对象的信息记录到模拟调试数据库中。由于每个模拟器都有自己的格式，因此选择了一个通用的API，每个模拟供应商都可以基于此实现记录。

但transaction 记录API的更改与1.1d不兼容，就要求EDA供应商基于用户使用的版本，提供两种机制来支持transaction 记录。除了对EDA供应商的产生额外负担，我们的性能测试表明相对于1.1d还会导致约65％的减速，我们认为这一功能，并不值得使性能下降。

结束语 

所以，本文的立场是，SystemVerilog和UVM都已达到相对完善稳定的情况，而不需要因为小众用户的需要而添加新的特性。这时应进入“冷却阶段”，为工具开发商提供一个较为稳定的版本，并在此基础上进行创新。下篇会谈到对UVM标准未来的发展动向的看法。