|
基于Xilinx MIS IP的DDR3读写User Interface解析 特权同学，版权所有，转载请注明出处 参考文档：ug586_7Series_MIS.pdf 1. Command时序 首先，关于User Interface的Command时序，ug中只给出以下波形。简单的来讲，app_cmd和app_addr有效，且app_en拉高，app_rdy拉高，则该命令成功发送给DDR3 Controller IP；若是在app_cmd、app_addr和app_en都有效时，app_rdy为低，那么必须保持app_cmd、app_addr和app_en的有效状态直到app_rdy拉高，那么该命令才算是成功发送给DDR3 Controller IP。 找一个实例来看，如图所示，在app_en连续拉高发起多次写入命令时，第58个时钟周期，遇到了app_rdy拉低的情况，此时需要保持当前的app_cmd和app_addr不变，app_en也继续为高，直到第59个时钟周期，app_rdy拉高了，那么说明该写命令成功。 2. 数据写入时序 对于单次的数据写入DDR3 Controller IP，ug中也只给出如图所示的时序波形。这里对应写入command发起的前后有1、2和3不同时间的Data Write时序，也就是说，对应这个写入command，数据比command早一点或晚一点写入都是可以的。 怎么理解“数据比command早一点或晚一点写入都是可以的”这句话？ug有提到，command以及data都有各自的FIFO，因此他们是需要同步的，换句话说，如果让我设计这个controller的User Interface，并且和目前的机制一样，command和data都有FIFO，那么很简单，我会根据command FIFO中的新命令，对应取一个data FIFO中的写入数据，也不用管它们谁先被送到各自的FIFO中。当然了，command FIFO有命令是data FIFO取数据的先决条件。至于两个FIFO万一不同步，那么怎么办？没办法，用户必须保证它们同步。事实就是这么残酷，特权同学在这里吃尽苦头，总算是搞明白了，必须mark一下。 前面说command时关注接口app_cmd、app_addr、app_en和app_rdy，这里写数据则需要关注接口app_wdf_data、app_wdf_wren、app_wdf_end和app_wdf_rdy。 先说app_wdf_end，DDR3实际读写的Burst =8，举例来说，DDR3的数据位宽为16bit，Burst为8，就是说每次对DDR3执行读写，必须是连续的8*16bit数据。那么在User Interface这端，如果逻辑时钟为DDR3时钟的4分频，且数据位宽为128bit，那么单个时钟周期就对应Burst=8的一次读写操作；而如果数据位宽为64bit，那么必须执行2次数据操作才能够完成一次Burst=8的读写。对于前者，app_wdf_end始终为1就可以了；而对于后者，app_wdf_end每2个写数据时钟周期内，前一次拉低，后一次拉高。 余下3个信号app_wdf_data、app_wdf_wren和app_wdf_rdy，他们的工作原理和command时序类似。app_wdf_data有效，且app_wdf_wren拉高，必须app_wdf_rdy也为高，才表示当前数据写入DDR3 Controller IP。 来看个实例，如图所示，app_wdf_en一直拉高进行数据写入。第158个时钟周期，app_wdf_rdy拉低连续5个时钟周期，此时即便app_wdf_en一直拉高也无法完成数据写入，app_wdf_data必须一直hold直到第163个时钟周期app_wdf_rdy拉高。 必须提醒的是，执行写数据command和执行写数据操作，它们是一一对应的，虽然控制时序可以分开实现。 3. 读数据时序 理解了写时序，读时序也就很容易领会了，它们本质上是一样的。每个数据的读操作，也需要先有读command的发起，当有效读command发起后，若干个时钟周期后，app_rd_data_valid拉高，此时app_rd_data有效，用户逻辑据此读出数据即可，非常简单。对于连续读取也是一样的。User Interface可以哗哗送一大堆读command，注意这些读command必须都是有效command，随后就等着app_rd_data_valid拉高接收app_rd_data即可。 也看看实际操作，如图所示，发起数据读操作后，大约经过30个时钟周期后，数据才连续出现。数据是pipeline方式出现的，所以尽可能连续的读取数据可以大大提高数据吞吐量。
| 
楼主
标题置顶
标题高亮
