FPGA高速采集Windows平台：XDMA技术实践与性能调优

高速采集板卡调了快两周，数据带宽始终卡在 3GB/s 上下，CPU 占用却飙升到 70% 以上。那时候我才意识到，继续把 FPGA 里的数据用中断方式一点一点搬进 Windows 主机，这条路在高速场景下已经走不通了。后来换成 XDMA 这套基于描述符的 DMA 方案，一路调通之后带宽接近 PCIe 理论上限，CPU 占用也落到几乎可以忽略。这篇内容就把 XDMA 技术在 Windows 平台上的应用实践完整梳理一遍，从控制器工作原理到驱动对接、从多包模式选择到性能调优和排查链路，希望能帮你少走我趟过的弯路。

适合读这篇文章的人，主要是三类：一类是在做采集卡、软件无线电、视频采集这类需要把 FPGA 数据高速搬到 Windows 主机的硬件工程师；另一类是负责 Windows 侧驱动和应用程序的软件工程师，想搞清楚为什么用户态分配的内存 DMA 会失败，中断为什么丢了包；还有一类是刚接触 DMA 场景，想快速判断 XDMA 方案能不能满足自己项目的同学。

1. 高速采集遇上 Windows：为什么 XDMA 成了绕不开的方案

很多人第一次接触 XDMA 技术，是在 Linux 平台，因为 Linux 下有完整的内存注册和用户态映射机制，跑起来相对顺。但实际做产品时，大量工控、医疗影像、测试测量设备的软件生态都在 Windows 上，用户桌面系统、数据后处理插件、UI 工具链全是 Windows 的，这时候就绕不开一个问题：能不能让 FPGA 发过来的高速数据直接高效落进 Windows 系统的用户态缓冲区，同时不让 CPU 成为瓶颈。

传统做法是 FPGA 内部收数据，填满 FIFO 后产生中断，CPU 响应中断后通过 PCIe 读走数据。这个模式在数据量小、速率在几十 MB/s 时没有问题，但到了 GB/s 级别问题集中爆发：读操作不断占用 PCIe 总线，中断频率高到系统响应不过来，CPU 大部分时间空转在中断上下文和内存拷贝上，数据只要稍微有抖动，FIFO 溢出就直接丢包。换句话讲，CPU 变成了搬运工，总线变成了窄门，两头都堵。

XDMA 这类 DMA 控制器方案把思路掉转了。它不再依赖 CPU 逐包搬运，而是由主机侧预先准备好一块内存、填好描述符，DMA 控制器自己通过 PCIe 去访问这块描述符，然后自动完成大块数据搬运。CPU 只在 DMA 完成后收到一个中断或者用轮询方式去看状态位，负载低一个数量级以上。这个思路类似快递柜：以前快递员必须挨家挨户敲门等收件人开门，现在快递员把包裹放进柜子、发个短信就行，收件人有空再去取。

为什么偏偏是 Windows 平台显得更难？因为 Windows 不是为这种实时大块 DMA 场景设计的，它的用户态内存可以被换页、可以被移动（系统把物理页挪走），而 DMA 控制器访问的是物理地址，一旦页面被换到磁盘或者位置变了，DMA 就会写到错误的内存区域甚至触发系统异常。Linux 下常用的内存注册接口可以方便地锁定物理页并拿到物理地址映射，Windows 下这件事分布在驱动层的内存描述符表（MDL）机制里，应用层很难直接感知。所以，把 XDMA 在 Windows 上用起来，不仅是学会配置 FPGA 里的 IP，更重要的是理解 Windows 侧驱动、应用和内存管理三者之间怎么配合。

这里想说的核心结论是：**XDMA 解决的不只是带宽，还顺带解决了 CPU 占用和实时性抖动问题。**但它不是即插即用，你必须搞清楚从 FPGA 到主机应用这条链路上每一环的职责，尤其是 Windows 下那些隐藏的内存和中断细节。下面就从传输架构开始拆。

2. XDMA 的传输架构拆解：描述符搬运与两种接口形态

