项目DDR需求整理---时延要求及写后读问题

       部分的芯片项目中缓存系统会对DDR CTRL有时延要求，具体分为读、写两种请求延时，即缓存请求被存入到DDRCTRL接口后，其中数据多久可以被真正写入DDR？读请求被DDR CTRL接口接收后，多久可以返回读数据？对于查表类的业务，读请求延迟通常需要非常短，若想实现这个需要在业务调度中对于该类请求进行特殊调度（降低带宽）。

写后读问题：

排除使用CACHE等功能外，请求的存取时间肯定越短整体系统性能越高，但实际DDR CTRL系统中请求需要因为保证带宽而进行一定的业务执行顺序的调度，这样会造成写入请求不能第一时间将数据存入DDR，这时候若读请求业务距离写请求间隔太短，就会造成后面的读请求调度到写请求前面执行，实际造成写后读的错误。

为了保证不出现上面的写后读问题，通常有三种解决方案：

1. 业务模块自己保证写读执行顺序，即具体DDR CTRL在接收到写请求后在请求数据真正写入DDR外设后给出确认的响应信号（可以使用AXI总线的写RESP信号），业务模块接收到真正写入的确认信号后，再发出相应的读请求。
2. DDR CTRL保证写、读执行顺序，客户接口需要记录相应请求地址，相同地址（例如BANK）的请求读写执行顺序不能被调度改变。
3. 客户接口前面增加写后读模块，类似于CACHE的结构，相同地址的写后读可以直接从CACHE中返回不存入DDR，对于查表类读请求效果较好