FPGA读写DDR4 (一)MIG IP核控制信号

FPGA读写DDR4 (一)MIG IP核控制信号

前言

        这几个星期在倒腾DDR4内存的读写控制,期间看了不少资料,这几天终于完工了于是想着把做过的内容总结一下,于是有了这篇文章,由于控制DDR4的内容很多,这一篇文章就只讲基础的,也就是DDR4的控制IP核 MIG的控制信号。

        主要参考内容:【正点原子】MPSoC-P4之FPGA开发指南_V2.0,[XILINX] pg150-ultrascale-memory-ip-en-us-1.4

MIG IP核控制信号

IP核创建界面

        MIG IP核(memory interface generator)是用户与DDR4进行沟通的桥梁,因为如果我们自己去写直接DDR4代码的话,其内容将会非常复杂,而且即便写出来其性能可能也不会好,以XILINX提供的MIG IP核为例,在综合布线后查看utilization,能发现MIG IP核足足使用了约7500个LUT和9000个register资源,足以看出其编写的复杂,不过对于我们普通用户,能够操作MIG提供的用户接口就我觉得就算差不多了,既然要使用IP核,我们就从IP核的创建界面开始说起,这部分正点原子的教程中解释的很清楚,我偷懒贴一下他们的说明:

        这里我要额外解释一个很重要的概念,也就是memory option中的Burst Length这个参数在上图所示的这块DDR4芯片中,其固定了Burst Length=8,我们知道DDR4是速度快且容量高的ram,但它与我们平时在FPGA中常用的RAM有个很大的不同点,当我们给定了地址ADDR,并启动传输后DDR4内存会同时将Burst Length*Data Width大小的数据一起传送到数据总线上,其真正传输了数据的地址范围也就是ADDR~ADDR+Burst Length-1这个范围,以图中的参数为例,假设我们给出了地址ADDR=0,并给出读数据指令,在隔一段时间后,就会在8*16=128位的数据总线上得到0~7这些地址单元上的数据,所以我们无论进行写操作还是读操作,假设我们都是进行顺序读写,那每次我们给控制器的地址都是以8为步进的,这点在我们后面的程序编写中很重要。

IP核控制信号

       接下来我们开始正式看MIG的控制信号以及相关时序,PG150中给出了用户接口的所有控制信号,如下图:

        图中标黄的信号就是我们主要要关注的,我们可以大致分为四类,全局接口,命令接口,写接口,读接口,我们先从全局接口说起:

全局接口

        三个全局接口分别代表着MIG给用户使用的用户时钟,校准完成指示,以及与用户时钟同步的复位信号,这里要注意我们所有的操作用户接口的逻辑都必须等到校准完成信号拉高后才能进行。

命令接口

        第二类接口是命令接口

        命令接口用来指示DDR能够接受读取或者写入命令以及对应的命令类型的一组接口,简单来说,假设我们要读取或者写入一组数据,我们首先要给命令接口发送命令,以读命令为例,首先我们要将app_cmd设为3'b001,然后等待app_rdy信号拉高,其拉高表示DDR能够接受读写命令,然后我们拉高app_en并同时给出要读的地址app_addr,则在若干个周期后,数据就会连同数据有效信号一起出现。由于app_cmd指示不同的命令类型,我们首先给出其不同值代表的命令:

        一次成功的命令传输时序如下图所示:

        这个图大家千万不要被app_en拉高了三个周期而迷惑,实际上只有三个周期的最后一个周期命令才被写入到IP核,因为此时app_rdy才被拉高。另外,图中的app_autoprecharge信号被一同拉高可能会让大家感到迷惑,实际上我们使用IP时可能根本不会操作这一信号,因为我们在IP核中要额外设置才能使用app_autoprecharge这一信号,这一信号以我的理解是用来在同一bank中进行读写时为了提高读写效率而使能的,其用途与DDR颗粒的结构有关,如果还是感到疑惑可以查看这篇描述DDR结构的文章:https://zhuanlan.zhihu.com/p/663697786