XDMA 控制器在全链路中的位置很特殊，它一头连着 PCIe 总线，一头连着 FPGA 内部的 AXI 总线。主机软件负责在内存里构建一个或多个环形描述符队列，DMA 控制器则自己沿着 PCIe 去读这些描述符，再根据描述符里的地址信息发起实际搬运。

2.1 描述符环形队列是怎样工作的

描述符结构大致包含：传输方向、目标/源地址、长度、控制位、下一个描述符的地址。主机驱动在初始化时把这些描述符放到一段连续内存里，形成环形队列，然后通过写入寄存器告诉 DMA 控制器“队列起始地址在这、深度是多少”。DMA 控制器硬件会自动从环形队列中取描述符并执行。

这里有个理解关键：**主机的内存既是描述符所在地，也是数据的搬运目标或来源。**也就是说，DMA 引擎不是凭空知道要搬哪块内存，它先通过 PCIe 读回你写好的描述符，再接续访问数据地址。描述符本身也是一个 PCIe 传输事务，所以描述符队列的深度和分布会影响初始化链路，但一旦队列建立，后续数据搬运就几乎不消耗 CPU。我调试时最喜欢看的就是“队列跑起来之后 host CPU 占用变化”，从之前的 70% 直接降到个位数，这种差异特别直观。

描述符深度选择上，我建议不要盲目追求大。描述符太多，蛮占用内存，而且硬件取描述符也有一点延迟；太少又容易在高带宽下出现队列空转。一个比较稳妥的起点是 256 到 512 条描述符，每条描述符对应一个 4KB 到 8KB 的缓冲块，这样环形队列能覆盖几 MB 的数据在途量，配合多包模式通常可以把带宽推满。

2.2 AXI Memory Map 与 AXI Stream 两种接口的选择

XDMA 控制器在 FPGA 内通常有两种数据接口形态，这决定了你在硬件设计和软件编程上的思路完全不同。

如果用 AXI Stream，FPGA 侧一般只需要把数据流接进 DMA 控制器，控制器内部会利用描述符中的地址把流写入主机内存。这种模式下你必须定义好包的开始和结束，否则 DMA 模块无法知道哪一段数据需要对齐到哪一个缓冲块。使用 AXI Memory Map 时，控制更自由，但 FPGA 侧需要额外做地址管理和 DMA 请求逻辑，工作量反而更大。

我在实际项目里更偏向 AXI Stream + 多包模式，因为采集卡的数据天然是连续的流，人工去管理地址反而复杂。关于多包模式，我们在第 4 节单独展开。

2.3 中断与轮询机制的分工

XDMA 控制器支持把每个描述符完成、队列半满、队列全空等事件通过中断通知主机。Windows 平台下最常见的是使用 MSI/MSI-X 中断，因为传统 INTx 线中断在高频场景下容易成为瓶颈。

值得留意的是，中断并非越快越好，中断频率过高会形成所谓“中断风暴”，CPU 一直被中断打断，吞吐反而下降。我在后面的实践部分给出过一个简单策略：先把中断响应路径跑通，再测量中断频率，如果每秒钟超过几十万次并且 CPU 占用异常，就改用轮询状态寄存器或者加长中断聚合窗口。Windows 平台上轮询模式在特定采集场景下效果相当不错，代价是多占一点 CPU，换取整体吞吐稳定。

3. Windows 平台对接要点：锁定内存、映射 BAR 与中断通知

这一节应该是很多软件同学最关心的。FPGA 侧的 XDMA 逻辑再完善，Windows 驱动和应用层对不上，数据照样起不来。

3.1 用户态缓冲为什么不能直接给 DMA 用

如果你在 Windows 应用层 new 了一块数组，把指针传给驱动，驱动是没法直接拿这个地址去发起 DMA 的。因为应用层的虚拟地址经过 CPU 页表转换后才对应物理内存，DMA 控制器访问的是总线地址，两者不是一回事；更致命的是，系统可能随时把这部分页面换出或迁移。

正确的做法是，驱动在收到应用层 IOCTL 时，针对用户缓冲区创建一个 MDL，把相关的物理内存锁在内存中，并且从 MDL 取到物理页信息。对应用层来说，使用时会感觉缓冲区地址没变，但它在物理内存里的存在状态已经被系统记账了，DMA 接口可以安全访问这些锁定的页面。这一步如果没有做，轻则 DMA 数据写到错误位置，重则系统蓝屏。

