之前的代码跑出来的结果是有bug的，具体的情况是这样的：
wdata在复位后，写入数据是从地址01开始，而rdata则是从00开始，这样的结果是rdata读出来的第一个数值是0，对于判断结果有一定的影响。最近博主也是思考了很多为什么会出现这种情况。具体的我们上图来分析：
先看到在60ns这个时刻，我们refermodule 也就是driver可以在 这里正常检测到的，但是我们rdata检测的是0。于是参考我们的时序图来看：
我们可以观察到在60ns的时刻 恰好是一个rclk上升沿，此时rempty从1-0发生跳变。这里贴出来设计代码：
正常情况下 如果read&！rempty应该是执行了地址加1，read的数据也应该是01的数据。
在刚分析的时候我以为是设计代码的问题，在请教了同学之后，告知我应该考虑跳变沿是不是存在亚稳态。于是乎进行了分析之后，发现这里60ns执行的应该是上述代码中 read & rempty的情况，此处的跳变并没有检测到0 而是将其当成1来判断了。这样由于复位后rdata都是0，会执行保持，导致此时刻rdata出的数据就为0。
在这里解释一下为什么rempty到60ns一直保持1，是因为我写的时钟是写快读慢，对于rempty判断需要将写时钟里面的写地址cdc到rclk中，而复位后，开始写，直接跨时钟过来后，最少也得是60ns，在此之前，跨时钟过来的写地址均为0，根据判断，rempty会一直保持1，等第一个地址cdc后就开始正常。
所以总的来说，在开始读数据之前，要给一个时间让其rempty保持稳定，避免在rempty跳变时候采样。
这里我解决的话是：延迟read信号的拉高。一般来说复位后的第二个rclk才会将rempty拉低，所以我们可以根据这个时间，让read在复位后过两个rclk cyc再拉高，具体代码不放出了，比较简单，这里看最后结果：
可以看到这样结果就全部successful，也就是测试通过了~
然后我也改了一些monitor scb的判断条件 ~有需要的可以跟我要最新的代码~
最后祝各位秋招顺利。