寄存器模型中mem与reg的联系和差别

UVM寄存器模型也可以用来对存储建模。uvm_mem 类可以用来模拟RW (读写）、 RO（只读）和WO(只写）类型的存储，并且可以配置存储模型的数据宽度和地址范围。uvm_mem不同于uvm_reg 的地方在于，考虑到物理存储一旦映射到 uvm_mem 会带来更大的资源消耗，因此 uvm_mem 并不支待预测和影子存储（shadow storage) 功能， 即没有镜像值和期望值。

uvm_mem 可以提供的功能就是利用自带的方法去访问硬件存储， 相比于直接利用硬件总线 UVC进行访问，这么做的好处在于：

• 类似于寄存器模型访问寄存器，利用存储模型访问硬件存储便于维护和复用。

• 在访问过程中，可以利用模型的地址范围来测试硬件的地址范围是否全部覆盖。

• 由于 uvm_mem 也同时提供前门访问和后门访问，这使得存储测试可以考虑先通过后门访问预先加载存储内容，而后通过前门访问读取存储内容，继而做数据比对，这样做不但节省时间，同时也在测试方式上保持了一致性。同时这种方式相比于传统前后测试方式（利用系统函数或仿真器函数实现存储加载），要在UVM测试框架中更为统一。

与 uvm_reg 相比， uvm_mem不但拥有常规的访问方法read() 、 write()、peek()和 poke()，也提供了 burst_read()和 burst_write() 。之所以额外提供这两种方法， 不但是为了可以更高速地通过物理总线的BURST方式连续存储，也是为了尽可能贴合实际访问存储中的场景。要实现BURST访问形式， 需要考虑下面这些因素：

• 目前挂载的总线UVC是否支持BURST形式访问，例如APB不能支持BURST访问模式。

• 与 read()、 write()方法相比，burst_read()和 burst_write()的参数列表中的一项uvm_reg_ data _t value[]采用的是数组形式， 不再是单一变量， 即表示用户可以传递多个数据。而在后台，这些数据首先需要装载到 uvm_reg_item 对象中，装载时 value 数组可以直接写入， 另外两个成员需要分别指定为 element_kind = UVM_MEM , kind = UVM_BURST_READ。

• 在 adapter 实现中， 也需要考虑到存储模型 BURST 访问的情形， 实现4 种访问类型(uvm access e) 的转换，即UVM_READ、UVM_WRITE、UVM_BURS_READ 和UVM_BURST_ WRITE。对于 UVM_READ 和 UVM_WRITE 的桥接， 已经在寄存器模型访问中实现， 而 UVM_BURST_READ 和 UVM_BURST_WRITE的转换，往往需要考虑写入的数据长度，例如长度是否是 4、 8、 16 或其他。比如 AHB 总线， 支持连续 4 个、8 个、 16 个数据的读写 (INCR4 、 INCR8、 INCR16), 但是如果数据长度不是这些固定长度时， adapter 还需要自己处理来实现 INCR 的连续访问方式。

• 此外还需要考虑不同总线的其他控制参数， 例如 AHB 支持 WRAP 模式， AXI 支持out-of-order 模式等， 如果想要将更多的总线控制封装在 adapter 的桥接功能里， 需要将更多的配置作为扩展配置， 在调用访问方法时作为扩展信息类，传入到形式参数uvm_object_extension。待传入后， adapter 将可以在桥接方法中抽取出扩展信息类，作为更准确的协议访问的限定依据。

• 对于更为复杂的 BURST 形式， 如果需要实现更多的协议配置要求， 那么笔者推荐直接在总线 UVC 层面去驱动。这样做的灵活性更大， 且更能充分全面的测试存储接口的协议层完备性。因此， 验证师在为存储模型访问实现 adapter 方法时， 需要考虑的是， uvm_mem 层面的方法应该尽员便捷、必要的参数应该少量， 以便于使用和维护；而另一方面， 如果要首先测试存储接口协议， 则应该在总线 UVC 的层面上完成更充分的验证。