文章来源：FPGA的现今未
在实际的DDR使用场景中，一般有如下2种场景，一个是把ddr当成一个大fifo，用户不用关心写入的地址是多少，一种是把ddr当成一个ram，用户需要自己管理读写地址，无论是上述哪种场景，都存在多个用户同时访问DDR的情况。当时mig core只有一个接口，因此在用户和mig core之间就存在一个仲裁和适配的逻辑，来帮助用户完成对DDR的读写。
因此一个比较通用的读写框图就如下图所示：
用户仲裁模块对用户的读写请求进行仲裁，一读一写为2个请求，如果支持N个用户的读写，那请求数就是2N。接口适配完成用户请求时序到mig时序的转换。
读写仲裁
读写仲裁的方式有很多种，在不同的场景中仲裁的方式也是不一样的。比如
（1）、DDR中存放的是表项，一组读写接口，由CPU完成读写操作，N个读接口，由内部逻辑执行读操作，即表项目的查询，为了让用户逻辑尽快查到最新的表项，这里可以是写操作优先，即写操作比所有的读操作优先级高，读操作之间采用公平轮询；
（2）、在网络通信中，用DDR来缓存网口输入的报文，在这种场景下DDR被当成一个大的FIFO，当DDR的读写性能满足网络报文一写一读的要求时，可以采用写优先，也可以采用读写之间公平轮询。
（3）、在视频场景，使用DDR缓存2路视频数据，每一路都是一读一写，由于视频数据的特点，它没有突发。所有端口的性能、包括瞬时的性能都是一样的，因此最好的方案是所有的读写端口都采用公平轮询的方案。
写通道存放的是写数据和写命令，通常会用fifo来做一个缓存，首先对写通道进行调度。读通道存放的是读命令和返回的数据（也可能没有缓存数据），读命令也单独的进行调度。读写调度的结果根据应用的场景再做一次调度，实现读写的仲裁。
接口适配
你xilinx的mig core有3种接口，一种是native interface，一种是axi4 slave interface，还有就是user interface。常用的是axi4和user interface这两种接口。适配逻辑就是完成用户侧接口到mig core接口的转换。在用户侧，对于读写的命令，一般主要包括2个内容，读写的起始地址和长度。因此适配逻辑需要做一个转换，将地址地址和长度的命令转换成mig core的接口。
对于axi4接口而言，如果用户访问的时候都采用axi4接口，那就不需要这种适配了，这种场景一般在用BD设计的方案中，比如FPGA内部有一个软核访问DDR，一般都采用axi4接口，这样直接相连即可，无需适配。我们这里讨论第二种情况，即用user interface（UI）的场景。毕竟在模块的内部的RTL设计中，为了简单，命令接口采用的可能都是起始地址+长度的模式。模块框图如下所示：
mig core的UI接口，是一种私有接口，数据和命令分开，反压采用ready信号，有一点类似axi_stream接口。官方给出的接口时序如下所示：
从图中可以看到app_cmd和app_addr只有在app_en和app_rdy同时有效的时候才算发送成功。通过实际测试发现，app_rdy每接收4个左右的命令后就会拉低。
数据接口的时序如下图所示，数据只有在app_wdf_rdy和app_wdf_wren同时有效的时候，app_wdf_data才会被写入到mig中。
在读写的过程中有2个问题需要注意：
（1）、数据和命令采用不同的接口，在设计上带来了一个难点，那就是数据和命令的关系，上图中提到了3种关系，这里推荐采用第1种方案，即只有在app_rdy和app_wdf_rdy同时有效的时候发送数据和命令。但是经过实际测试，app_wdf_rdy就没有拉低过（也可能是测试的场景太少吧）。
（2）、地址的变化，UI接口的时序在ug586里只是描述了一拍数据，数据连续写入的时序如下图所示，这里假定app_wdf_rdy和app_rdy都没有拉低，接口时钟和IO时钟比为1:4。
比如有数据要从地址0开始写入，那么在数据写入的过程中，app_addr需要用户自己累加，因为在K7系列中，mig core的burst length默认是等于8的。所以没拍数据写入的时候地址要累加8。
