关于Xilinx 2020.1新建工程时配置MIG核的完整步骤，请参阅：https://blog.csdn.net/ZLK1214/article/details/111349678

MIG核里面有两个通道：命令通道和数据通道。这两个通道是相互独立的，互不影响。 命令通道：要发送的命令由ddr3_app_cmd指定（0号命令是写内存，1号命令是读内存），ddr3_app_en拉高就开始发送命令。 数据通道：要发送的数据由ddr3_app_wdf_data指定，ddr3_app_wdf_wren拉高就开始往FIFO里面送入数据。 MIG里面是严格一个时钟（ddr3_ui_clk）发送一个命令（或写一个数据）。ddr3_app_en如果一直拉高，那么就一直重复发送命令。拉高了多少个时钟周期，就发送多少条命令。同样，ddr3_app_wdf_wren如果一直拉高，就一直重复往FIFO里面写入数据。编写程序的时候要特别注意这一点。

如下图所示是MIG连续写DDR3内存时的时序。ILA的采样周期刚好就是ddr3_ui_clk（100MHz），横向时间单位为10ns。 从红竖线（8192时刻）开始写内存，发送写命令（ddr3_app_cmd=0且ddr3_app_en=1），写的内存地址是ddr3_app_addr=0，同时往FIFO里面送入要写的数据（ddr3_app_wdf_wren=1，wdf的全称为write data FIFO）。第8193时刻，读到ddr3_app_rdy为1说明写命令发送成功，读到ddr3_app_wdf_rdy=1说明数据成功送入FIFO。这两位同时为1表示写内存成功。 第8193时刻又发出了写8号地址的写命令，往FIFO里面塞入数据0x0008。然而，第8194时刻读到ddr3_app_rdy为0，说明写命令发送失败了！！同时读到ddr3_app_wdf_rdy为1，说明往FIFO里面送入数据成功了。这个时候就要注意了，写命令发送失败但FIFO送入数据成功，接下来写命令应该重新发送，但数据不能再往FIFO里面送了！！！也就是图中红框的部分，在第8194时刻必须把ddr3_app_wdf_wren拉低，停止送入数据，不然的话，这种情况下就会连续往FIFO里面送入三个0x0008，导致后面的地址0x0000010（16号地址），0x0000018（24号地址）都被写入0x0008这个数据！！！如果不懂的话，是非常容易犯这个错误的。 写8号地址的命令发了两次都失败了，第三次终于发送成功了，ddr3_app_rdy为1。在8196时刻可以发送新的写命令了，向FIFO里面写入新的数据。

连续读内存也是类似的。如下图所示是一种错误的做法。只要ddr3_app_en为1，就一直在发命令，ddr3_app_addr一直为0就发了一大串读0号地址的命令。

那改成发一个读命令，等到数据读出来后（ddr3_app_rd_data_valid=1），再发下一个命令，这样就能读出正确的结果，但是抓了波形图一看，中间的等待时间很长，每读一个地址都要等待很久，非常浪费时间。

于是我们可以边发命令，边接收数据。一开始就从0地址开始一直往后发命令：0,8,16,24,36,48…… 当ddr3_app_rd_data_valid=1时，我们已经发到0xb0（176）地址了，这个时候0号地址的数据才读出来，于是一个一个接收，如下图所示。

这样连续读数据就会比刚才快很多很多。值得注意的是，接收完最后一个数据后，ddr3_app_rd_data_valid会变为0，表明数据已接收完毕。

我们来看看最终的代码：

这里程序有一个失误，就是ddr3_ui_clk_sync_rst是一个同步复位信号，不应该是异步复位。代码里面写成了always @(posedge ddr3_ui_clk, posedge ddr3_ui_clk_sync_rst) begin，把ddr3_ui_clk_sync_rst用成了一个异步的复位信号，这是不对的。应该把always敏感列表里面的posedge ddr3_ui_clk_sync_rst去掉，写成always @(posedge ddr3_ui_clk) begin才对。不过笔者在实际运行时并没有发现有什么不对的地方。