在过去的几年中，UVM在几大EDA公司不遗余力的推广和工具的支持下，迅速成为了verifier的必备技术之一。而对于那些大公司，那些有深厚技术储备的公司，他们在验证技术的演变中一直在扮演着迁徙者的角色，即从水草贫乏之地（以前不是这样的）迁完丰饶的地方。这种迁移譬如当年的VMM到OVM、或者OVM到UVM等等。而我们今天要介绍的OVM到UVM的转化，更贴近目前的演化阶段。在OVM迁移到UVM时，不少验证组都会评估代码迁移的好处和代价，如果有更多的好处，更少的代价，那是最好的。

首先来看看，如果迁移后的好处是什么？

• 主流的仿真器都将支持重心迁移到UVM，而OVM的特性则不再主要考虑，这意味着后者最终会停止更新和支持。

• UVM的寄存器模型包现在成为了验证领域的主流，而之前OVM一侧的各个第三方的寄存器模型包不具有共通性，另外OVM在后期也本身引入了UVM的寄存器宝。

• 主流的VIP都是以UVM为主，从VIP的数量来看，UVM也逐渐占据多数，与OVM的VIP数量拉开了距离。

• 从接下来五年的验证潮流来看，目前找不到直接的竞争对手会取代UVM，这就使得在迁移后整个团队保持了与最新技术的联系。

造成OVM与UVM在2013年前后势均力敌的原因之一在于，他们在2013前后的受欢迎度是不分伯仲的。这也使得早年应用OVM的人，已经习惯了OVM，而UVM之初仅仅是迁移了OVM的所有特性并没自己什么个性的时候，这些OVM用户并没有做出要迁移到UVM的决定。然而各领风骚四五年，UVM而今已经不容置疑地统一了动态仿真界，在这一形势下，即便UVM并不会从技术上有太多突破，但在外部资源、技术更新上的考虑，越来越多的人选择了迁往UVM，或者将新的UVM VIP置入到原有的OVM环境中，做两种方法学的混合仿真（这一点我们会在下一节《OVM与UVM的混合仿真》谈到）。

那做了迁移的决定之后，我们需要考虑，什么样的方法会使得迁移的成本最小呢？

• 在迁移之前，我们需要审视现有的OVM环境代码，得出哪些方式在UVM中已经被废弃了（不建议使用）。我们应该替换掉这些废弃代码，转而使用推荐的代码方式。

• 一个合适的脚本可以帮助我们完成批量处理。

• 在脚本帮助完成转化之后，我们还需要再次完成编译和回归测试，确保转换前后的回归测试结果是一致的。

• 在转换过程中，我们应当遵守单元测试的原则，先完成从OVC到UVC的转化和测试，再完成OVM顶层转换到UVM顶层转换和测试的目标，逐级完成转换和测试。

在2013年初，Verilab公司的Litterick Mark（首席验证顾问）就推出了关于如何实现从OVM到UVM的自动化转化的论文和相关脚本。在他的论文中提出利用脚本实现从OVM到UVM转换的四个基本步骤：

• 检视原有的OVM代码，移除已经废止的用法和不建议的用法。

• 通过脚本实现从OVM到UVM的一些通用关键词的转换（批量处理）。

• 通过脚本或者手动修改的方式将OVM的编码方式修改为UVM的吧编码方式。

• 使用新的UVM的特性。

而在具体操作过程中，上面四个步骤，Litterick Mark又分别给出了四个脚本来对应，通过这些脚本，或者可以帮助检查出需要修改的地方，或者可以帮助用户直接完成替换。下面的表格中，可以看到通过脚本首先可以生成一些报告，指出代码中需要修改的部分，继而再通过后续脚本进行替换或者手动替换。关于这些脚本，读者可以在本书对应的目录中找到。

在推出这一方式之后，UVM委员会考虑并吸取了这一思想和部分脚本，经过简化之后，在目前的UVM-1.2安装包中，用户通过$UVM_HOME/bin/ovm-to-uvm10.pl完成上述步骤的第二部，即通过批量处理完成OVM关键词到UVM关键词的转换，而更多的特性用法则需要用户自己检视代码和手动修改。因此，目前UVM官方给出的转换步骤进化为了下面的方式：

• 用户需要自己检视代码（而不再是通过脚本来检视和报告）

• 通过脚本完成基本的关键词转换

• 完成从OVM phase到UVM phase的编码转换

• 抛弃原有的OVM objection方式转而使用UVM objection编码方式

• 用UVM configuration替换原有的OVM configuration方式

• 添加新的UVM特性

可以看到UVM委员会给出的转换方式舍弃了之前Litterick建议的脚本检视和后续的自动替换，而只保留了最“安全”的替换基本关键词的脚本，例如ovm_component到uvm_component的转换。而路桑通过实际的转换经验，建立读者有需要的情况下，使用“中和”的方式：

• 通过脚本完成检视，替换掉已经废止和不建议的OVM用法。

• 通过脚本完成从OVM到UVM的基本关键词转换。

• 剩余的部分考虑到需要更多的语义和结构分析，建议进行手动替换。

接下来，我们就这一建议的方式来给出大致的操作步骤，而相关的脚本读者可以在本书附赠的源代码包中找到。

OVM代码检视

这一环节中的脚本ovm_audit.pl的作用是用来检视OVM代码和生成报告：

• 指出已经被废止的OVM代码

• 指出不建议使用的代码

• 指出在OVM中有效而在UVM已经废除的代码

检视脚本的作用是用来生成报告，并不会修改代码本身。而下进行下一个步骤之前，用户应该根据检视报告来修改那些不合适的代码，在修改完之后用户可以在OVM环境中编译运行，确保修改不影响原有的功能。下面是脚本的使用范例：

audit one file:

% ovm_audit.pl file.svh

audit a set of files:

% ovm_audit.pl *.sv*

audit a whole tree of files:

% find . -name "*.sv*" | xargs -r ovm_audit.pl

这些关键词在OVM-2.1.2中已经被废止或者不建议使用：

• ovm_test_top

• ovm_top_levels

• ovm_phase_func

• post_new_ph

• export_connections_ph

• import_connections_ph

• configure_ph

• pre_run_ph

• ovm_find_component

• ovm_print_topology

• avm_

• global_reporter

• ovm_threaded_component

• do_sprint

• print_unit

• do_test

• m_do_test_mode

• do_task_phase

• set_parent_seq

• get_parent_seq

• seq_item pre_do

• seq_item body

• seq_item mid_do

• seq_item post_do

• seq_item wait_for_grant

• seq_item send_request

• seq_item wait_for_item_done

• start_sequence

• OVM_REPORT_

• ovm_seq_prod_if

• ovm_seq_cons_if

• ovm_seq_item_prod_if

• ovm_seq_item_cons_if