关于时钟相位差仿真和下板现象不同的一些想法

环境

AB口都是8bit数据位宽，2k深度。
Mif文件是255-0的周期数据，A口写入0-255的周期数据，B口写入255-0的周期数据。

问题描述

这两天遇到了一个问题，在使用双口RAM ip核的时候（读后写模式），仿真现象是过了的，但是下板现象却不过。


仿真在addra=2042应该读出doa=5,但是下板的时候发现doa读出了250。（手动狗头）

找了很久也没有找到bug，因为从cea写入等角度来看，都是ok的，读后写，应该先读出5再写入250，这很是让人头大。（这里的cea是笔误，代码里cea接到wea端口上的）并且可以排除B口写入的数据，因为B口写入的数据是5。

解决

把例化过程中的cea修改为cea_b（cea表示clka产生的写使能，cea_b表示clkb产生的写使能，这俩的差别仅仅是时钟相位差）。

从宏观上来看是因为自己抓的cea波形都是top模块的变量，并不是ram端口上的信号，这是不一样的！（因为自己写代码会写错）

把B口的写使能都用clkb产生的cea_b来控制，仿真波形就和下板一致了。

虽然现象一致了，but，我明明是A口读出有问题，改了B口的ceb和web怎么会影响到A口呢（让A口读出正常）？？（修改B口是可以解决另外一个问题，本篇文章里没有提到这个问题，问题是因为B口用了clka的写使能，因为相位差异导致B口有一个数没有写进去）

追溯问题源头

这个暂时还没有找到。

总结

1. 抓波形一定要抓ram模块的接口（从内部抓），因为实例化的时候，其接口可能是其他信号。
2. PLL仿真和下板产生的波形相位，（我猜测是不一致的）一是仿真能过是因为没有加布局布线的延时，并不能代表真实情况，PLL产生的相位带了布局布线的延时。二是实际下板和仿真的时钟起始位置很可能不一样。
3. 抓bug的关键点，其实很多都是经常被忽略的地方，比如实例化模块接口是否一致（这几天因为实例化出了好几个bug）。
4. 抓bug，可以先看看复位，再看看问题类型，如果是功能仿真有问题就好办了，抓关键信号的波形（如果是例化的模块一定要抓模块内部的接口），然后看看和外部产生的波形是否一致。如果是phy仿真（后仿）、上板和功能仿真不一致，这就有点难定位了（这点我也需要继续学习，如果有懂的大佬可以在后面评论喔~）
5. 关于实例化，之前遇到过一次使用位置绑定出错的情况，EDA工具在综合时把接口顺序给换掉了，导致phy仿真出错。所以尽量使用名称绑定。（不要偷懒，偷懒都会还的）
6. 不要偷懒，偷懒都会还的，copy其他代码但是又忽略了一些东西，结果就是仿真出错。
7. 多开TD工具的时候，每次下载，一定要确认下载的bits是不是当前工程的。默认打开的bit是之前下载过的（其他工程的），建议先删除bit重新添加。