日志

UVM世界观篇之十三（终）：宏的优劣探讨

已有 5061 次阅读| 2017-6-12 00:44 |个人分类:验证系统思想|系统分类:芯片设计

对于UVM的初级用户而言，学习UVM的困难之一就是种类繁多的宏（macro）。宏对于软件开发而言，使得重复编码的部分变得简洁，易于阅读，但同时宏也隐藏了更多的细节。实际上隐藏的这些细节对于理解UVM在每个环节的机制都有帮助，而宏对于UVM的小白而言，在度过了初级“临摹”的时候，就变得不那么“友好”了。因为这些隐藏的细节，是阻碍用户升级到高级用户的一个障碍，譬如用户不能很好地脱离宏而灵活使用底层的函数，或者在断点调试的时候一些仿真器也不能支持在展开宏在里面的语句中设置断点。所以，尽管UVM宏的长处明显直接，便于初学者，但固定的形式也不利于用户的灵活使用。在本文中，也会对UVM以及OVM宏的隐藏开销进行说明，从这些隐藏的开销可以得出本文的建议，哪些宏可以使用，哪些宏不建议使用。

性价比分析

`uvm_*_utils

应该使用。

这些配对的宏用来将类注册到factory中，定义create()方法。由于类型的注册必须准确，而这些宏代码简短、易于分析，也难以出错，所以这些宏是很方便的方法，应该使用。

`uvm_info | warning | error | fatal

应该使用。

与uvm_report_*函数相比，这些宏最大的一个便利就是在选择处理字符串之前，先判断其verbosity是否可以过滤，如果可以过滤则不会调用umv_report_*函数，这就节省了一笔字符串处理的资源。因此推荐使用该宏。

`uvm_*_imp_decl

可以使用。

这些宏定义了一些特殊的imp类型端口，使得组件可以定义多个TLM接口和内置多个TLM处理方法。比起自己定义参数化的类和方法，还是使用该宏的方法简易。

`uvm_do_*

可以避免。

`uvm_do_*由多个内置的宏进一步构成，这些宏的存在是为了通用语sequence或者sequence item。如果用户自己选择不使用`uvm_do_*的话，那么就需要考虑针对于sequence或者sequence item而采取不同的方法，但是使用底层方法可以减少底层的开支。下面的两种方法分别通过宏和底层函数来发送sequence和sequence item。

virtual task parent_seq::body();

  my_item item;

  my_subseq seq;

  ‘uvm_do(item) <-- what do these do?

  ‘uvm_do(seq) <-- side effects? are you sure?

endtask

----------------------

task parent_seq::do_item(ovm_sequence_item item,...);

  start_item(item);

  randomize(item) [with { ... }];

  finish_item(item);

endtask

virtual task parent_seq::body();

  my_item item = my_item::type_id::create("item",,get_full_name());

  my_seq seq = my_seq::type_id::create("seq",,get_full_name());

  do_item(item);

  seq.start();

endtask

`uvm_sequence macros

不应使用。

从OVM时代迁移过来的sequence/sequencer相关的宏在UVM-1.1中已经进入了废止列表，用户已经不需要沿用下面这些宏来构建sequence library。这些已经废止的宏包括但不限于：

`uvm_sequence_utils
`uvm_update_sequence_lib
`uvm_sequencer_utils
`uvm_declare_sequence_lib
`uvm_declare_p_sequencer

如果要注册uvm_sequence，可以使用`uvm_object_utils来替换；如果要注册uvm_sequencer，可以使用`uvm_component_utils来替换。

`uvm_field_*

可以使用。

在之前介绍的《核心基类》中可以得知，uvm_object类提供的众多简便方法例如拷贝、打印、比较等等都与field automation有关。而要使能field automation，`uvm_field_*相关的宏是必不可少的。然而，这些宏恐怕是对于资源开销最多的宏之一了。关于这些相关宏展开以后的行数比较表如下：

在使用这些宏来完成field automation时，首先需要替换为众多实际的底层函数来实现，这已经是一次开销了。而在实际运行中，如果再做更多的拷贝、打印、比较等操作，那么后台要额外消耗的资源会更多。幸运的一点是，与OVM的宏相比，UVM宏在性能上已经明显提升很多，几乎可以替代人为的地层实现。下面的比较分别是关于OVM以及UVM的宏需要调用的函数和人为调用函数的对比：
从中可以看到的是：
UVM的宏与OVM相比，已经有显著的性能提升。
对于拷贝、比较、打印和打包而言，可以使用预定义函数copy()、compare()、sprint()、pack()/unpack()函数。
对于记录而言，仍然建议用户自己定义回调函数do_record()，取得更好的效果。

同时，`uvm_field_*宏也存在一些限制：
无法支持一些类型，例如为从uvm_object继承的对象、unpacked结构体、事件和枚举类型的关联数组、多维数组等等。
调试困难。预定义的copy()、compare()等函数会完成处理，但是用户如果深入内部探究处理为什么失败，那么大量的内置方法嵌套和行数会让人苦不堪言。与相应的回调函数相比do_copy()和do_compare()用户自己定义相比，回调函数的调试会容易得多。
整形变量不能超过`UVM_MAX_STREAMBITS（4096）。修改这个宏会影响整体的运行效率。
uvm_packer打包之后的整体大小不能超过`UVM_MAX_PACKED_BITS。修改这一全局的宏，也会影响整体的运行效率。

从OVM过渡到UVM，一些常规的宏已经经过了优化，而且从实验结果来看，性能也确实得到了提升。通过上面对于这些常规宏的介绍和性能分析，读者可以清楚地知道哪些宏应该使用、哪些应该避免。

至此，可谓奇幻的UVM世界观光已经完毕，相信游客们从中领会到一些UVM的魅力。而从下一篇《UVM结构篇》开始，将为读者们对于常见的UVM环境中的类以及它们的特性做出一一介绍，待该篇的尾部也给出之前SV篇章中的待测设计MCDF的UVM验证结构方案。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。