热度 1| |||
部分的芯片项目中缓存系统会对DDR CTRL有时延要求,具体分为读、写两种请求延时,即缓存请求被存入到DDRCTRL接口后,其中数据多久可以被真正写入DDR?读请求被DDR CTRL接口接收后,多久可以返回读数据?对于查表类的业务,读请求延迟通常需要非常短,若想实现这个需要在业务调度中对于该类请求进行特殊调度(降低带宽)。
写后读问题:
排除使用CACHE等功能外,请求的存取时间肯定越短整体系统性能越高,但实际DDR CTRL系统中请求需要因为保证带宽而进行一定的业务执行顺序的调度,这样会造成写入请求不能第一时间将数据存入DDR,这时候若读请求业务距离写请求间隔太短,就会造成后面的读请求调度到写请求前面执行,实际造成写后读的错误。
为了保证不出现上面的写后读问题,通常有三种解决方案:
l 业务模块自己保证写读执行顺序,即具体DDR CTRL在接收到写请求后在请求数据真正写入DDR外设后给出确认的响应信号(可以使用AXI总线的写RESP信号),业务模块接收到真正写入的确认信号后,再发出相应的读请求。
l DDR CTRL保证写、读执行顺序,客户接口需要记录相应请求地址,相同地址(例如BANK)的请求读写执行顺序不能被调度改变。
l 客户接口前面增加写后读模块,类似于CACHE的结构,相同地址的写后读可以直接从CACHE中返回不存入DDR,对于查表类读请求效果较好