写接口

        第三类接口是写接口

       app_wdf_data也就是写数据总线,不多解释。app_wdf_rdy信号其实就是写操作的app_rdy信号,对于一次写操作来说,只有当app_rdy和app_wdf_rdy同时为高时,写命令才能有效。app_wdf_wren拉高表示当前数据总线上数据就是要写入的数据,具体用法等会看时序就知道了。app_wdf_mask信号是写数据的屏蔽位,所谓屏蔽就是被写入为1的那个字节将不会被写入到DDR中,举例来说,对于位宽16,burst length8的ddr,一次传输为16*8=128=16字节,其mask以字节为单位屏蔽,则mask大小为16bit。app_wdf_end这个信号比较抽象,它表示的是当前时钟周期是写入数据的最后一周期,而对于我们之前一直举例的ddr,其用户时钟与DDR时钟分频比为1:4,其实就代表着每个用户时钟周期都会进行一次完整的Burst传输,则app_wdf_end实际上和app_wdf_wren是一起拉高的,(假设分频比为2:1,则数据总线宽度将会减半,一次Burst传输需要用户时钟的两个周期,这个是我的理解,不一定正确),我们实际应用时将其与app_wdf_wren连到一起即可。接下来我们看写数据的两种时序:

        第一种时序被称为非背靠背或者单次写入的时序,这个时序比较的抽象,其描述的是我们给出写命令的前一个到后两个周期在给出写控制信号以及数据,这些数据也能够被写入DDR,这种操作说实话应该是不太常用到的,但是我们还是要关注到,app_wdf_wren和app_wdf_en一同拉高时,该周期数据总线上的数据才是会被写入的数据,而app_en被拉高的那个周期地址和控制命令才会被写入,这点一定注意。

        第二种时序被称为背靠背写入时序,实际上其与非背靠背写入除了连续性上只有一个不同点,app_en信号和app_wdf_wren以及app_wdf_end信号是对其的,这是个非常好理解的时序,而且也比较好编写,我们只要将这些信号在app_rdy以及app_wdf_rdy为高时一起拉高即可实现写入。

读接口

        第四类接口是读接口:

        读接口就没什么好说的了,读数据没有额外的控制接口,只需要操作前面提到的命令接口就能够实现读数据,这里要额外说每一句DDR读数据会有很大的延迟,在给出读指令后,需要很多个时钟周期数据和数据有效标识才会出现,当然还要注意data_vaild会和有效的读出数据一起出现,和我们平时操作ram或者fifo一样。两种读操作时序如下图所示:

        实际上,除了这四组接口,还有一些额外的用户接口没有被使用,例如像PG150的130也就描述了另外一部分_ref或者_req信号的其他操作,由于我也没用上就不说了,可能还要多注意的就是app_hi_pri这个信号,PG150中没有详细描述,只是说要保留且置为0:

总结

        看我上面这些时序,其实我们能够发现MIG的操作时序并不复杂,但是在我们进行代码编写时注意点可能就比较多了,而且我们还要注意到,整个MIG IP核其用户逻辑工作在一个很高的时钟下,以我的DDR IP核配置为例,DDR工作时钟1200Mhz,用户时钟300Mhz,假设我要对一个100Msps,采样位数16bit的ADC进行数据采集并存入DDR,很显然,FIFO在这其中是必不可少的。而为了实现这种跨时钟域的数据传输,其中对于FIFO的复杂操作才是我们将遇到的最大困难,我们下一期将DDR读取操作与读写FIFO的设计。

Read more

一文讲清楚RAG 四大模式:Naive RAG、Advanced RAG、Modular RAG 与 Agentic RAG

一文讲清楚RAG 四大模式:Naive RAG、Advanced RAG、Modular RAG 与 Agentic RAG

