Xilinx 7系列FPGA DDR3控制器——mig使用总结(几个经典问题)

本文转载自: FPGA的现今未

在DDR读写的设计中,有一些比较经典的问题,是在设计中必须考虑到的,这些问题会影响项目的整体方案或者架构,不同的场景可能会不一样,但是大同小异,总体的设计思想不变。

时钟域隔离

我们知道mig core接口信号工作的时钟是由mig core给出来的,如下图所示,整个FPGA的系统时钟,或者用用户读写DDR的时钟往往不会是这个时钟,因为这里就必然存在一个时钟域隔离的问题。即从系统时钟域转到mig core的接口时钟域(这里简称UI时钟域)。

1.JPG

在哪里完成时钟域转换呢?应该来说有2种方案。第一种方案是在仲裁模块完成时钟域转换,如下图所示,用户逻辑向仲裁模块发送读写命令和写数据后,先做时钟域转换,然后再UI时钟域完成mig core的访问,同样,mig core返回的读数据,在仲裁逻辑的出口处转换到系统时钟域后给用户。

2.JPG

第二种方案是在接口适配逻辑完成时钟域的转换,如下图所示,即仲裁逻辑和大部分的适配逻辑工作在系统时钟域,在适配逻辑最后完成接口转换的时候,同时完成时钟域的转换。

3.JPG

这2种方案本质上没有太大差别,由于是在UI时钟域的时钟频率不高的时候,如果UI时钟域的时钟频率在系统中算比较高的话,可以采用第二种方案。减少高时钟频率的范围,当然前提是要满足读写的性能需求。

如何发起读命令

设想一种场景,用户发送了N个读命令,这些读命令一共会返回Mbyte的数据,但是用户现在处理不了这么多数据,mig core又是不接受反压的,数据无法存放,想到的简单方案那就读慢一点,少发点读命令,那又可能带来一个新的问题,就是读的太少,mig返回的数据不够,影响了处理的性能。究竟如何处理呢?答案也很简单,就是用户有多大的处理能力,就读多少数据。

从DDR中读回的数据,一定会有一个地方做缓存,这个缓存可能是在用户逻辑里,也可以在仲裁逻辑里。这2种方案各有利弊。

3.JPG

不管在哪里缓存,核心的思想就是要根据缓存剩余空间的多少来决定读命令的发送。读命令能否发送,就要看当前这个命令读取的数据量x,加上还在路上将要从mig返回的数据量y,要小于缓存剩余的空间z,即x+y <= z,满足这个条件的时读命令才可能发送。如下图所示:

4.JPG

读命令发送逻辑已经发送了4个命令,其中cmd1和cmd2已经到mig core,且mig core返回了数据。分别为Y1和Y2 byte。cmd3、cmd4还在路上,分别要读取长度为Y3和Y4 byte。缓存中还剩余的空间为z byte,那cmd5能否发送呢?从图中可以看出,只要缓存收下从cmd1到cmd4所读的数据后,还有空间存放cmd5要读的数据,即可以发送cmd5,即 Z - (Y1+Y2+Y3+Y4)>= Y5。关于如何计算在途的数据量,也可以参考这里——如何计算在途数据量

5.JPG

如何确认数据真的写入DDR

从用户的角度,当一个写数据和写地址给到仲裁逻辑后,是否就可以读取该地址的数据呢?答案是不确定的,如果仲裁逻辑是先优先,那上面的问题的答案是肯定的,如果读和写的仲裁是公平轮询,那答案就不一定了。那如何确定数据是否真的写入DDR呢?

从mig的接口来看,它的读写只有一个端口,因此可以确定,只有到了mig接口的写数据,才是真正被写入DDR中,此时再读该地址的话,一定可以读到写入的数据。要确保数据已经写入DDR中,最好的办法就是给用户的写操作提供一个反馈。axi4接口本身带有写响应,但是UI接口就需要适配逻辑和仲裁逻辑增加一个写反馈接口,这个设计思路就和读数据返回给用户是一样的。即每个通道的用户的写操作送到mig core的接口后,都向该用户反回一个写完成动作,给用户逻辑足够的操作空间来根据应用场景利用这个写完成动作。

比如把DDR当成FIFO中的场景,只有收到这个写完成的动作后,才认为数据已经写入DDR中,然后才能读取,这样保证了读取的数据永远是最新的。

最新文章

最新文章