这几年做嵌入式异构平台ARMDSPFPGA的组合听得不少但真愿意拿出来一条条讲清楚的并不多。我前阵子正好拿到一块OMAPL138加Spartan-6的核心板配套一块评估底板断断续续跑了差不多三周从裸机点亮到Linux起来再到三颗芯片之间打通通信踩了不少坑也理顺了不少原来半懂不懂的细节。这篇文章就是把这套板卡的实际试用过程、设计思路和排查记录梳理一遍给准备碰这套平台的人一个参考。文章会涉及硬件上电时序、DDR配置、启动模式、DSP侧裸机开发、FPGA侧配置加载、以及ARM/DSP/FPGA三方通信的常见做法适合已经有嵌入式基础但第一次接触异构平台的朋友纯新手也能跟着把环境跑起来只是有些背景概念建议提前补一补。1. 这套平台是什么定位ARM、DSP、FPGA三种器件凑在一起图什么1.1 OMAPL138这一颗芯片本身就不简单OMAPL138严格来说是双核处理器片内集成了一个ARM926EJ-S内核和一个C674x浮点DSP内核主频最高可以跑到456MHz实际常用300MHz档。ARM9负责跑系统、跑协议栈、管外设C674x负责做算法密集型的信号处理比如滤波器、FFT、浮点运算。两个内核共享一片DDR2和内部RAM通过硬件mailbox和共享内存做通信。这颗芯片之所以在很多工业音频、机器视觉、数据采集项目里出现是因为它把“跑Linux”和“算信号”两件事分开做了而且功耗很低。比如做一个多通道音频采集设备ARM上跑网络协议栈和文件管理DSP上拉一堆FIR、IIR滤波器两边互不拖累比在单核处理器上硬扛要稳得多。1.2 Spartan-6在这块板卡里干的活儿Spartan-6属于某个系列的FPGA中端型号以逻辑单元数量和DSP Slice的性价比著称。在这块核心板上它跟OMAPL138通过EMIFA并行总线挂在同一个存储映射空间里相当于一个“可重构外设”。FPGA在这类平台里通常扮演的角色有三类一是做高速数据采集前端把ADC的数据先缓存、预处理再交给DSP二是做接口转换把一些非标准的总线时序转换成EMIFA能读的并行数据三是做实时控制把对延时敏感的逻辑用硬件实现不给CPU增加负担。我试用的这块板子把FPGA挂在了EMIFA的CS5片选上地址线和数据线直接连过去这也是Spartan-6与OMAPL138通信最主流、吞吐量最大的一种接法。1.3 这类板卡一般被用在什么场景说实话拿这个组合去做消费类电子产品有点浪费它更适合工业级的信号处理和控制混合场景。比如超声波探伤设备前端FPGA做高速采样和波束合成DSP做信号处理算法ARM做显示和通信再比如电力系统监测终端多路ADC同步采集、实时计算、网络上报这套架构的每一部分都各司其职。我当时的评估目标是拿它做一台上位机控制卡Core层跑Linux做Socket通信DSP做数字滤波和特征提取FPGA模拟几路接口来对接外部传感器。如果只用单核处理器实时性很难保证如果全用FPGA算法迭代又太费劲。这种ARMDSPFPGA的组合恰恰把三种器件的优势都放在了合适的位置上。2. 硬件设计和核心板布局的门道2.1 电源域与上电时序最容易翻车的地方OMAPL138对电源的要求可以分成三组看待内核电源、I/O电源、实时时钟电源。典型配置下内核用1.2VI/O和大部分接口用3.3VDDR的VDDQ用1.8VRTC用一个独立的1.2V或由电池直接供电。核心板上一般用一颗电源管理芯片把外部5V转成这三路关键是上电顺序。OMAPL138手册里明确规定内核电源要先上I/O电源后上两者之间通常要求几十毫秒的间隔RTC电源优先级最高必须一直保持有效。这块核心板的设计比较规矩电源管理芯片的每个输出通道都有独立的使能控制用延迟电路确保上电顺序。我后来用示波器实测过的确是先1.2V、再1.8V、最后3.3V大概间隔20ms左右。这个顺序如果反过来短期内大概率也能跑但器件长期可靠性会打折扣严重的直接导致DSP内核电流异常。评估板上还有一路独立的5V输入给底板外设用核心板与底板之间有防倒灌处理。我一开始把底板供电和核心板供电接反了顺序结果电源指示灯能亮但串口完全没反应排查了半小时才发现是I/O电源比内核上得还早。后来老老实实按底板标注的“先核心板后底板”顺序操作再没出过事。2.2 启动模式与DDR配置不是焊上去就能跑OMAPL138没有内部Flash启动只能靠外接存储常见的是SPI Flash、NAND Flash、NOR Flash或者直接UART启动。启动模式由一组BOOT引脚在复位上升沿采样决定这组引脚在核心板上通过拨码开关引出来了。我拿到的板子默认是SPI Flash启动拨码开关上专门标注了每个档位对应的启动介质这个细节对做板卡的人来说其实很关键因为很多核心板到场默认启动介质和你想要的不一致你会误以为板子坏了。DDR的配置是另一个坑。OMAPL138的DDR2控制器需要在上电后由软件初始化寄存器包括刷新周期、时序参数、行列地址位宽。这些参数在U-Boot里通过配置文件设置。我用的核心板配的是两片DDR2颗粒共256MBU-Boot里已经做好的配置直接就能跑。但我尝试调整过DDR频率想优化性能结果系统能启动但跑一会儿就随机死机。后来对比原厂配置才发现刷新周期参数跟温度等级是绑定的工业级的芯片在常温下如果照搬消费级的刷新参数就有风险改回默认值就稳定了。2.3 核心板与评估板之间的接口定义核心板采用了类似邮票孔的引脚形式把所有可用的外设和总线都引到了双排插针上。OMAPL138的引脚大部分是功能复用的核心板设计者把UART、SPI、I2C、McBSP、USB、EMIFA数据总线和几组GPIO都引出来了评估板上再通过跳线做功能选择。这里有一个值得注意的设计取舍UART0被固定用作启动调试串口Core侧Linux的console输出就挂在上面而DSP侧的调试信息如果也想走串口就得另外复用别的串口。我当时想让DSP打印点调试信息发现默认的调试串口被ARM占了最后把McBSP配成UART模式才解决。很多核心板不会在文档里写清楚这种“隐含占用”遇到问题先翻原理图确认引脚复用比闷头调试高效得多。3. 开发环境搭建与首次跑通3.1 ARM侧Linux的启动路径ARM侧跑Linux是我们这套平台的第一步。使用的系统是基于某个经典内核版本定制的厂商已经编译好U-Boot和内核镜像放在SPI Flash和SD卡里。默认启动流程是上电后固件从SPI Flash读取U-BootU-Boot初始化DDR和串口再加载内核和设备树。设备树里把EMIFA、SPI、I2C这些外设节点都配好了特别是FPGA挂载的那个CS5区域在设备树里被定义成一个内存映射设备。我自己也尝试过从零编译内核环境是基于Ubuntu某个LTS版本交叉工具链用厂商提供的ARM编译器内核代码拉下来之后直接执行老一套的配置编译流程就行。踩过的一个小坑是设备树里的EMIFA节点有units的说明如果你换成别的内核版本总线时序的配置节点可能不兼容导致FPGA区域映射出来读不到数据。解决办法是尽量沿用板卡厂商验证过的内核版本不要一上来就追新。启动成功后Linux里能看到/dev/mem和/sys/class/gpio等标准节点。FPGA挂载的地址区域可以通过/sys/bus/platform/devices下的设备节点访问或者用 mmap 直接映射物理地址。我写了一个简单的测试程序映射CS5对应的物理地址往里面写一个固定值再用逻辑分析仪检查FPGA侧的电平变化确认总线通路是好的。提示在跑Linux的ARM上访问EMIFA设备如果没写内核驱动直接用mmap映射物理地址要注意缓存一致性问题最好把映射区域配置为strongly ordered或device memory否则写操作可能被写回缓存读操作也可能拿到旧数据。3.2 DSP端的裸机程序怎么跑DSP侧初期不跑操作系统直接用裸机工程调试。开发工具是芯片原厂的老牌集成开发环境CCS它支持对OMAPL138的双核进行调试连接方式可以是仿真器通过JTAG也可以直接在ARM侧的Linux里运行一个DSP加载工具把DSP的可执行文件加载到共享内存区域并启动DSP。CCS里新建DSP裸机工程时目标芯片选C674x编译器用原厂的CGT工具链。裸机程序的结构其实很简单就是一个main函数里初始化后跑主循环但需要注意C674x的入口点设置和中断向量表位置。板卡厂商提供了一套DSP启动模板里面已经把cache配置、中断控制器初始化都写好了我就在这套模板上做二次开发省了很多事。调试DSP最爽的是CCS的图形化变量窗口可以在线看波形直接观察中间数组的数值。我用它调了一个10阶IIR滤波器把输入信号直方图和输出信号放一起看效果整个过程体验很不错。唯一的问题是仿真器比较贵如果没有仿真器就得靠ARM侧把DSP的日志通过共享内存传出来调试效率会低一些。3.3 FPGA侧ISE流程与配置加载Spartan-6的开发工具是某款经典的FPGA集成套件最后的稳定版本是14.7这个版本也是Spartan-6的“绝版”支持。流程跟所有FPGA一样写HDL、综合、实现、生成比特流、下载。我这里要重点说的是配置加载的两种方式。第一种是JTAG在线调试适合功能验证。用下载器连上板载JTAG接口把生成的bit文件直接下载到FPGA里掉电就没。第二种是SPI Flash配置把bit文件转成prom格式烧进SPI Flash上电后FPGA自动加载。这块板卡上FPGA的配置时钟可以跟OMAPL138共用同一个SPI总线但要注意避免两个器件同时抢总线。板卡上的跳线就是干这个的调试时跳JTAG模式量产时跳Flash模式。Spartan-6还有一个细节IO电平标准必须在约束文件里写清楚比如挂EMIFA的引脚组要设置成LVCMOS33否则默认的LVCMOS25可能会电平不匹配导致OMAPL138读不到正确的数据。我第一次综合时忘了加IO标准约束时序报告中显示电压域错误但功能在仿真里又正常浪费了半天时间排查。4. 三大处理单元之间的通信细节4.1 ARM与DSP的共享内存通信OMAPL138内部有一块比较大的共享RAM同时DDR也可以被ARM和DSP通过不同的地址窗口访问。通信的基本套路是定义一块共享内存区域ARM往里面写数据结构和标志位DSP轮询或收到中断后读取处理后把结果写回再通知ARM。早期产品用DSPLINK这套通信组件它提供的是抽象的Message和Region接口但配置繁琐依赖特定内核版本。后来有了SYSLINK它把底层mailbox和共享内存管理封装成了内核驱动用户态通过文件接口就能跟DSP通信方便很多。我试用这块板卡时就直接用了SYSLINK在ARM侧Linux里加载对应内核模块再写一个用户态测试程序把一个数据块发到DSP侧DSP做一次求和后写回测试通了。这里有个关键参数共享内存区域的地址和大小必须在DSP链接脚本和SYSLINK配置里保持一致。否则DSP访问到的数据完全不是ARM写的那份而且这种问题极难排查。建议在通信结构体最前面放一个固定魔数启动后互相校验一下就知道了。4.2 ARM/DSP与FPGA的EMIFA交互FPGA通过EMIFA挂在OMAPL138的存储映射空间里看起来就是一个外部存储设备。ARM或者DSP只要对某个地址范围做读操作时序就会通过EMIFA总线传导给FPGAFPGA解析地址和数据线就能完成交互。EMIFA支持8位、16位两种数据宽度这块板卡用的是16位模式。FPGA侧负责把读写信号、片选信号、地址总线、数据总线转换成内部逻辑能用的控制信号。我写了一个简单的寄存器组FPGA内部维护16个16位寄存器ARM侧往寄存器0写控制字往寄存器1写数据FPGA就能输出对应的PWM波形。这个方案比GPIO模拟要高效得多一次访问就是一条指令的事。调试EMIFA交互最直观的工具是逻辑分析仪把芯片使能信号、读写使能信号、地址和数据总线全抓出来。我碰到过一次CS5区域完全无响应的问题用逻辑分析仪一看发现地址总线上始终带着一个偏移量原来是我在设备树里把reg配置成了CS5的基地址加了一个偏移导致访问地址越界把偏移去掉就好了。4.3 中断与握手把三端串起来纯轮询通信在数据量不大时够用但在高速数据采样的场景下轮询会浪费大量CPU时间这时候就需要中断。OMAPL138的中断通路是FPGA拉高一个GPIO或者利用EMIFA的扩展信号产生事件这个信号连接到ARM或DSP的可编程中断控制器内核响应后读取FPGA的数据寄存器。我在这块板卡上验证了一套典型流程FPGA采到一组数据后拉高GPIO中断DSP响应中断通过EMIFA读取FPGA内部FIFO的数据处理完成后写回结果再通过mailbox通知ARM取走结果。整个链路在逻辑分析仪上能看到清晰的中断脉冲和数据总线活动时序关系非常明确。这块板卡的FPGA有足够的逻辑资源做一个小型异步FIFO这个设计特别实用可以缓存突发数据避免DSP还没来得及读新数据就已经把旧数据覆盖了。FIFO的读侧挂在EMIFA总线上写侧挂在采集逻辑上两端时钟不同步也没关系。5. 实测中的坑与排查实录5.1 上电时序不对板子没有任何反应我前面提到过上电顺序踩过一次坑这里再展开说一下。当时核心板电压跳线接法有误导致3.3V比1.2V先建立结果是U-Boot跑不起来串口毫无输出电源指示灯却是正常的。这类故障最迷惑人的地方在于“看起来有电”。排查思路是先量关键节点电压核心板上的1.2V、1.8V、3.3V是否都正确再用示波器同时抓三路电的上升沿看先后顺序。如果发现顺序不对先查电源管理芯片的使能引脚和延迟配置电阻不要急着怀疑固件。很多核心板的文档里会给出“推荐上电顺序”的测试点位置用示波器探针同时挂上就能看到。这个问题在量产阶段尤其重要电源管理芯片的配置电阻如果贴错一个整批板子都会出问题。5.2 FPGA配置一直失败FPGA在JTAG模式下能正常下载但切换到SPI Flash模式就起不来。FPGA的DONE引脚一直是低电平说明配置没有完成。这种问题有几个常见原因bit文件转prom文件时格式选错、SPI Flash芯片型号与配置工具里选的型号不一致、配置时钟频率过高导致Flash读取不稳定。我排查下来是Flash擦除不完全。因为下载器在烧写prom之前如果不执行擦除操作flash里残留的数据会导致FPGA校验失败。解决方法是重新烧写前先全片擦除一次再写入新数据。另外配置时钟频率在Spartan-6上最高可以到几十兆但很多SPI Flash并不支持那么高的读时钟保守一点降到10MHz以内更稳。5.3 DDR长时间跑就崩溃系统能够启动也能跑基本程序但持续运行几个小时后就随机死机串口输出一堆无法解析的异常。这种问题在DDR相关的项目里非常经典。我前面提到修改DDR刷新参数导致不稳定其实还有一个更隐蔽的因素是DDR2终端电阻和板上走线阻抗不匹配导致信号完整性下降长时间高温运行后问题才暴露。软件层面的排查就是把U-Boot里的DDR参数恢复成厂商默认值再观察是否复现。也可以跑内存压力测试软件连续读写来快速暴露问题。如果是硬件设计问题就需要在DDR的DQ、DQS信号线上检查是否有信号反射这个就得靠示波器了。我的经验是先用软件排除法确定是DDR问题再用替换法确认板子硬件最后再怀疑自己的配置改动。5.4 常见问题速查表现象可能原因排查手段上电后串口无输出上电时序不对、启动介质选错示波器抓电压时序、检查拨码开关状态U-Boot能启动Linux起不来设备树与外设不匹配检查设备树节点地址、确认内核版本EMIFA区域读写超时地址偏移配置错误、总线宽度不匹配逻辑分析仪查片选与读写时序FPGA掉电后丢失逻辑配置没写进Flash或烧写格式不对检查prom文件格式、配置时钟频率DSP程序加载后无响应共享内存地址不一致、入口点错误对比链接脚本与SYSLINK配置DDR长时间运行死机刷新参数或信号完整性问题恢复默认参数、跑内存压力测试6. 个人体会与选型建议这套OMAPL138Spartan-6的组合在当下的嵌入式市场里不算新潮但它的成熟度和文档完整度是经过大量项目验证的。我在三周试用里最大的感受是这套平台适合那种需要“稳定可靠”多于“极限性能”的场景。比如工业采集、音频处理、电力监控这类产品算法模型固定、接口需求明确用这套架构可以把开发周期压得很短。如果让我给准备选型的人一个建议我会先说清楚自己的需求到底是什么。如果只是需要一个能跑Linux的低功耗处理器那直接买单品ARM芯片可能更省事如果算法迭代频繁需要反复调DSP代码这套方案比其他方式更灵活如果大数据量吞吐是核心指标FPGA侧设计才是决定成败的关键建议把精力重点放在EMIFA接口时序和FPGA的内部FIFO设计上不要一上来就写上层应用。最后再分享一个很小的细节核心板的散热和外壳结构出发前一定要考虑清楚我试用的这块板卡在满负荷运行DSP算法时核心板表面温度上升非常明显不加散热片长时间跑会不稳定。很多人只关注软件能不能跑通忽略了热设计恰恰是这类工业场合最隐蔽的坑。希望这篇心得能让你少走几步弯路。
