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

【STM32项目开源】基于STM32的智能家居环境监测系统

【STM32项目开源】基于STM32的智能家居环境监测系统

目录 一、设计背景和意义 1.1设计背景 1.2设计意义 二、实物效果展示 2.1实物图片 2.2实物演示视频 三、硬件功能简介 3.1项目功能详解 3.2元器件清单 四、主框图与软件流程图 五、硬件PCB展示 六、软件程序设计 七、项目资料包内容          资料获取:查看主页介绍“充哥单片机设计” 一、设计背景和意义 1.1设计背景         随着物联网(IoT)、嵌入式系统和云计算等技术的飞速发展,智能家居系统正在逐渐改变人们的生活方式。智能家居不仅仅是简单的远程开关控制,而是向着环境感知、自主判断、智能决策的方向不断演进。特别是在城市化进程加快、生活节奏加快的背景下,用户对生活便捷性、家庭安全性和环境舒适度的要求不断提高,这对智能家居系统的综合感知、智能响应能力提出了更高的要求。         当前市面上的智能家居产品多以分立模块存在,系统功能较为单一,

【前端异常】JavaScript错误处理:分析 Uncaught (in promise) error

在前端开发中,JavaScript 异常是不可避免的。随着现代前端应用越来越多地使用异步操作(如 Promise、async/await 等),开发者常常会遇到 Uncaught (in promise) error 错误。这个错误是由于未正确处理 Promise 的拒绝(rejection)而导致的,常常出现在异步操作失败的情况下。如果不妥善处理,可能会导致应用的不稳定和用户体验的下降。 本文将深入分析 Uncaught (in promise) error 错误的原因,如何有效捕获和处理这些异常,并通过实际案例和代码展示具体的解决方案。 一、Uncaught (in promise) 错误的成因 在 JavaScript 中,Promise 是用于处理异步操作的一种机制。当 Promise 被拒绝(即 reject 时),如果没有为其提供处理函数(如 .catch(

用 Notepad++ 直连 SE80:把 BSP / WebClient UI 视图的 HTML 维护效率拉满

用 Notepad++ 直连 SE80:把 BSP / WebClient UI 视图的 HTML 维护效率拉满

用 Notepad++ 直连 SE80:把 BSP / WebClient UI 视图的 HTML 维护效率拉满 在做 SAP CRM WebClient UI、BSP 应用,甚至一些老系统里的自定义页面时,很多人都会遇到同一个尴尬:页面的主要工作量明明在 HTML、CSS、JavaScript,可你却被迫在 SAP GUI 的内置编辑器里写前端代码。它当然能用,但在真实项目里,能用 和 好用 中间隔着一条鸿沟:缺少你习惯的语法高亮、正则替换、多光标编辑、编码可视化、对比插件、批量格式化……写着写着就很容易变成体力活。 有个小技巧能让体验瞬间回到你熟悉的节奏:把你常用的本地 HTML 编辑器(例如 Notepad++)挂到 SE80 里,

本地部署 Gemma-1B 轻量级大模型:Ollama + Open WebUI 完整配置与实战指南

本地部署 Gemma-1B 轻量级大模型:Ollama + Open WebUI 完整配置与实战指南 关键词:Gemma-1B、Ollama、Open WebUI、本地大模型、LLM 部署、JSON 配置、开源模型、轻量化 AI、私有化部署、OpenAI 兼容 API 适用读者:AI 工程师、全栈开发者、技术爱好者、边缘计算研究者、企业私有化 LLM 应用构建者 阅读时长:约 25 分钟(含代码实操) 📌 引言:为什么选择 Gemma-1B 进行本地部署? 在生成式人工智能(Generative AI)迅猛发展的今天,大型语言模型(Large Language Models,