ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

无人机双路视频图传项目DDR3选型与Verilog读写控制的5个实战坑

无人机双路视频图传项目DDR3选型与Verilog读写控制的5个实战坑 先说项目背景免得大家拿到标题不知道我在聊什么。年初我们接了一个无人机双路视频图传项目机载端两个摄像头每路1080p/60帧采集后送FPGA做拼接和H.264编码压缩码流再通过无线链路回传到地面站。整机算力不大内存规划时团队盯上了DDR3 2Gbit 1866颗粒16bit位宽单片搞定。当时看中的是方案成熟、开发资料多、成本低怎么算都觉得稳。结果从选型、布线到控制逻辑一路踩坑踩到怀疑人生。尤其是DDR3 2G 1866这个组合放在无人机这种低纹波余量、宽温度范围、高并发读写的场景里几乎每个环节都可能出幺蛾子。这篇就把我实际踩过的5个坑完整写出来包括现象、定位思路和处理办法给准备在嵌入式视觉、图传、双路视频采集这类项目里选DDR3的朋友做个参考。1. 选型前先搞懂DDR2/DDR3/DDR4的差别为什么我只选DDR3网上搜DDR3的时候总会连带着搜出一堆“ddr2、ddr3、ddr4的区别”之类的内容。说实话这三代内存的差异不是频率数字那么简单它直接决定了你的控制器设计难度、功耗预算、电源复杂度和PCB布线成本。选型之前我建议先把这张表刻在脑子里。参数DDR2DDR3DDR4工作电压1.8V1.5V / 1.35V1.2V预取宽度4bit8bit8bit靠bank group提升带宽常见频率400-1066MHz800-2133MHz1600-3200MHzI/O接口标准SSTL-18SSTL-15POD12终结方式片内ODT有限片内ODT更完善动态ODT伪开漏POD支持VPP新增关键功能无ZQ校准、读写Leveling、复位引脚DB、CRC校验、指令奇偶校验、bank group典型拓扑菊花链/T型Fly-by拓扑命令地址走菊花链Fly-by拓扑典型应用场景老式嵌入式设备大批量视频/通信/工业设备高性能计算、PC、高端嵌入式我特别想强调一个容易忽略的事实DDR3和DDR2之间差距不是“频率更高了”而是预取宽度从4bit翻到8bit。这意味着同样跑在800MHz的接口频率下DDR3内部存储阵列的等效数据传输率是DDR2的两倍控制器侧的Burst Length也从4变成了8。对应到Verilog读写控制Bank管理、突发对齐、写后读间隔这些细节全都不一样了。DDR4的功耗确实更低1.2V但代价是颗粒封装和控制器IP的复杂度上去了而且DDR4一般需要额外的VPP电源用于字线升压PCB上的供电网络比DDR3多一路。在无人机这种对面积、层数、成本都敏感的板子上DDR4省下的那点功耗完全不够抵消供电和布线带来的麻烦。所以最终方案还是锁定了DDR3。还有一个现实原因FPGA平台对DDR3的支持太成熟了。Xilinx的MIG、Intel的EMIF都是点两下就出控制器网上能搜到大量可用的参考设计。相比之下DDR4的IP在很多老型号FPGA上根本不开放LPDDR4更是要额外买License。项目周期紧的时候“生态成熟”这四个字比参数表里那几百兆频率值值钱得多。2. 第一个坑1866的“1866”只是颗粒能跑不是你的板子能跑当时选DDR3-1866核心原因只有一个带宽高。双路1080p/60的视频流进来每路YUV422格式大约是4MB一帧60帧就是249MB/s两路加起来接近500MB/s。再加上H.264编码器要反复读参考帧、写重建帧16bit位宽的DDR3跑1600的时候理论带宽只有3.2GB/s实际能用一半就不错了算一算有点紧。所以一看到1866觉得频率越高越好直接定了。结果样机回来用MIG IP默认配置跑常温桌面测试一切正常一装到无人机上整机通电磁场干扰一上来开始偶发出现写数据超时。用ILA挂在控制器的写数据通道上抓等半天抓不到一次错误但实际图传画面就是会卡顿。后来把频率从1866降到1600同样的代码、同样的板子跑了三天一次错误都没出。这个问题的本质是时序裕量。DDR3-1866的时钟周期只有1.07ns写数据眼本来就小再加上读写Leveling的偏差、PCB走线等长误差、电源纹波对VREF的影响留给控制器的裕量可能只剩几十皮秒。无人机不是实验室环境电机的EMI、电池电压波动、高频振动都会影响信号完整性。数字电路在高频下没有“玄学”只有裕量够不够。定位和处理思路供参考先降频验证如果降一档频率就稳定基本可以判断是时序裕量不足而不是逻辑错误。检查FPGA到DDR3的走线等长数据线组内等长建议控制在±10mil以内DQS和CLK的等长要做重点检查。我们当时PCB布线组把数据线等长做到了±5mil但DQS和时钟之间差了将近50mil这在1866下几乎必挂。用调试工具读出DDR3的时序参数MIG IP里可以调整CAS Latency、Write Latency、ODT阻值、输出驱动强度适当放宽CL/CWL或者把ODT从40欧调到60欧能救回一部分裕量。最直接的还招降频。1600MHz的CL从11调到12整个系统稳如老狗肉眼看不出带宽差异。提示标称频率是颗粒厂商在特定负载、特定PCB条件下的测试值不是你的板子一定能跑到的值。选型时按标称频率的80%来规划带宽能省掉后面一大堆排查时间。3. 第二个坑2G到底是2Gbit还是2GB容量规划必须用bit为单位这个坑说起来有点丢人但我和团队真就踩了。DDR3颗粒的规格书里“2G”默认是2Gbit不是2GB。初学者特别容易混连我们做硬件的同事也差点按2GB去规划缓存。我们当时的缓存规划是这样的双路1080p/60YUV422格式每帧约4MB两路各缓存3帧那就是约24MBH.264编码器需要参考帧队列按4张参考帧算又占约32MB码流缓冲、位图叠加、通信协议栈再分掉一些。整体算下来一个2GB的内存规划刚好够。结果颗粒到位一看单片只有2Gbit也就是256MB直接砍到八分之一。双路视频跑起来帧缓存和参考帧队列互相挤压DDR3读写冲突频繁画面直接撕裂。用bit还是Byte计算逻辑如下给大家捋一遍常见16bit位宽颗粒单片容量2Gbit 2 × 1024^3 bit除以8 268,435,456 Byte也就是256MB。但这里的“2Gbit”在颗粒组织上可能是128M × 16bit。注意128M是存储单元数不是字节数。8bit位宽颗粒同样是2Gbit组织方式是256M × 8bit容量还是256MB只是地址线和数据线的分配不一样。所以选型的时候别只看包装上的容量标签一定要和供应商确认三件事单片容量是多少bit、数据位宽是几bit、封装是x8还是x16。因为这个差异直接决定了你的FPGA引脚分配、地址线宽度和Bank管理逻辑。我们最后换成了4Gbit512MB的x16颗粒地址线从A0-A12变成A0-A13多了一条BA2线控制器配置里把Memory Part选对问题迎刃而解。如果项目对容量需求更大还可以考虑两片x16颗粒拼32bit位宽但无人机板子面积有限单片512MB已经是我们能接受的极限。提示如果颗粒型号后缀里出现类似“MT41K256M16”这样的编号中间的数字“256M”指的是存储单元数量256M个再乘以后面“16”就是位宽二者相乘除以8才是MB数。拿到型号第一件事先换算容量别等画完板再改。4. 第三个坑双路视频并发读写带宽和仲裁才是真瓶颈单路视频跑的时候DDR3的带宽绰绰有余。一旦接入第二路摄像头再加上H.264编码器的读参考帧和写重建帧整个DDR3总线上的请求来源变成了四个Camera0写入、Camera1写入、编码器读取、编码器回写。这四个源如果谁也不让谁DDR3的效率会断崖式下降。我实测过一组数据说出来大家可能不信16bit位宽DDR3-1600理论带宽3.2GB/s但在四路读写并发且仲裁策略简陋的情况下实测有效带宽只有约1.4GB/s利用率不到45%。照这个效率双路1080p/60外加编码器很容易就把带宽吃满出现丢帧和画面撕裂。定位这个问题的第一步是重新计算带宽需求双路摄像头写入每路1080p/60/YUV422约249MB/s两路约498MB/s。H.264编码器读参考帧按参考帧4张、60fps、每张约4MB算读取带宽约250MB/s。编码器重建帧回写和码流缓冲写入约100MB/s。合计需求约850MB/s。表面看1.4GB/s的有效带宽还够。但那是理想情况下实际运行中还有刷新操作、Bank冲突、读写切换惩罚这些都会进一步压缩可用带宽。问题往往不是“总带宽不够”而是“某个瞬间多个请求同时涌向同一个Bank造成排队”。处理方法是把仲裁和Bank规划做细我这边实际做了三件事用独立的请求队列分别缓冲四个DDR访问源用带优先级的轮询仲裁。实时性最高的是摄像头写入因为丢一帧等于画面卡一次编码器读参考帧次之码流写入最低可以排队等待。把双路摄像头写入分配到不同的Bank组避免两个写入流同时命中同一个Bank。DDR3的Bank数量一般是8个完全够用。把Burst Length从4提到8每次读写处理的数据量翻倍减少命令周期在总线上占用的比例也就是减少命令地址总线上的切换开销实测效率提升非常明显。调整完之后同样跑双路1080p/60加编码器DDR3有效带宽利用率从45%提升到了约62%画面撕裂和丢帧问题彻底消失。那块瓶颈其实从来不在颗粒本身而在你怎么调度它。5. 第四个坑纹波、温度等级这些“不上电”的指标决定无人机能不能飞这个坑是最阴间的因为它在实验室里根本不会暴露只有整机装到无人机上才会出事。项目中期我们做了一次室外低温试飞。环境温度大约零下5度无人机起飞后电机大电流拉载图传偶尔会出现花屏和偶发的数据CRC错误。返厂排查在实验室常温环境下反复测试始终复现不了。后来把示波器探头直接点到DDR3的VDDQ和VTT上让无人机在飞行动作下录波形真相才露出来电机换向的瞬间整机供电线上出现超过150mV的尖峰纹波直接灌到了DDR3供电网络上。DDR3的VDDQ是1.5VJEDEC标准允许的纹波范围大概是±2%也就是±30mV左右。150mV的纹波直接把数据总线的信号判决电平全都带偏了。更麻烦的是DDR3的数据总线是双向的DQS和DQ在接收端的参考电压VREF也需要非常干净纹波一大采样点就漂读数据就可能采错。另外温度这个指标在无人机上也是大问题。商用级DDR3颗粒的标准工作温度是0到70度工业级是-40到85度。低温环境下DRAM的刷新周期其实需要做补偿很多控制器的默认刷新率是按85度最恶劣情况设计的反而在极低温下可能出现自刷新保持时间异常。当时我们为了省几块钱采购成本选的是商业级颗粒零下温度一跑就心虚。这两块的整改措施可以给同样做无人机、车载这类宽温低纹波环境的朋友参考DDR3供电不能直接从系统主电源上拉必须单独走一级低纹波LDO或带低纹波特性的DC-DC并且把LC滤波做到位。VTT和VREF的生成电路尽量靠近DDR3颗粒端VTT的上拉/下拉电阻网络不要省VREF用高精度分压电阻加去耦电容。选型时起步就要用工业级颗粒温度范围务必覆盖-40到85度。无人机冬天用的场景太多了别在这个指标上赌概率。在FPGA里加一个后台DDR数据校验任务周期性写入已知数据并读回比对把CRC错误计数暴露到调试接口。这样偶尔出现的数据错误能被实时捕捉不用等花屏了再去猜。这些问题单独看都是小坑但无人机是机械振动、大电流瞬变、宽温度范围三重恶劣环境叠加小坑会迅速放大成大故障。处理完之后我们在DDR3的电源前端加了一颗磁珠和两级钽电容的滤波器实测纹波从150mV降到25mV以内低温花屏问题再也没出现过。6. 第五个坑Verilog读写控制没有你想的那么难但细节会骗人本来这个坑应该写在最前面因为DDR3的读写控制是整个项目里最容易“仿真全过、上板就挂”的部分。我把它放在最后是因为如果前面几个坑你没踩过大概率说明你的控制器是直接拿IP或者参考设计改的这个坑出现的概率就低一些。不少人搜“ddr3读写控制实现verilog”的时候是想自己写控制器我完全理解为什么有人想自己做毕竟MIG生成的代码量大看不太明白总觉得没有掌控感。但实际上DDR3控制器的核心难点不在“读写”这两个字上而在三件麻烦事上初始化时序上电后要经历复位、CKE拉高、等待至少500us、加载MR0到MR3寄存器然后做ZQ校准整套流程一步都不能错。MR寄存器里配置了CAS Latency、Write Latency、Burst Length、输出驱动强度、ODT阻值、附加延迟等几十个bit任何一个配置和颗粒实际参数不匹配都会导致读写数据异常。刷新管理DDR3要求每64ms刷新8192行平均每7.8us发一次刷新命令。问题是你没法保证这7.8us内DDR恰好是空闲状态所以刷新请求在仲裁器里必须有足够高的优先级。我们当时在一个低优先级任务里面插刷新命令逻辑仿真根本测不出来因为仿真时DDR访问频率低实际跑起来高负载时刷新命令等太久DRAM内部数据保持失败出现偶发单bit翻转。时序参数Activate到Read/Write之间的tRCD、Precharge到Activate的tRP、写后读的tWTR、突发传输的tCCD这些参数哪怕差一个时钟周期数据都可能串位。比如Write Latency配置错了写数据会整体错位但仿真模型有时会宽容这类错误上板后DQS和DQ的相位关系就全乱了。如果一定要自己写我的建议是按这个顺序做第一步先不碰任何DDR用IP生成一个基础控制器把初始化流程和时序参数都读一遍看明白MIG在初始化阶段到底往MR寄存器里写了什么。第二步写一个简单的用户逻辑先做单地址写读回环确认基本通路OK。第三步加刷新调度用计数器严格控制刷新间隔并把刷新请求仲裁器的优先级调到仅次于实时光写入。第四步用ILA或者SignalTap去抓PHY接口层的DQS和DQ波形对比DDR3手册里的时序图确认读写DQS相位对齐。排查时最有效的一招是降频。把DDR3时钟从1866降到800甚至400如果之前的上板错误全部消失基本说明问题出在时序余量或训练上而不是逻辑架构。先把低频下的读写调稳再往上提频每提一档做一次压力测试这样排查效率最高。提示新手我真的建议直接用MIG或EMIF别自己造轮子。DDR3控制器属于那种“看起来简单、做起来全是雷”的东西项目周期紧的时候拿现成IP把配置搞清楚比从头写省两个星期起步。7. 常见问题速查表现象、原因、对策最后把这段时间碰到的问题整理成一个速查表。不一定每个现象都对应“立刻换颗粒”按表格顺序排查通常能直接定位到根因。现象可能原因快速排查方法解决办法高温或低温环境下偶发花屏颗粒温度等级不够看颗粒丝印确认商业级还是工业级换工业级颗粒启动自检和CRC校验电机启动瞬间图像卡顿/花屏DDR3供电纹波过大示波器量VDDQ和VTT波形单独供电、加磁珠和滤波电容双路接入后丢帧仲裁策略不合理、burst过短统计DDR控制器效率提高Burst Length、分开Bank分配偶尔出现单bit数据错误刷新仲裁优先级低或刷新超时查看刷新计数和ILA抓取刷新命令时间戳提高刷新请求优先级确认间隔小于7.8us1866下偶发写超时时序裕量不足或PCB等长差降频到1600测试调整ODT和驱动强度严重时降频运行上电后DDR初始化失败MR寄存器配置错误或ZQ校准异常抓初始化状态机状态核对颗粒型号和MR参数确保ZQ外挂240欧电阻还有一个容易被忽视的细节DDR3颗粒的ZQ引脚必须通过240欧姆电阻接地这个电阻的精度直接影响ZQ校准后的输出驱动强度和ODT阻值。我们有一次贴片批次把240欧贴成了2.4K欧结果DDR3读写老是不稳定最后用万用表一个个去量才发现是阻值错了。一些碎碎念式的经验项目收尾后回头看DDR3 2Gbit 1866本身是个好方案在无人机图传和双路视频这个场景里完全够用功耗和成本也都控制得住。真正出问题的都是选型时容易被忽略的边界条件容量单位、频率裕量、温度范围、供电纹波、仲裁策略这些没一个写在颗粒的datasheet首页上却决定了整个系统能不能在恶劣环境里稳定跑。我个人最大的体会是嵌入式系统里没有“某一块芯片决定成败”这回事DDR3这种看似成熟到不能再成熟的内存颗粒放到具体项目里照样有一百种方式教你做人。选型前把容量按照bit来算、频率按标称的八成来规划、颗粒直接上工业级、供电单独做低纹波处理、控制器优先用IP这套组合下来后面能少熬两个星期的夜。如果你们项目也在选DDR3做视频类应用希望这5个坑能帮你们提前绕开。
返回列表