3.2 DMA 可直接访问的缓冲区分配方式

除了锁定应用层传入的缓冲，也可以直接在驱动里分配 DMA 缓冲。Windows 的 DMA 框架提供了一整套“公共缓冲区”机制，系统保证分配的内存在物理上是连续或满足平台聚合能力的。这种方式对驱动程序实现来说最简单，因为不需要去遍历 MDL 的物理页结构，但一般需要额外限制连续的尺寸，因此公共缓冲区通常用于控制结构、描述符队列，不用于大型数据缓冲。

大型数据缓冲我用得最多的是“先分配可分页的系统内存，再使用 MDL 锁定”这种方式。它的好处是内存管理灵活，应用层也可以直接映射到同一段物理内存。这里有一个容易被忽视的点：DMA 数据到达时，CPU 缓存里可能还存着同一地址范围的旧内容，如果不做缓存一致性处理，DMA 写入内存之后应用层读到的可能是旧数据。正确做法是在 DMA 完成中断处理时，驱动对相应 MDL 调用缓存刷新或失效操作，然后把数据提交给应用层。

3.3 BAR 空间映射与寄存器初始化

XDMA 控制器在 PCIe 设备中一般会暴露若干 BAR。软件要能工作，第一件事就是把这些 BAR 区域映射到自己进程的虚拟地址空间。Windows 下驱动可以做，也可以通过用户态库直接映射。

我习惯在驱动初始化时读取 PCIe 设备配置空间，找到 BAR0/BAR2 这类寄存器和数据通道。BAR 空间里通常包含：DMA 控制寄存器、中断使能寄存器、描述符环形队列头部指针寄存器、状态寄存器等。驱动在打开设备后，写出描述符队列地址和深度，再设置中断使能，DMA 引擎才会真正开始“看”那个队列。

如果发现 FPGA 侧已经在搬数据但主机侧没有任何状态变化，我第一个去查的就是 BAR 映射是否成功、寄存器读写是否正常。很多时候问题不在 DMA 逻辑，而是驱动把地址写成 64 位扩展地址导致 32 位只写了高位或低位，产生“大部分正常但某个通道死掉”的诡异现象。

4. 多包模式与完成队列：实测传输效率的取舍

前面提到我更喜欢 AXI Stream 接采集流，这里必须把多包模式单独提炼出来讲，因为它几乎决定了你在 Windows 侧接收大批短包时的吞吐上限。

4.1 单描述符单包为什么吞吐受限

从最简单模式看，一个描述符对应一个包，包长可能只有几百字节。设想 FPGA 以 2GB/s 的速度连续发数据，每个包 512 字节，每秒要产生 400 万个包。如果每个包都需要一个描述符去承载，描述符读取和提交频率就被拉到一个很高的水平，PCIe 总线需要不停地传送描述符本身，整体效率一定上不去。

这个原理类似“快递盒里的快递盒”——主总线既要搬运实际数据包，又要搬运“描述这些数据包的信息”，信息开销占比一大，有效带宽自然下降。你可能会说那就把包长加大，但这在很多协议里做不到，因为源端就是按固定协议长度发送。

4.2 多包模式下描述符复用同一块缓冲

多包模式的思路是：一个描述符不再是只对应一个包，而是一次性可以对应多个包，在主机侧表现为一个描述符指向一段大缓冲区，包含很多个小包。每个小包的起始由包边界信号（Packet Marker）或专门的元数据位来标记，而不是靠描述符数量来区分。

对 Windows 应用来说，好处很明显：接收缓冲区可以预先申请几 MB 的连续物理锁定内存，描述符数量维持在较低值，包的到达事件不再和描述符一一对应，而是由一个完成队列来表示“这段缓冲里已经装了一批包，可以取走”。这样既降低了中断频率，又减少了描述符存取次数。