随着技术迭代,RAG 已从最初的简单架构发展出多种进阶形态。本文将系统解析 RAG 的四大主流模式 ——Naive RAG、Advanced RAG、Modular RAG 与 Agentic RAG,从工作原理、技术特点到适用场景进行全方位对比,为技术选型提供参考。 一、RAG 基础:检索增强生成的核心逻辑 在深入模式解析前,需先明确 RAG 的核心逻辑。简单来说,RAG 由检索(Retrieval) 与生成(Generation) 两大模块构成: 检索模块:从预设知识库中精准定位与用户问题相关的信息片段(如文档、段落、句子); 生成模块:基于检索到的信息,结合大语言模型生成符合上下文、逻辑连贯的答案。 这种 “先检索再生成” 的模式,既保留了 LLM 的语言理解与生成能力,又通过外部知识的引入弥补了模型训练数据过时、事实准确性不足的缺陷。

win11本地部署openclaw实操第2集-让小龙虾具有telegram机器人能力和搜索网站能力

win11本地部署openclaw实操第2集-让小龙虾具有telegram机器人能力和搜索网站能力

1 按照第一集的部署完成后,我们就开始考虑给小龙虾增加telegram机器人和搜索网站能力,实现效果如下: 2 telegram机器人能力部署 C:\Users\Administrator.openclaw的配置文件openclaw.json 增加一段内容 "channels":{"telegram":{"enabled": true, "dmPolicy":"pairing", "botToken":"你的telegram机器人的token", "groupPolicy":"allowlist", "streamMode":"partial", "network":{"

FPGA开发必看:Vivado IP核调用操作指南

FPGA高效开发实战:Vivado IP核调用全解析 你有没有遇到过这样的场景? 项目进度紧张,系统需要实现DDR3缓存、多路时钟分发和高速数据流控,但手写HDL代码从头搭建这些模块不仅耗时,还容易出错。调试几天后发现,问题竟然出在一个看似简单的异步FIFO亚稳态处理上。 这正是 Vivado IP核 存在的意义——它不是锦上添花的工具,而是现代FPGA开发中不可或缺的“工程加速器”。作为Xilinx(现AMD)官方提供的预验证功能模块,IP核让开发者能像搭积木一样快速构建复杂系统,把精力真正集中在核心算法与架构创新上。 本文将带你 深入Vivado IP核的实际应用全流程 ,不讲空泛概念,只聚焦真实项目中你会用到的关键操作、配置技巧和避坑指南。我们将以几个高频使用的IP为例,从添加、配置、连接到调试,一步步还原一个工程师在实际开发中的完整工作流。 为什么非要用IP核?一次对比胜过千言万语 我们先来看一组真实项目的开发数据对比: 模块类型 手动编码(估计工时) 使用Vivado IP核(实际耗时) 时钟管理单元 8~12小时 15分钟(图形化配置 + 自动生成) 异步

【GitHub项目推荐--AI-Goofish-Monitor:闲鱼智能监控机器人完全指南】

简介 AI-Goofish-Monitor 是一个基于 Playwright 和 AI 技术的闲鱼(Goofish)多任务实时监控与智能分析工具。该项目由 dingyufei615 开发,通过先进的浏览器自动化技术和多模态大语言模型,为用户提供智能化的闲鱼商品监控解决方案。该工具不仅具备强大的数据采集能力,还配备了功能完善的 Web 管理界面,让用户能够轻松管理和配置监控任务。 🔗 GitHub地址 : https://github.com/dingyufei615/ai-goofish-monitor ⚡ 核心价值 : AI智能分析 · 多任务监控 · 实时通知 · Web管理界面 技术特色 : * AI驱动 :集成多模态大语言模型(GPT-4o、Gemini等),深度分析商品信息 * Web管理 :完整的可视化界面,无需命令行操作 * 多平台通知 :支持 ntfy.sh、企业微信、Bark 等多种通知方式 * 智能过滤 :基于自然语言的任务创建和AI分析标准生成 * 云原生支持 :提供