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

Element-Plus-X:基于Vue 3的AI交互组件库

Element-Plus-X:基于Vue 3的AI交互组件库 一、什么是Element-Plus-X? Element-Plus-X 是一个专门为AI应用场景设计的Vue 3组件库,可以理解为 “Element Plus的AI增强版”。它在保留Element Plus优雅设计体系的同时,深度整合了现代AI应用所需的各种交互组件。 核心定位:让前端开发者能够像搭建普通后台管理系统一样,快速构建复杂的AI交互界面。 二、核心特性:为什么选择Element-Plus-X? 2.1 专为AI设计的组件体系 Element-Plus-X提供了一系列开箱即用的AI交互组件: * 智能聊天组件:Bubble、BubbleList、Conversations * 多模态输入:Sender组件支持文本、语音、文件上传 * 状态展示:Thinking、ThoughtChain展示AI思考过程 * 辅助组件:Welcome、Prompts、FilesCard等 2.2 无缝的技术栈集成 // 与主流技术栈完美兼容 Vue 3+ TypeScript + Element Plus

AI生成图片R18提示词:新手入门指南与最佳实践

AI 生成图片 R18 提示词:新手入门指南与最佳实践 (2026 年视角,适用于本地 Stable Diffusion / Flux / Pony 等开源模型,或部分支持 NSFW 的在线平台) R18(成人限制级)内容在 AI 图像生成中属于高敏感领域,不同模型/平台对它的开放程度差异极大: * 完全封禁或强过滤:Midjourney、DALL·E 3/4、Flux.1 [dev/pro] 官方、Google Imagen、Adobe Firefly 等 * 部分支持但需技巧:NovelAI、Pony Diffusion、Flux Uncensored 变体、某些 SDXL LoRA 模型

AI如何帮你快速找到JXX登录网页最新域名

快速体验 1. 打开 InsCode(快马)平台 https://www.inscode.net 2. 输入框内输入如下内容: 开发一个智能域名追踪系统,能够自动检测JXX登录网页的最新域名变更。系统需要包含以下功能:1. 定时爬取JXX相关页面,检测域名变化;2. 通过DNS解析验证域名有效性;3. 发现新域名后自动通知用户;4. 提供历史域名记录查询。使用Python实现,集成requests库进行网页请求,dnspython库进行DNS解析,并添加邮件通知功能。 1. 点击'项目生成'按钮,等待项目生成完整后预览效果 AI如何帮你快速找到JXX登录网页最新域名 最近在做一个需要频繁访问JXX网站的项目,但发现这个网站的登录域名经常变更,每次都要花时间到处找最新地址,特别影响工作效率。于是研究了下如何用AI辅助开发一个智能域名追踪系统,自动帮我解决这个问题。 系统设计思路 1. 定时爬取检测:系统需要定期自动访问JXX相关页面,检查是否有新域名出现。这里用Python的requests库就能实现,设置合理的请求间隔避免被封禁。 2.

AI 驱动游戏:鸿蒙生态的机会在哪里?

AI 驱动游戏:鸿蒙生态的机会在哪里?

子玥酱(掘金 / 知乎 / ZEEKLOG / 简书 同名) 大家好,我是子玥酱,一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。 我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案, 在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。 技术方向:前端 / 跨端 / 小程序 / 移动端工程化 内容平台:掘金、知乎、ZEEKLOG、简书 创作特点:实战导向、源码拆解、少空谈多落地 文章状态:长期稳定更新,大量原创输出 我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”,而是更关注为什么这么设计、在什么场景下容易踩坑、