实际工程里，我常用的配法：主机侧预先分配 8MB 的非分页缓冲，分成 64 个描述符块，每块 128KB，每块里能装 64 个 2KB 的包。这个配置不是随便拍的，是根据项目数据率和包长反推出来的。假设突发到达速率是 3GB/s，包长 2KB，那么主机侧必须有足够深的缓冲来吸收抖动，否则即便 DMA 理论带宽够，应用层处理小包时稍微慢了一点，缓存就溢出。要为自己项目算一个合理的“在途字节量”，至少要覆盖目标带宽乘上最差处理时延，再放大 1.5 到 2 倍。

4.3 完成队列通知与应用层消费节奏

多包模式下，驱动完成中断后会把“已接收包的数量”和“缓冲区索引”通过完成队列交给应用层。应用层不要在每次收到事件后立刻把所有数据都拷贝走，这会把你拉回搬数据的老路，而是采用双缓冲甚至多缓冲的流水线方式：一块缓冲正在被 DMA 填充，另一块缓冲由应用层处理；二者交替使用。

这个节奏在 Windows 平台上最影响性能。如果处理线程做得太重，比如在中断通知到达后进行文件写入或界面刷新，下一块缓冲 DMA 还没开始，链路就会有空洞。我建议至少准备三块环形缓冲：一块正在写、一块正在读、一块空闲等待，应用层线程只在事件触发时处理“完成的一块”，不阻塞硬件填充。

5. 我在 Windows 上踩过的三个问题及完整排查链路

纸上谈兵讲得再多，还是比不上一堆真实的问题级感受。这一节写我在和 XDMA 配合的 Windows 工程里踩过的三个坑，每个都给出排查链路，你可以照着这个思路去复现。

5.1 问题一：环回自测过了，业务数据一上来就丢包

现象很典型：单独跑 1KB 的环回测试，数据吞吐正常；一连接采集业务，Windows 下接收程序跑起来就丢包，而且丢包没有规律。

我当时没有直接去改 DMA 配置，而是按链路逐级排查。第一步，在 FPGA 内做计数器，确认真实数据速率是否超过预设的保险值。第二步，在驱动收到的 DMA 完成中断位置直接记录计数，如果这里计数就丢，问题在内存和中断；如果这里计数正常，丢包发生在用户态拷贝，问题在应用层处理速度。第三步，把应用层处理逻辑临时注释掉，只保留事件计数，观察是否持续丢包。

实测下来，驱动中断计数是完整的，但应用层消费不及时。究其原因，是应用层拿到缓冲后做了内存拷贝和界面刷新，处理时间超出预期，导致缓冲队列排满，DMA 控制器发现没有空闲缓冲或描述符时就直接丢弃后续数据。解决方法有两个方向：一是把业务处理改到独立线程，队列里只转指针；二是增大缓冲深度和描述符数量。最终采用了双管齐下，丢包问题大幅缓解。

5.2 问题二：MSI-X 中断频繁吞吐反而下降

另一个印象深刻的问题是，中断开启后吞吐非但没有提高，反而比轮询模式还差。我用性能计数器观察到一个很反常的现象：中断模式下 CPU 总占用率不高，但 DPC 占用曲线有明显尖峰，而且吞吐有周期性下跌。

排查到后面发现中断被分配到了多个 CPU，但所有数据包又需要由同一个 DMA 描述符队列管理。跨核频繁调度导致缓存命中率下降，DPC 处理被不断打断。这里用到了 Windows 的中断亲和性配置，将特定 MSI-X 中断绑定到固定的两个核心，避免它到处乱跳。绑定之后 DPC 尖峰消失了，吞吐恢复了稳定。

这个经验提示：不要觉得中断模式一定比轮询好，**中断的核心价值是省 CPU，前提是中断处理足够轻且分散合理。**如果你的 Windows 平台对吞吐稳定性要求高，轮询模式往往是一个被低估的选项。轮询模式下，驱动在定时任务里直接读 DMA 状态寄存器，不需要中断，省去了 DPC 上下文切换，市卫在某些场景实测吞吐比中断模式高 10%-15%。

5.3 问题三：系统随机蓝屏，指向非分页内存压力

第三个问题是系统长时间运行后随机蓝屏，错误指向某个驱动模块。用内存调试工具看完崩溃转储文件，问题并不是某一行代码写错，而是 DMA 缓冲分配方式本身。

