svt_mem的使用

缘由

开始写这个东西的原因倒是很简单，是因为临时帮人搭建一个小的验证环境AXI写需要加上check，由于没有现成的mem检查，我就直接拿了s家的svt_mem这个玩意来做golden，s家的很多东西加密的，而且文档看着很头疼，于是仔细研究了一下这个玩意。

问题

小小的说一下我遇到的几个小问题：
1: svt_mem的不对齐读写操作
2:正常的AXI写一直报monitor error，比如 data is stable when vaild is high，又或者wlast is stable when valid is high
3：做数据比较时考虑了uvm_comparer，但是由于不熟悉这个class，在稍微做了尝试之后，zebu和soc又比较急，因此挑选了简单的比较方式。

解决

1：如果地址不对齐的话，直接调用svt_mem.write是无法写进想要的数据的，因为实际上write是操作一个位宽较大的数据，通过wstrob来控制数据的写入，读数据类似，因此我封装了一个task来做此事，外面调用还是任意地址访问，哈哈！代码可以参考如下，为啥用interface可以往上一篇文章看看。

// Without note
interface get_axi_slave_if();
        svt_mem axi_mem;
	bit [127:0] rdata2,wdata2;
        task axi_slv_write_byte(bit[31:0] addr,bit[7:0] write_byte);
		wdata2 = write_byte << ((addr-((addr>>4)<<4))*8);
		void'(axi_mem.write(((addr>>4)<<4),wdata2,1 << (addr-((addr>>4)<<4))));
        endtask

        task axi_slv_read_byte(bit[31:0] addr,output bit[7:0] read_byte);
                rdata2 = axi_mem.read(((addr>>4)<<4));
		read_byte = rdata2[(addr-((addr>>4)<<4))*8+:8];
        endtask
endinterface

2：那些乱七八糟的monitor error，着实折腾了我一天，比如data不稳定，我开始认为是我提供的wready delay过大,导致其出现问题，又发现wready_delay最小好像就是3还是4，没法一直拉高，后面经过讨论，我把输入的valid随机拉低，然后再将数据握手initialize到golden_mem中，最后做数据check。wlast的问题是由于wdata没有伴随最后一个数据的到来升起，而是跟着最后一次握手而升起，我开始认为没有问题，后面想想也不太对，于是将RTL的wlast进行了修改，订正了该报错。

有感而发

至于为什么诞生了这一篇文章，哈哈哈，纯粹是因为我的svn up一直在up代码，然后zebu的仿真也正在跑，而上周把svt_mem搞熟悉了，还是有点小收获的。不管是小环境还是soc或者emulation，我还是得重视起来，绝对不要觉得low就不重视；再就是年年被倒挂，只怪自己没实力(嘘！)。