tree_node和route_node在排序中经常会用到，因此如果读者需要构建图（diagram），用tree或者route模式，那么可以考虑使用这两种类和随后配套的tree和route类来构建图。

对于aggregate类集合中，按照存放数据的方式，又可以分为packed_array、unpacked_array、dynamic_array和queue、data_stream和bit_stream。下面是这些类的一些使用例码：

bit[7:0] pa; // packed array

bit ua[7:0]; // unpacked array

ua = packed_array#(bit,8)::to_unpacked_array( pa );

my_class ua[8]; // unpacked array of my_class

unpacked_array#(my_class,8)::reverse( ua );

collection类内部一般由queue或者associate array来实现，而比起SV已有的queue、associate array，它们提供更多的方法：

• set类：包含没有重复的成员。

• deque类：支持首尾双端push/pop的操作。

• tree类：实现了tree模式的数据存储结构。

• route类：按照route模式的数据存储结构。

从上面关于tree模式和route模式的结构图来看，显著的差别在于，tree模式的父节点（parent node）只有一个，而route模式的父节点可以允许有多个。所以在建立结构的时候可以根据不同的场景选用tree模式还是route模式。

策略类

对于上面的容器类在需要比较和格式化的时候，就需要用户自定义的方法或者类来实现。 comparator类用来比较两个容器对象，例如：

class pair_comparator #( type T = pair ) extends comparator #(T);

virtual function bit eq( T x, T y );

return x.first == y.first && x.second == y.second;

endfunction: eq

// ... other functions

endclass: pair_comparator

formatter类用来将容器中的对象例如长整形、枚举型或者句柄转化为字符串。例如下面的例子中，comma_formatter类将整形转化为由逗号间隔的字符串便于阅读：

comma_formatter#(longint) com_fmtr = comma_formatter#(longint)::get_instance();

$display( com_fmtr.to_string( 123456789 ) );  // 123,456,789

验证相关类

一些与随机相关的类，例如下面的类random_4_bin_num在例化之后，可以通过指定随机的范围和比重来实现随机约束，继而产生期望的数值。

random_4_bin_num n = new;

// min max wt

n.db = ’{ ’{ 100, 200, 1 }, // bin 0

’{ 300, 400, 2 }, // bin 1

’{ 500, 600, 3 }, // bin 2

’{ 700, 800, 4 } }; // bin 3

assert( n.randomize() );

$display( n.val ); // the randomized value

对象n在给定约束n.db之后，产生的随机值n.val将在100和200，300和400，500和600，700和800之间，而四个区间的比重是1、2、3和4。

另外，还提供计时器kitchen_timer。计时器的功能可以通过对仿真计时，继而用作看门狗（watch-dog timer）或者利用事件触发来处理其它事务。

领域相关类

而到了与验证具体功能领域相关的类，这恐怕是开发者总结了以往接触到的项目，继而将它们整理到了一起。目前cluelib提供了三个类：

• crc

• scramblers

• network

以crc类为例，这个类或者说类簇，包含了多个静态函数，而每一个静态函数都会根据不同的协议标准返回需要的crc值。例如crc::crc5_usb返回crc-5-usb值，crc::crc7_mvb返回crc-7-mvb值。也许这些有限的领域相关类并不是读者需要的，但这种将现有验证功能领域的函数汇总收集为一个类、放入一个完整库的思路，值得verifiers们借鉴。

也许SV标准委员会在一开始制定SV标准的时候考虑地比较多，毕竟SV的首要使用对象，即早期的verifier们都是从古老的HDL世界迁移过来的“原住民”。为了让他们更快地使用SV的特性，在底层函数制定可能做了一些妥协。例如字符串string，是一个类型同时又提供一些方法，但它又并不是一个类，这一点不同于Java的显式String类，或者Python的隐形str类。它这种尴尬的位置使得后期在string类型做扩展时遇到了不小的麻烦，而开发者们不得不转而求其次重新定义了字符串类。当然SV另外一些特性，例如内存管理、垃圾回收、对象句柄操作等使用方式又尽量简单，不对使用者造成太多困扰，这一点值得肯定。

目前SV和UVM的现状就是开源生态圈没有建立起来，尽管一些EDA厂商例如MentorGraphics在推进这件事情（Verification Academy），但与软件生态圈的丰富第三方库比起来仍然有不小的差距。一方面这与验证从业人员的数量、编码方式、职业习惯有关，另外这也与半导体行业一直较为封闭的价值观有关（好的代码也无法开源出来）。我们本节希望通过介绍上面这些有限的但有质量的开源库，读者们可以更多地浏览源代码，了解开发公共库的常需要考虑的方向、如何测试库、发布和维护库等等，在自己所在的团队、公司层面可以更多地促成这样地事情。所谓前人栽树后人乘凉，至少可以让公司在功能验证方面的资源都整合在一起、有章法可循，而通过这种方式进一步确立验证工程师属于“正规军”的形象，让公司知道它的价值不单在于设计IP资源，同时也包括完善的验证IP资源。

下一节我们将进入软件开发过程中经常使用到的标准测试概念，和已经推出的和SV相关的单元测试方法《SV单元测试方法SVUnit》。

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