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

【AI】——SpringAI通过Ollama本地部署的Deepseek模型实现一个对话机器人(二)

【AI】——SpringAI通过Ollama本地部署的Deepseek模型实现一个对话机器人(二)

🎼个人主页:【Y小夜】 😎作者简介:一位双非学校的大三学生,编程爱好者, 专注于基础和实战分享,欢迎私信咨询! 🎆入门专栏:🎇【MySQL,Javaweb,Rust,python】 🎈热门专栏:🎊【Springboot,Redis,Springsecurity,Docker,AI】  感谢您的点赞、关注、评论、收藏、是对我最大的认可和支持!❤️ 目录 🎈Java调用Deepseek  🍕下载Deepseek模型  🍕本地测试  🍕Java调用模型 🎈构建数据库  🍕增强检索RAG  🍕向量数据库  🍕Springboot集成pgvector 🎈chatpdf 🎈function call调用自定义函数 🎈多模态能力 🎈Java调用Deepseek 本地没有安装Ollama、Docker,openwebUI,可以先学习一下这篇文章:【AI】——结合Ollama、Open WebUI和Docker本地部署可视化AI大语言模型_ollma+本地大模型+open web ui-ZEEKLOG博客

OmniSteward:LLM Agent 赋能,语音文字随心控,智能家居与电脑的超级管家

OmniSteward:LLM Agent 赋能,语音文字随心控,智能家居与电脑的超级管家

目录 * 一、前言 * 二、项目概述 * 三、功能特性 * 四、技术架构 * 五、安装与使用 * 1、系统要求 * 2、安装步骤 * 3、环境变量配置 * 4、启动方式 * 4.1 命令行模式(CLI) * 4.2 Web模式 * 六、应用场景与未来展望 * 七、结语 一、前言 在科技日新月异的今天,人工智能正以前所未有的速度改变着我们的生活方式。从智能手机的语音助手到智能家居的自动化控制,AI技术逐渐渗透到生活的各个角落,为我们带来了便捷与高效。OmniSteward正是在这样的背景下应运而生,它作为一款基于大语言模型的全能AI管家系统,致力于打破人机交互的壁垒,为用户打造一个智能、高效、便捷的生活和工作环境。无论是忙碌的上班族希望在工作中提高效率,还是追求高品质生活的家庭用户渴望轻松掌控家居设备,OmniSteward都有可能成为他们理想的智能伙伴,引领我们进入一个全新的智能生活时代。 二、项目概述 OmniSteward是一个正在积极开发中的全能管家系统,

【UAV】基于射频和深度学习的无人机检测与识别:构建大型开源无人机数据库的初步探索【附MATLAB+python代码】

【UAV】基于射频和深度学习的无人机检测与识别:构建大型开源无人机数据库的初步探索【附MATLAB+python代码】

文章来源:微信公众号:EW Frontier QQ交流群:1074124098(如满私信留言获取最新群) 注:本文为参考文章~代码为对其部分内容进行复现~ 若有侵权联系删除。 摘要 民用无人机的普及可能引发技术、安全和公共安全问题,这些问题亟待解决、规范和预防。安全机构一直在不断探索能够检测无人机的技术和智能系统。然而,相关技术的突破因缺乏无人机射频信号开源数据库而受阻,这些射频信号可通过远程传感和存储,为开发最有效的无人机检测与识别方法提供支持。本文为构建不同飞行模式下各类无人机射频信号数据库迈出了重要一步。我们系统地收集、分析并记录了不同无人机在不同飞行模式(如关闭、开启并连接、悬停、飞行和视频录制)下的原始射频信号。此外,我们利用所开发的射频数据库设计了智能算法,用于检测和识别入侵无人机。研究采用三个深度神经网络,分别实现无人机存在检测、无人机存在及类型识别,以及无人机存在、类型及飞行模式识别。通过 10 折交叉验证过程验证每个深度神经网络的性能,并使用多种指标进行评估。分类结果显示,随着类别数量的增加,性能普遍下降。平均准确率从第一个深度神经网络(2 类)的 99.7%