为什么要用类来做UVM的通信事务？

​rockeric.com

还有两个月就又到年底了，按照往常是要做年终总结的，可从今年路桑发表的文章来看，数量远远没有达到年初计划，反倒是自己在催周围的同事朋友们多给明年的DVCon中国大会投论文。索性在接下来几周多补一补今年的作业吧，写一写浓妆淡抹总相宜的短篇。

 

如果你知道UVM，也还知道UVM通信的标准，那你有没有考虑过，TLM通信的对象为什么是类？——除了类，我们还有什么可以用来通信的可能？先说最直观的吧，为什么不可以是结构体呢？

 

为什么transaction不可以是结构体呢？

• class和struct都可以包含数据

• class可以对数据做封装，struct不可以

• class可以对父类做继承，添加新的成员，struct要添加新的变量只能文本拷贝

• class可以内置成员方法对成员变量做操作，struct不可以

• transaction需要随机化和约束，这是类的专长，struct不可以

• 可以使用对象内建的randomize()函数随机化对象中的随机变量，而struct无法轻松办到这一点（不是不可以）

• class本身也是naming space，它也可以在自己的body中定义一些类型，而struct不是naming space，由于这一特性class中也可以定义静态变量和方法，struct不可以

• 在UVM中，考虑到环境的复用性，如果要对transaction添加成员或者修改constraint，合理的做法是扩展子类从顶层利用factory做类型覆盖（override），这首先需要transaction类可以实现注册，而struct无法注册，也自然享受不到这个待遇

• 在UVM组件的通信中，initiator与target的通信实际上是同一个数据实体，可以实现对同一个数据对象的共享，所以class是合适的，如果修改为struct，那么则发生的是数据拷贝，两端实际上是不同的数据对象。

 

那么是不是小白以后在UVM中都只使用class，而不需要使用struct，将它束之高阁呢？我们这里再发散一下几个话题吧，我们稍后一一来探讨：

• struct与class相比就有一些短板，那么谁还可能做transaction呢？

• 怎么样在合适的场景选择合适的类型和代码方式？