FPGA与ARM64异构架构下高速数据采集DMA框架设计与实现

1. 为什么我要做这套一体化采集平台做高速数据采集这行的朋友应该都有体会最头疼的往往不是前端模拟电路也不是FPGA逻辑本身而是数据从FPGA采到之后怎么高效、稳定地送到上位机或者嵌入式处理器里做后续处理。我过去几年做过不少项目从最开始的STM32加SPI ADC到后来Zynq平台上跑裸机DMA再到纯FPGA加外部FIFO芯片的方案每一套都有各自的痛点。STM32那套采样率上不去SPI总线在几兆采样率下就开始丢数Zynq虽然集成了ARM核但PL和PS之间的AXI总线带宽在持续高吞吐场景下也会成为瓶颈而且开发流程割裂感很强逻辑工程师和驱动工程师经常互相甩锅。后来我把目光转向了FPGA加独立ARM64处理器的架构。这个思路其实很朴素FPGA负责它最擅长的事——高速并行采集、时序控制和数据预处理ARM64处理器负责它最擅长的事——跑完整的Linux系统、做协议栈、文件系统、网络通信和上层应用。两者之间用DMA通道连接数据不经过CPU干预直接在内存和FPGA之间搬运。这套架构听起来简单但真正落地的时候从硬件选型、DMA IP核配置、Linux内核驱动开发到用户态接口设计每一步都有坑。hs_dma_framework就是我在这个方向上反复迭代出来的一套相对完整的参考框架名字里的hs是high-speed的缩写dma是核心机制framework说明它不是单个demo而是一套可以复用的工程骨架。这套东西适合谁呢如果你正在做FPGA项目实战尤其是涉及高速数据采集、图像处理前端、通信测试终端或者边缘网关这类场景并且希望把采集到的数据交给一个跑Linux的ARM64平台去处理那这套框架应该能帮你省下不少从头摸索的时间。它不要求你对Linux内核驱动开发有多深的积累但需要你至少能看懂Verilog或者VHDL知道怎么用Vivado或者Quartus建工程对Linux常用命令和基本的设备树概念有了解。下面我会从整体设计思路开始把每个关键环节拆开来讲包括我踩过的坑和最后验证可行的方案。2. 整体架构设计与核心思路拆解2.1 为什么选FPGA加ARM64而不是Zynq或者纯MCU先说选型这件事。市面上做高速采集主流方案大概三类纯MCU加外置高速ADC、Zynq或者UltraScale这类集成ARM核的FPGA、以及FPGA加独立ARM处理器。纯MCU方案在采样率低于1MSPS、通道数少于4路的时候很香成本低、开发快STM32F103配合SPI DMA中断接收发送通信就能搞定。但一旦采样率上到10MSPS以上或者通道数扩展到8路、16路MCU的SPI或者并口带宽就不够了而且MCU做数据预处理的能力有限FFT或者滤波运算跑起来很吃力。Zynq方案的优势是集成度高PL和PS在同一芯片里AXI总线带宽有保障。但实际用下来Zynq的PS端ARM核性能相对有限跑完整Linux桌面或者复杂应用会吃力而且PL和PS的联合调试有时候很折磨人特别是涉及DMA连续请求和缓存一致性问题的时候。另外Zynq芯片本身价格偏高在小批量项目里成本压力不小。FPGA加独立ARM64的方案灵活性最高。FPGA可以选性价比好的中低端芯片ARM64这边可以选瑞芯微、全志或者树莓派CM系列这类跑Linux很成熟的平台。两者之间用高速接口连接我常用的是PCIe或者并行总线加DMA的方式。这样逻辑工程师和软件工程师的职责边界很清晰FPGA这边只管把数据按照约定格式推到DMA FIFO里ARM64这边只管从DMA缓冲区里读数据。调试的时候也可以分开调FPGA用逻辑分析仪或者ILA抓波形ARM64这边用示波器或者逻辑分析仪看总线时序互不干扰。2.2 DMA通道的设计哲学让数据自己流动DMA在这套框架里是绝对的核心。我见过不少项目FPGA采到数据后先存到片内BRAM然后ARM通过GPIO或者SPI慢慢读这种方案在低速率下能用但高速场景下CPU占用率直接爆表。DMA的本质是让数据在外设和内存之间直接搬运CPU只负责配置和收尾搬运过程完全不占用CPU周期。在hs_dma_framework里我设计了三条DMA通道。第一条是采集通道FPGA把ADC或者LVDS接收到的数据打包后写入DMA FIFODMA引擎自动搬运到ARM64侧的内存缓冲区。第二条是配置通道ARM64通过DMA把配置参数下发给FPGA比如采样率、触发阈值、通道使能这些。第三条是状态回传通道FPGA把采集状态、FIFO水位、错误计数这些信息通过DMA回传给ARM64。三条通道物理上可以复用同一个DMA控制器但逻辑上分开管理避免配置数据和采集数据互相阻塞。这里有个关键设计决策DMA缓冲区是用连续物理内存还是分散聚集列表。连续物理内存在Linux用户态很难直接申请到大块通常需要在内核态用dma_alloc_coherent或者预留CMA区域。分散聚集列表灵活但描述符管理复杂而且FPGA侧需要支持描述符解析。我最后选了连续物理内存加双缓冲的方案每个缓冲区大小根据采样率和延迟要求计算。比如采样率100MSPS、位宽16bit、双缓冲各1MB那么每个缓冲区能存大约524288个采样点对应约5.24毫秒的数据。这个延迟对于大多数实时处理场景是可以接受的。2.3 Linux侧驱动与用户态接口的分层ARM64这边跑的是标准Linux我常用Ubuntu 22.04 arm64或者Kylin Linux V10 arm64。驱动层我写了一个字符设备驱动负责DMA控制器的初始化、缓冲区管理、中断处理和mmap映射。用户态通过ioctl来配置采集参数、启动停止采集通过mmap把内核态的DMA缓冲区映射到用户空间这样应用程序可以直接读取数据不需要额外的拷贝。为什么用mmap而不是read系统调用因为read会触发一次内核到用户态的数据拷贝在高速场景下这个拷贝开销很大。mmap把物理内存直接映射到用户进程的地址空间应用程序读数据就像读本地内存一样零拷贝。当然mmap也有代价就是缓冲区管理需要应用程序自己负责不能像read那样有内核帮你做流控。我的做法是在驱动里实现一个环形缓冲区用户态通过ioctl获取当前可读的数据块索引然后直接访问对应的mmap区域。用户态接口我封装了一个轻量级的C库提供hs_dma_open、hs_dma_config、hs_dma_start、hs_dma_read、hs_dma_stop这几个函数。应用程序只需要链接这个库就可以像操作普通文件一样操作DMA采集。库里面处理了缓冲区切换、中断等待、错误重试这些细节上层应用不用关心底层DMA怎么工作的。3. 核心细节解析与实操要点3.1 FPGA侧DMA FIFO的深度计算与位宽选择DMA FIFO的深度不是随便定的需要根据采集速率、DMA搬运延迟和ARM侧响应时间来算。假设采集速率是R字节每秒DMA搬运一包数据的时间是T_dmaARM侧从收到中断到重新配置DMA的时间是T_arm那么FIFO深度至少要是R乘以(T_dma加T_arm)。我一般会再留50%的余量。举个例子采集速率200MB/sDMA搬运一包4KB数据的时间大约是20微秒假设DMA带宽100MB/sARM侧中断响应加处理时间大约50微秒那么FIFO深度至少是200MB/s乘以70微秒等于14KB。留50%余量就是21KB。实际选型的时候我会用32KB的FIFO用FPGA的BRAM实现。如果BRAM不够可以用外置的SRAM或者DRAM做FIFO但那样就增加了硬件复杂度。位宽选择也很关键。FIFO位宽太窄DMA效率低太宽BRAM消耗大。我一般用64bit或者128bit。64bit位宽在100MHz时钟下理论带宽是800MB/s实际能跑到600MB/s左右对于大多数采集场景够用了。如果采集速率超过这个数就要考虑用AXI Stream接口加DMA IP核或者用多个DMA通道并行。3.2 Linux内核驱动的DMA缓冲区分配策略在Linux内核里分配DMA缓冲区有几个选择dma_alloc_coherent、dma_alloc_writecombine、CMA预留内存、或者用IOMMU。dma_alloc_coherent保证缓存一致性但分配大块内存时容易失败因为内核启动后物理内存碎片化严重。CMA预留内存是在内核启动参数里预留一段连续物理内存专门给DMA用这样分配大块内存很稳定。我一般在设备树里预留64MB到256MB的CMA区域具体大小看应用需求。设备树里这样配置reserved-memory { #address-cells 2; #size-cells 2; ranges; cma_pool: cma_pool0x80000000 { compatible shared-dma-pool; reg 0x0 0x80000000 0x0 0x10000000; reusable; linux,cma-default; }; };这段代码预留了从0x80000000开始的256MB内存作为CMA区域。注意地址要根据实际硬件平台调整不能和内核镜像、文件系统加载地址冲突。我踩过一次坑CMA区域和initrd加载地址重叠了内核启动直接挂掉查了半天才发现是设备树地址写错了。驱动里用dma_alloc_coherent从CMA区域分配缓冲区buf_virt dma_alloc_coherent(dev, buf_size, buf_phys, GFP_KERNEL); if (!buf_virt) { dev_err(dev, Failed to allocate DMA buffer\n); return -ENOMEM; }buf_phys是物理地址需要告诉FPGA侧DMA控制器。buf_virt是内核虚拟地址驱动内部用。用户态mmap的时候用dma_mmap_coherent把这块内存映射到用户空间。3.3 中断处理与缓冲区切换的时序配合DMA传输完成中断是驱动和FPGA之间的同步点。FPGA侧DMA搬完一包数据后触发中断ARM64收到中断后切换到另一个缓冲区同时通知用户态有新数据可读。这里的关键是中断响应延迟和缓冲区切换的原子性。我最初的做法是在中断处理函数里直接做缓冲区切换和用户态通知结果发现高负载下偶尔会丢中断。后来改成中断上半部只做最紧急的事——记录当前缓冲区索引、切换DMA目标地址、清除中断标志然后触发一个tasklet或者工作队列来做用户态通知和统计更新。这样中断处理时间从几十微秒降到几微秒丢中断的概率大大降低。缓冲区切换的原子性用自旋锁保护。驱动里维护一个buffer_state结构体记录当前DMA正在写的缓冲区索引、用户态正在读的缓冲区索引、以及每个缓冲区的状态空闲、DMA写入中、用户态读取中、就绪。中断处理函数和用户态ioctl都会访问这个结构体必须用spin_lock_irqsave保护。3.4 用户态零拷贝读取的实现细节用户态通过mmap拿到DMA缓冲区的虚拟地址后读取数据就是直接内存访问。但这里有个缓存一致性问题如果ARM64的缓存策略是写回模式DMA写入的数据可能还在缓存里没落到内存用户态读到的可能是旧数据。解决办法是在驱动里把DMA缓冲区映射为non-cached或者write-combine模式或者在每次DMA传输完成后调用dma_sync_single_for_cpu做缓存同步。我选的是在mmap的时候用dma_mmap_coherent它会自动处理缓存属性。用户态读数据的时候不需要额外的同步操作但要注意读完之后如果要把缓冲区还给DMA需要调用一次ioctl通知驱动驱动会做dma_sync_single_for_device。这个来回同步的开销比数据拷贝小得多实测在200MB/s的速率下同步开销不到5%的CPU占用。用户态读取的典型流程int fd hs_dma_open(/dev/hs_dma0); hs_dma_config(fd, config); hs_dma_start(fd); while (running) { int buf_idx hs_dma_wait_buffer(fd, timeout_ms); if (buf_idx 0) continue; void *data hs_dma_get_buffer(fd, buf_idx); size_t len hs_dma_get_buffer_len(fd, buf_idx); process_data(data, len); hs_dma_release_buffer(fd, buf_idx); }hs_dma_wait_buffer会阻塞等待直到有就绪的缓冲区底层是poll或者ioctl加等待队列实现的。hs_dma_get_buffer返回mmap区域的对应偏移地址。hs_dma_release_buffer通知驱动这个缓冲区可以重新给DMA用了。4. 实操过程与核心环节实现4.1 FPGA工程搭建与DMA IP核配置以Xilinx平台为例Vivado工程里需要例化几个关键IPDMA控制器我用的是自己写的简单DMA也可以用Xilinx的AXI DMA、FIFO Generator、以及采集前端接口。自己写DMA的好处是逻辑透明出了问题好排查而且可以根据需求裁剪功能。我的DMA控制器支持最多4个通道每个通道有独立的源地址、目的地址、传输长度和完成中断。DMA控制器的核心是一个状态机状态包括IDLE、READ_REQ、READ_DATA、WRITE_REQ、WRITE_DATA、DONE。IDLE状态下等待启动信号收到启动信号后进入READ_REQ向源端发起读请求。源端返回数据有效后进入READ_DATA把数据存入内部FIFO。FIFO非空时进入WRITE_REQ向目的端发起写请求。写完成后如果传输长度未达到设定值回到READ_REQ继续否则进入DONE触发中断回到IDLE。FIFO Generator配置为独立时钟模式写时钟是采集时钟读时钟是DMA时钟。深度设为512或者1024位宽和DMA数据位宽一致。Almost Full阈值设为深度的75%用来做反压。Almost Empty阈值设为深度的25%用来做流控。采集前端接口根据实际传感器或者ADC的接口来定。如果是LVDS接收需要例化IBUFDS和IDELAYCTRL做源同步接收。如果是SPI ADC需要实现SPI Master逻辑用DMA把配置数据发给ADC再把ADC返回的采样数据写入DMA FIFO。FPGA的LVDS接收这块要注意时序约束特别是多通道之间的偏斜控制我一般会在约束文件里对每个LVDS对做独立的输入延迟约束。4.2 设备树节点编写与驱动加载设备树里需要为DMA控制器添加节点描述寄存器基地址、中断号、DMA通道数这些信息。以我的平台为例hs_dma: hs_dmaa0000000 { compatible hs,dma-1.0; reg 0x0 0xa0000000 0x0 0x10000; interrupts 0 89 4; interrupt-parent gic; dma-channels 4; dma-buf-size 0x100000; dma-buf-count 4; status okay; };reg指定了DMA控制器的寄存器地址范围interrupts指定了中断号和触发类型dma-channels是通道数dma-buf-size是每个缓冲区大小1MBdma-buf-count是缓冲区个数4个。驱动加载的时候会解析这些参数动态分配缓冲区。驱动模块编译成ko文件用insmod加载。加载成功后会在/dev目录下创建hs_dma0字符设备节点。可以用lsmod查看模块是否加载成功用dmesg查看驱动打印的初始化信息。如果设备树节点写错了驱动probe会失败dmesg里会有详细的错误信息比如寄存器映射失败、中断申请失败这些。4.3 中断号申请与DMA通道初始化驱动probe函数里首先要做寄存器映射res platform_get_resource(pdev, IORESOURCE_MEM, 0); base devm_ioremap_resource(dev, res); if (IS_ERR(base)) { dev_err(dev, Failed to map registers\n); return PTR_ERR(base); }然后申请中断irq platform_get_irq(pdev, 0); ret devm_request_irq(dev, irq, hs_dma_isr, IRQF_TRIGGER_RISING, hs_dma, priv); if (ret) { dev_err(dev, Failed to request IRQ %d\n, irq); return ret; }中断触发类型要和FPGA侧的中断信号极性匹配。我遇到过FPGA输出高电平中断但设备树里写了下降沿触发结果中断一直不来的情况。后来用示波器抓了中断信号波形才发现问题。DMA通道初始化包括设置源地址、目的地址、传输长度、中断使能这些寄存器。每个通道有一组寄存器基地址加上通道号乘以寄存器块大小。初始化的时候把所有通道都配置好但先不启动等用户态ioctl来启动。4.4 用户态测试程序编写与性能验证测试程序我写了一个简单的采集回环测试FPGA侧生成一个递增的计数器作为测试数据通过DMA传到ARM64用户态程序读取数据后检查是否连续递增。如果数据连续说明DMA传输没有丢数如果有跳变说明中间丢了数据包。性能验证主要看三个指标吞吐量、CPU占用率、延迟。吞吐量用dd或者自己写的带宽测试程序测CPU占用率用top或者perf测延迟用时间戳测。我在RK3588平台上实测200MB/s的采集速率下CPU占用率不到15%单核端到端延迟大约2毫秒从FPGA产生数据到用户态读到数据。如果吞吐量上不去先检查DMA位宽和时钟频率是否匹配。比如64bit位宽、100MHz时钟理论带宽800MB/s如果实际只跑到200MB/s可能是FIFO深度不够导致反压或者DMA状态机效率低。可以用ILA抓DMA控制器的状态机和FIFO信号看瓶颈在哪里。5. 常见问题与排查技巧实录5.1 DMA传输丢数或者数据错位这是最常见的问题。现象是用户态读到的数据不连续或者偶尔出现错误值。排查思路从后往前先确认用户态读取逻辑是否正确缓冲区索引和长度有没有算错再确认驱动里缓冲区切换是否原子有没有竞态条件最后用ILA抓FPGA侧DMA控制器的信号看写入FIFO的数据和DMA读出的数据是否一致。我遇到过一次数据错位查了半天发现是FIFO的读使能和读数据之间的时序问题。FIFO IP核配置的时候有个First Word Fall Through模式读使能有效后数据在下一个时钟才有效但我的DMA状态机在同一个时钟就采样了数据导致读到的永远是上一个数据。改成Standard FIFO模式或者调整状态机时序问题就解决了。还有一个坑是DMA传输长度寄存器位宽不够。比如传输长度是20bit但实际数据量超过了1M寄存器溢出后传输长度变成0DMA直接完成中断数据只传了一部分。解决办法是增大寄存器位宽或者在驱动里把大传输拆成多个小传输。5.2 Linux内核启动时DMA缓冲区分配失败dma_alloc_coherent返回NULLdmesg里提示CMA: failed to allocate。原因通常是CMA区域太小或者CMA区域和别的预留内存冲突。检查设备树里CMA区域的大小和地址确保没有和其他节点重叠。另外CMA区域要在内核启动参数里使能有些平台默认不开启CMA。如果CMA区域够大但还是分配失败可能是内存碎片化严重。可以在驱动里用dma_alloc_attrs加DMA_ATTR_NO_KERNEL_MAPPING标志减少内核虚拟地址空间的占用。或者改用分散聚集列表但那样FPGA侧要支持描述符解析复杂度高一些。5.3 中断响应延迟大导致丢包高负载下中断响应延迟可能达到几百微秒如果FIFO深度不够就会丢包。解决办法有几个一是增大FIFO深度用BRAM或者外置SRAM二是把中断处理函数拆成上半部和下半部上半部只做最紧急的事三是用NAPI或者轮询模式替代中断模式在高速场景下轮询有时候比中断更稳定。我实测下来在200MB/s的速率下如果中断处理函数超过20微秒丢包概率就明显上升。后来我把中断处理函数精简到只有寄存器读写和缓冲区索引更新用户态通知放到工作队列里做丢包率降到零。5.4 用户态mmap后读到的数据是旧数据这是缓存一致性问题。ARM64的缓存策略默认是写回DMA写入的数据可能还在缓存里。解决办法是在驱动里用dma_mmap_coherent映射或者在每次DMA传输完成后调用dma_sync_single_for_cpu。我推荐用dma_mmap_coherent它在mmap的时候就把缓存属性设对了用户态不需要额外的同步操作。如果用了dma_mmap_coherent还是读到旧数据检查一下mmap的偏移和长度是否正确。mmap的偏移必须是页对齐的长度最好是页大小的整数倍。如果偏移不对映射到的可能是别的内存区域。5.5 常见问题速查表问题现象可能原因排查方法解决方案DMA传输丢数FIFO深度不够ILA抓FIFO满信号增大FIFO深度或降低采集速率数据错位FIFO时序不匹配ILA抓读写时序调整状态机或FIFO模式缓冲区分配失败CMA区域不足dmesg查看CMA信息增大CMA区域或拆分缓冲区中断延迟大中断处理函数太长ftrace或perf分析拆分上半部和下半部读到旧数据缓存不一致对比DMA和CPU读到的数据用dma_mmap_coherent吞吐量上不去DMA位宽或时钟不够计算理论带宽增大位宽或提高时钟驱动加载失败设备树节点错误dmesg查看probe错误检查reg和interrupts6. 性能优化与扩展方向6.1 多通道并行DMA的带宽聚合单通道DMA在高速场景下可能成为瓶颈。我的框架支持最多4个DMA通道可以并行工作。比如4个通道各跑100MB/s聚合带宽就是400MB/s。多通道的关键是通道间的仲裁和缓冲区管理。我在DMA控制器里实现了一个简单的轮询仲裁器每个通道轮流获得总线使用权。缓冲区管理上每个通道有独立的缓冲区队列用户态可以分别读取也可以聚合读取。多通道并行的时候要注意FPGA侧的总线带宽。如果多个通道同时访问同一个BRAM或者DDR可能会冲突。解决办法是用多个独立的BRAM块或者用AXI Interconnect做带宽分配。我一般会在Vivado里用AXI Performance Monitor看一下实际带宽利用率如果超过80%就要考虑优化了。6.2 与ROS或者图像处理框架的集成这套框架采集到的数据最终往往要送给上层应用做处理。如果是机器人或者自动驾驶场景通常会集成ROS。Ubuntu 22.04 arm64上跑ROS Noetic是可行的但要注意ROS的安装包要选arm64版本。我一般把hs_dma的用户态库封装成一个ROS节点采集到的数据通过ROS topic发布出去图像数据用sensor_msgs/Image点云数据用sensor_msgs/PointCloud2。如果是图像处理场景采集到的原始数据可能需要做去马赛克、白平衡、伽马校正这些处理。可以在ARM64上用OpenCV做也可以把部分处理放到FPGA里做。FPGA做图像预处理的好处是延迟低、不占CPU但开发复杂度高。我的建议是先把数据采回来在ARM64上用OpenCV验证算法等算法稳定了再考虑往FPGA迁移。6.3 长时间运行的稳定性保障高速采集系统往往需要连续运行几个小时甚至几天稳定性是关键。我在框架里加了几个保障机制一是看门狗如果DMA超过一定时间没有完成中断驱动会复位DMA控制器并重新启动采集二是错误计数FPGA侧统计FIFO溢出次数、DMA错误次数通过状态回传通道定期上报三是日志记录驱动和用户态都会记录关键事件方便事后分析。长时间运行还要注意内存泄漏。用户态程序要确保每次hs_dma_get_buffer都有对应的hs_dma_release_buffer否则缓冲区会被耗尽。驱动里可以用kmemleak或者valgrind做内存检查。我踩过一次坑用户态程序在异常分支里忘了释放缓冲区跑了几个小时后缓冲区耗尽采集直接停了。后来加了RAII风格的封装用goto cleanup统一释放问题就没了。6.4 跨平台移植的注意事项这套框架最初是在Xilinx Zynq平台上验证的后来移植到RK3588加Artix-7的方案。移植的时候主要改几个地方设备树的寄存器地址和中断号、DMA控制器的时序参数、以及用户态库里的平台相关代码。FPGA侧的DMA控制器逻辑基本不用改因为接口是标准的。ARM64和x64的差异主要在内存模型和缓存一致性上。ARM64是弱内存模型需要显式的内存屏障来保证顺序。我在驱动里用了wmb()和rmb()来保证DMA描述符的写入顺序。另外ARM64的页大小可能是4KB或者64KBmmap的时候要注意对齐。如果页大小是64KB缓冲区大小最好是64KB的整数倍否则mmap会失败。7. 我在实际项目中的几点体会这套框架从最初的想法到相对稳定前后迭代了大概一年半。中间踩过的坑不计其数有些是技术问题有些是设计思路的问题。最大的体会是高速数据采集系统的瓶颈往往不在采集本身而在数据搬运和同步。FPGA采集逻辑写起来很快但DMA配置、驱动调试、缓冲区管理这些“脏活累活”才是真正花时间的。另一个体会是调试手段比代码本身更重要。ILA、示波器、逻辑分析仪、ftrace、perf这些工具要熟练使用。很多时候问题不是靠看代码看出来的而是靠抓波形、看日志、做对比实验定位出来的。我建议每个做这块的工程师都花点时间学一下这些调试工具磨刀不误砍柴工。最后说一个小的经验DMA缓冲区的数量不要设太多4到8个就够了。缓冲区太多会增加管理复杂度和内存占用而且用户态处理不过来反而会导致延迟累积。我一般用4个缓冲区每个1MB到4MB根据实际延迟要求调整。如果延迟要求高就减小缓冲区大小、增加数量如果吞吐量要求高就增大缓冲区大小、减少数量。这个平衡点需要根据具体应用来调没有万能公式。