早期我为了图省事，在驱动里用公共缓冲区为每个通道分配了较大空间，公共缓冲区一般来自非分页内存池的非连续页，物理连续性不强。DMA 控制器如果被配置成需要连续地址，然后驱动又只取了首地址加长度，后续内存跨越了很多不连续页面，DMA 访问到不存在的页面映射就会触发总线错误甚至系统崩溃。

修复方式是把公共缓冲区只用于描述符这类小结构，数据缓冲改用 MDL 锁定用户缓冲或其他一致性内存方式，同时确认 DMA 通过分散/聚集链表访问物理页集合。这之后蓝屏不再出现。

这个问题的排查链路特别值得记录：蓝屏先看转储里崩溃的驱动名字——接着看 DMA 地址访问的位置是否落在非法的物理页——再到分配缓冲的地方去检查是公共缓冲还是 MDL。大多数这类问题不是“代码逻辑错”，而是“内存类型选错”。

6. 一次性能调优的配置记录：从带宽上不去到接近 PCIe 上限

如果说前面几节是在讲方法和原理，这一节就是一次完整性能调优的具体记录，我把配置前后的差异和我自己的推断都写出来，你可以拿来做参照。

6.1 初始配置与性能瓶颈

当时板卡使用 PCIe 3.0 x8 通道，理论单向带宽约 7.8GB/s。初始配置如下：AXI 总线位宽 256bit，工作时钟 250MHz，描述符队列深度 128，单描述符单包模式，包长 4KB，中断模式开启。实测结果是：DMA 读方向（FPGA 到主机）约 3.2GB/s，写方向约 2.7GB/s，距离理论值差距很大，而且中断模式下 DPC 处理时间占比一度超过 30%。

第一轮性能排查发现，单描述符单包模式浪费了大量描述符周期。128 个描述符只能覆盖 512KB 在途数据，当 PCIe 上延迟变高、链路拥堵时，描述符队列很容易空转。简单说就是“填描述符的速度追不上数据到达速度”。

6.2 调优后的配置清单

改了之后，读方向带宽从 3.2GB/s 提升到 5.6GB/s，写方向接近 4.9GB/s。CPU 占用率从 30% 降到约 5%，DPC 尖峰消失，整体稳定性明显提高。为啥没有达到 7.8GB/s 理论值？因为 PCIe 协议本身也有开销，包括 TLP 头部、数据完整性字段、流量控制与 ACK/NAK，另外 FPGA 侧 AXI 时钟和数据产生模块也有瓶颈。实际工程中做到理论值的 70%-80% 就是不错的成绩，剩下的空间往往要靠更深层次的流水线优化去挖。

6.3 调优过程的细节经验

这里分享几个我认为最有用的细节。第一，修改描述符深度后，PCIe 总线上的读请求宽度会变化，如果 BAR 空间的寄存器没有正确设置高位地址，多半会出现“前几个描述符正常，后面全乱”的情况，排查时一定要先确认寄存器写入是不是完整 64 位。第二，多包模式不是无条件的，它要求主机侧必须清楚每个包的起点。如果数据包里带有有效的包序号或长度字段，应用层解析会更安全；如果数据流本身没有包边界，强行用固定长度切包会有隐患。第三，Windows 平台的内存锁定一定要区分“物理连续性”和“虚拟连续性”：VC++ 一个大数组在虚拟地址上连续，不代表物理内存连续；DMA 需要的是物理地址层面可描述，不是软件层面的地址连续。这个误解非常常见，几乎每个接手的人都踩过。

写在最后

从最初被中断搬运模式折腾到怀疑人生，到后来把 XDMA 跑通并稳定在 GB/s 级别，我感觉最难的不是硬件逻辑怎么配，而是把“PCle 事务、描述符队列、Windows 内存管理、应用层消费节奏”这几条线理顺。只要先想清楚数据从FPGA到应用内存的完整路径中每一跳由谁负责做什么，再一个一个环节去测，问题基本都能定位。如果你正在做类似的高速采集板卡和 Windows 端配套开发，建议先把“描述符队列深度、多包开关、中断亲和性、缓冲分配方式”这四个参数写进项目设计文档，别让后边的人再跟我一样从头试一遍。