wangyingwei的个人空间 https://blog.eetop.cn/499631 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

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

热度 1已有 288 次阅读| 2022-12-27 16:02 |个人分类:DDR4 CTRL 系统芯片设计全流程记录-----从 ...|系统分类:芯片设计| DDR, CTRL, 时延, 写后读

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

 

写后读问题

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

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

l  业务模块自己保证写读执行顺序,即具体DDR CTRL在接收到写请求后在请求数据真正写入DDR外设后给出确认的响应信号(可以使用AXI总线的写RESP信号),业务模块接收到真正写入的确认信号后,再发出相应的读请求。

l  DDR CTRL保证写、读执行顺序,客户接口需要记录相应请求地址,相同地址(例如BANK)的请求读写执行顺序不能被调度改变。

l  客户接口前面增加写后读模块,类似于CACHE的结构,相同地址的写后读可以直接从CACHE中返回不存入DDR,对于查表类读请求效果较好


1

点赞

刚表态过的朋友 (1 人)

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 3

    粉丝
  • 0

    好友
  • 3

    获赞
  • 0

    评论
  • 261

    访问数
关闭

站长推荐 上一条 /1 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-3-29 21:55 , Processed in 0.022864 second(s), 15 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部