Synopsys PCIe 2.0 DMA驱动：从BAR映射到4Gbps带宽实现

简介面向 PCIe 驱动开发与 SoC 设计验证工程师这份基于 Synopsys PCIe 2.0 IP 的 DMA 驱动实现包实测传输速率可达 4GB/s完整呈现设备初始化、DMA 引擎配置、数据传输、中断处理与错误处理的底层驱动流程并附带 TDD 测试驱动开发文档帮助读者理解先写测试再实现驱动的工程方法。包内共 174 个文件以 v、cpp、c、h 等源码文件为主辅以 xst、ucf 等综合约束文件以及 dll、sys、exe 等编译产物和脚本、配置文件压缩包约 18.02MB。目录中 DriverMgr 工程、xilinx_pci_exp_1_lane_epipe_ep_v19.bit 配置比特流与 s3_1000.c、pnp.c、xbmd.c 等模块可对照学习 PCIe IP 初始化、即插即用与 DMA 数据通路实现包内另有驱动安装脚本、makefile、def 等构建链接配置以及 sln/vcxproj 工程入口和 txt 说明文档便于复现编译环境、按模块检索二次开发。目前已有 459 人学习适合正在基于 Xilinx/Synopsys PCIe IP 开展驱动开发希望通过完整工程、测试文档与实际测试数据快速上手的中高级开发者。1. 基于Synopsys PCIe 2.0的DMA驱动为什么4Gbps是一个真实可达的目标把一块带Synopsys PCIe 2.0核的FPGA卡插到服务器上写一个Linux字符驱动通过DMA把高速采集数据搬进主机内存这是非常典型的一线开发任务。标题里的“4G”按有效载荷吞吐4Gbps理解约等于每秒500MB这个数字并不夸张——在x1链路上它接近协议上限在x2或x4链路上则给TLP开销和中断处理留了余量。对正在被枚举失败、数据错位、速率跑不动纠缠的驱动工程师来说这篇内容会把Synopsys核先当成一块需要摸清BAR和中断能力的硬件再从描述符环一路写到最小传输序列最后落在调试手段和参数选择上。适合FPGA数据采集、高速存储和网络加速场景也适合刚接手PCIe设备的Linux驱动开发入门者照着复现。2. 动手前先摸清Synopsys PCIe 2.0核的边界BAR布局、链路带宽与中断选择拿到一个Synopsys PCIe 2.0核先分清楚三件事协议层、DMA引擎和寄存器窗口。协议层负责建链和TLP收发DMA引擎在这个核里多半不在Synopsys协议栈内部而是挂在AXI主接口外部的用户逻辑寄存器窗口则通过BAR映射给驱动访问。很多新手一上来就翻寄存器手册找DMA控制位结果翻遍协议层寄存器也找不到就是因为没先确认这三块的分工。2.1 从BAR布局开始驱动如何找到DMA引擎的寄存器窗口在Linux里BAR信息已经由PCI子系统帮你解析好了。驱动要做的是把这些资源打印出来确认哪一BAR是配置空间、哪一BAR是DMA引擎控制区。常见做法是枚举一遍所有BAR看长度和映射关系是否和IP配置时一致for (int i 0; i PCI_STD_NUM_BARS; i) { if (pci_resource_len(pdev, i) 0) continue; dev_info(pdev-dev, BAR%d: start%pa, len%pa\n, i, pdev-resource[i].start, pdev-resource[i].end); }这段代码不做事只做侦察。pci_resource_start返回的是CPU物理地址pcim_iomap之后才能用readl/writel访问。在我做过的Synopsys PCIe 2.0工程里BAR0通常分配给配置和状态寄存器BAR2留给DMA控制窗口但这不是定规——每个工程的IP配置界面都可能调整映射。你要做的是打开IP生成工具导出的寄存器手册对照BAR长度去推断窗口里每个块的位置。映射操作一般是void __iomem *io_base pcim_iomap(pdev, 2, pci_resource_len(pdev, 2)); if (!io_base) return -ENOMEM;注意一个坑不要用普通内存指针去访问MMIO。有些驱动图省事把BAR地址强转成结构体指针在x86上偶尔能跑到了ARM上就会遇到设备树和内存序的问题。readl/writel和ioread32/iowrite32才是正经做法。2.2 链路宽度与带宽上限4Gbps放在哪条链路上才合理在写驱动之前你得先算一笔账PCIe 2.0单通道的原始信号速率是5GT/s经过8b/10b编码后符号速率是4Gbps再扣掉TLP包头、LCRC和链路管理报文一条x1通道能搬的用户有效载荷大约在3.2到3.7Gbps。所以标题里的4Gbps如果指的是x1链路那基本是贴着协议封顶跑的如果用的是x2或x4它只是一个偏向保守的目标值。链路宽度原始信号速率编码后符号速率256B MPS下有效载荷上限4Gbps占上限比例x15GT/s4Gbps约3.2–3.7Gbps接近满速x210GT/s8Gbps约6.4–7.3Gbps约55%–63%x420GT/s16Gbps约12.8–14.6Gbps约27%–31%这张表的价值在于定位问题。如果驱动只能跑到1.5Gbps而链路明明是x4瓶颈大概率不在协议层如果链路是x1那4Gbps已经是结果而非问题。在Ubuntu上看链路速率最直接的方式是lspci -vvv找LnkCap和LnkSta两行前者是设备能力后者是当前协商结果。我常在客户现场用这个命令先排除“链路只协商到x1”的嫌疑。2.3 中断路径INTx换MSI是提高吞吐的第一步对DMA驱动来说中断处理是数据通路的组成部分。INTx是共享电平中断所有设备挤在一根线上中断来了一段还要逐个读状态寄存器判断归属在多核机器上往往被固定送到一个CPU上。MSI把中断变成内存写事务直接发给指定CPU的本地APIC还能用系统里的irq affinity做负载均衡。Synopsys核一般同时支持INTx和MSI。驱动侧推荐优先申请MSIint nr pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSI); if (nr 0) dev_warn(pdev-dev, MSI not available, fallback to INTx\n); int irq pci_irq_vector(pdev, 0);这段代码只申请了一个向量够DMA完成通知用了。不建议在驱动刚起步时就上MSI-X多队列先把单队列跑稳再考虑把多个描述符环绑定到不同CPU上。提示申请MSI的时机要放在pci_enable_device之后、request_irq之前描述符环初始化完成后才挂中断处理函数。3. 描述符环设计让DMA引擎按你的内存布局工作DMA引擎认的不是你代码里的struct而是物理内存里的一段连续区域。驱动负责把这段区域组织成硬件能看懂的结构并且和DMA引擎约定好谁写头指针、谁写尾指针。这一步没做对后面所有带宽优化都是空中楼阁。3.1 DMA描述符结构最少字段和字节顺序不同Synopsys工程的DMA描述符字段有差异但一套能跑的描述符至少需要源地址、目的地址、长度、控制字和状态字。我常用的是这个结构struct dma_desc { __le32 src_addr_lo; __le32 src_addr_hi; __le32 dst_addr_lo; __le32 dst_addr_hi; __le32 len; __le32 ctrl; /* bit0: valid, bit1: irq_en, bit2: last */ __le32 status; /* DMA 完成后硬件回写 */ __le32 reserved; } __packed;关键在两点所有字段用__le32因为PCIe是小端总线这个结构在x86上无所谓但代码一旦跑到ARM或其他大小端架构漏掉__le32就会让地址被解释反了第二个是__packed结构体不能有填充字节。控制字里的valid位是所有权交接的关键。驱动把描述符内容写好后置valid1DMA引擎看到有效描述符就搬运搬完清掉valid并回写status。驱动下次要复用这个描述符前必须等硬件把valid清成0。3.2 初始化描述符环用dma_alloc_coherent还是dma_map_single描述符环本身是驱动和硬件共享的内存两边都会读写分配时我用dma_alloc_coherent而不是kmalloc加dma_map_single。原因是一致性DMA内存默认不做cache同步驱动写描述符后不需要手动刷新cache硬件写回状态后驱动也不需要失效cache。省掉这两步就少了一半DMA同步的坑。static int dma_ring_init(struct dma_chan *ch, struct pci_dev *pdev) { size_t ring_size RING_DEPTH * sizeof(struct dma_desc); dma_addr_t ring_phys; ch-ring dma_alloc_coherent(pdev-dev, ring_size, ring_phys, GFP_KERNEL); if (!ch-ring) return -ENOMEM; writel(lower_32_bits(ring_phys), ch-io DESC_BASE_LO); writel(upper_32_bits(ring_phys), ch-io DESC_BASE_HI); writel(RING_DEPTH - 1, ch-io DESC_RING_LIMIT); return 0; }RING_DEPTH取2的幂比如256或512这样驱动计算下一个描述符下标时能用位与运算代替取模。硬件需要三个参数描述符基地址的低32位、高32位和环深度。地址必须是总线地址不能用CPU虚拟地址也不能直接拿__pa()转换的物理地址——在有IOMMU的环境下总线地址和物理地址可能不一致。描述符环分配好了真正的数据缓冲区还得单独处理。数据缓冲区是流式映射每次传输前用dma_map_single传输完成用dma_unmap_single方向和DMA实际搬运方向保持一致dma_addr_t buf_dma dma_map_single(pdev-dev, cpu_buf, len, DMA_FROM_DEVICE);FPGA往主机内存搬数据时方向是DMA_FROM_DEVICE把数据交给网卡发送时才用DMA_TO_DEVICE。方向写反的典型症状是数据在cache里还是旧的怎么读都不对。3.3 环的管理模型生产者消费者和valid位描述符环本质上是生产者消费者模型。驱动是生产者往环里填描述符并推进写指针DMA引擎是消费者从环里取描述符执行搬运。Synopsys核一般通过一个“门铃寄存器”doorbell通知硬件有新描述符。我习惯在驱动里维护两个下标u32 head; /* 下一个可用的描述符 */ u32 tail; /* 下一个待检查完成的描述符 */驱动提交描述符时用head定位写完valid位后写门铃中断处理时对照硬件回写的完成指针推进tail。两个下标用不同变量保存避免在同一个变量上发生竞争。这里最容易犯的错是写完描述符内容后直接写门铃忘了加内存屏障。CPU对普通内存的写可能被重排DMA引擎拿到门铃时描述符还没落到内存里。正确的顺序是写完描述符字段后执行wmb()再置valid位最后写门铃。这个顺序在ARM和x86上行为不同但加屏障永远是安全的做法。4. 打出4Gbps的驱动实现最小传输序列与带宽参数到了真正写submit函数的环节。一个DMA传输从驱动角度看就是“把一块数据从FPGA侧搬到主机内存或者从主机内存搬到FPGA侧”。下面这套代码是抽象过的最小序列寄存器名用宏定义替换成你自己工程的寄存器名就能用。4.1 提交一次DMA传输从描述符到门铃#define DESC_BASE_LO 0x1000 #define DESC_BASE_HI 0x1004 #define DESC_RING_LIMIT 0x1008 #define DOORBELL 0x100C #define DESC_VALID BIT(0) #define DESC_IRQ_EN BIT(1) #define DESC_LAST BIT(2) static int dma_submit(struct dma_chan *ch, dma_addr_t src, dma_addr_t dst, size_t len) { u32 idx ch-head; struct dma_desc *d ch-ring[idx]; d-src_addr_lo lower_32_bits(src); d-src_addr_hi upper_32_bits(src); d-dst_addr_lo lower_32_bits(dst); d-dst_addr_hi upper_32_bits(dst); d-len len; wmb(); /* 先把描述符写入内存 */ d-ctrl DESC_VALID | DESC_IRQ_EN; writel(idx, ch-io DOORBELL); ch-head (idx 1) (RING_DEPTH - 1); return 0; }逻辑很简单填描述符放内存屏障置有效位敲一次门铃。门铃寄存器有的是写当前head有的是写一个计数累加值要看寄存器手册里怎么定义。这里要强调wmb()的位置。如果你把它放在写ctrl之后硬件可能已经看到ctrl里的valid位为1但源地址字段还在CPU的写缓冲里没落地DMA引擎就会读到一个地址不全的描述符。这个坑在x86上出现概率低在ARM上很常见。4.2 完成处理读完成指针别在硬中断里做重活DMA完成后硬件要么清掉描述符的valid位要么回写一个完成指针寄存器。我用后者因为读一个寄存器比扫描环里256个描述符的状态快得多。static irqreturn_t dma_isr(int irq, void *dev_id) { struct dma_chan *ch dev_id; ch-done_idx readl(ch-io CPL_INDEX); writel(1, ch-io INTR_CLEAR); return IRQ_WAKE_THREAD; } static irqreturn_t dma_isr_thread(int irq, void *dev_id) { struct dma_chan *ch dev_id; if (ch-done_idx ! ch-acked) { /* 批量通知等待中的用户态读操作 */ ch-acked ch-done_idx; wake_up_interruptible(ch-wq); } return IRQ_HANDLED; }IRQ_WAKE_THREAD把工作挪到线程上下文硬中断里只读一个寄存器和清中断这是让带宽不掉的关键。有些驱动把数据拷贝也放在硬中断里一旦传输块小、频率高CPU就在中断上下文里耗尽时间片用户态程序反而抢不到CPU。完成指针的处理要留意done_idx是硬件回写的绝对序号不是环内下标。驱动拿它和acked比较差值就是这批新完成的数据块数量。用绝对序号而不是下标可以避免环回绕时无法区分“空”和“满”。4.3 三个必调的带宽参数MPS、MRRS和中断合并代码跑通后先别急着测带宽把下面三个参数调完再测否则你会怀疑DMA引擎有问题其实只是配置没到位。参数推荐值作用常见错误Max Payload Size256BPCIe 2.0允许最大TLP有效载荷减少包头开销占比默认128B带宽损失约8%Max Read Request Size512B或1KB一次读请求可以拿回的数据量对FPGA侧读主机内存影响大设为128B读延迟淹没带宽完成中断粒度每批最后一条描述符才开IRQ减少中断频率降低CPU开销每个描述符都开中断CPU被IRQ打爆第一项用pcie_set_mps()改第二项用pcie_set_readrq()改。注意这两项不是驱动单方面能定的端点和根复合体要协商一致。pcie_set_mps内部会做能力检查如果返回值是负多半是对方不支持更大的值先查对方的Device Capabilities寄存器。第三个参数在描述符控制字里控制不是全局寄存器。在批量提交时只有最后一条描述符置IRQ_EN前面的只置VALID。4KB的传输拆成16条256B描述符16次搬运只来一次中断CPU占用率立刻降一个量级。提示调MPS和MRRS要在pci_enable_device之后、开始DMA传输之前执行驱动运行过程中改这两个值可能触发链路重训反而掉带宽。5. 移植踩坑记录Synopsys PCIe 2.0 DMA驱动的五个常见问题这一章是全篇最值钱的部分。以下问题都是从“现象→原因→解决”三个角度展开按我见过的频率排序。5.1 现象驱动加载成功第一次DMA传输就超时现象是probe正常、中断号也申请到了但submit之后等不到完成中断寄存器读回来是超时。原因是PERST时序问题。FPGA侧的PCIe核在上电后需要满足复位释放时序主机RC如果释放PERST太早FPGA内部逻辑还没准备好链路建不起来。驱动看到的是寄存器能写能读其实链路状态机根本没跑到L0。解决方法是两步走先在驱动里读链路状态寄存器确认LinkUp再初始化DMAu16 lnksta readw(io_base LINK_STATUS_OFFSET); if (!(lnksta LINK_STA_UP)) return -ENODEV;再检查FPGA侧的PERST信号确保从电源稳定到PERST释放至少间隔100ms。PCIe规范对这个时序没有统一的严格要求但大量FPGA核手册都要求这么给。5.2 现象DMA搬回的数据错位一个Cache Line现象是前4KB正确从第二个4KB开始每个块的开头都重复了上一块的结尾数据。原因是数据缓冲区没有做Cache Line对齐。DMA引擎按Cache Line大小搬运或者主机侧CPU在DMA写入期间因为cache管理策略产生了伪共享。缓冲区起始地址和长度都要按L1 Cache Line大小对齐通常是64字节。解决方法是分配缓冲区时显式对齐struct page *pg alloc_pages(GFP_KERNEL | __GFP_ZERO, get_order(ALIGN(len, 64)));如果缓冲区是从用户态通过mmap映射进来的那在驱动里要做一次dma_map_single并用sg表管理不能直接拿用户指针当总线地址。5.3 现象怎么调都只有1.5Gbps离4Gbps差一大截现象是带宽稳定但数值低换驱动版本、关闭中断都不见好转。原因是EP侧没有把MPS和MRRS协商到预期值。很多FPGA的Synopsys核配置界面里默认把Max Payload Size设为128B驱动里pcie_set_mps想设256但EP能力位里根本没声明支持256B协商退回到128BTLP开销一下子把有效带宽吃掉接近两成。解决方法是先确认协商结果sudo lspci -vvv | grep -E LnkCap|LnkSta|DevCap|DevSta重点看MaxPayload 128 bytes还是256 bytes。如果是128去FPGA工程的PCIe IP配置界面里把Device Capabilities Max Payload Size改成256重新生成比特流。驱动侧再配合pcie_set_mps(pdev, 256)带宽通常立竿见影。5.4 现象传输不丢数据但CPU占用率100%中断风暴现象是吞吐量有3Gbps但top一看si软中断占了多个核网络协议栈还没介入CPU就不够用了。原因是每个描述符都开了中断4KB数据拆成16个描述符就来16次中断。在中断频率高的情况下CPU把时间都花在进出中断上下文上。解决方法是中断合并。每批传输的最后一条描述符才置IRQ_EN前面的描述符只置VALID如果硬件不支持按描述符控制中断就在驱动里加一个定时器兜底比如每毫秒检查一次完成指针配合中断一起驱动完成队列。5.5 现象设备重启后初始化失败必须断电再上电现象是驱动卸载重装没问题但整机reboot之后设备找不到了或者枚举出来但DMA始终不工作。原因是主机复位时PCIe链路经历了热复位或链路禁用FPGA侧Synopsys核的配置空间丢了用户逻辑的DMA引擎复位状态没有恢复。驱动probe时读到的BAR还在但DMA引擎的寄存器区已经回到默认值。解决方法是驱动里增加一个“复位后重新初始化”的完整路径不能只做pci_enable_device就继续用旧的io_base。要把描述符环基地址、长度、中断使能全部重新写一遍并且在写之前先做一次软件复位确认DMA引擎回到IDLE状态writel(0x1, ch-io SOFT_RESET); while (readl(ch-io SOFT_RESET) 0x1) msleep(1);6. 把4Gbps变成可复现数字测速方法与后续提速习惯6.1 测速口径不要靠感觉判断带宽验证驱动是否达标要建立一套固定口径的测试方法。我最常用的是大块连续搬运配合用户态计时。驱动在read(2)入口记录起始时刻完成指定大小的搬运后记录结束时刻带宽就是字节数除以耗时。测试命令用dd就够dd if/dev/dma_dev0 of/dev/null bs16M count128bs16M是为了让单次read申请大块缓冲区减少用户态和内核态切换次数count128共2GB数据足够覆盖PCIe链路缓存和CPU调频带来的波动。测完再比较dmesg里驱动打印的累计搬运字节数如果dd报告的数据量和驱动记录的不一致先查描述符有没有丢再谈带宽。6.2 两个持续提速的习惯第一个习惯是绑中断亲和性。MSI向量申请成功后把中断绑定到和传输业务同一个NUMA节点上的CPU能显著降低cache miss。更彻底的做法是用irq_set_affinity_hint配合cpumask_set_cpu实现。第二个习惯是放大单次搬运粒度。同样4KB数据拆成一条描述符和拆成四条256B描述符TLP开销差别很大。在描述符len字段允许的前提下尽量让单条描述符承载2KB以上数据配合MPS256让每个TLP都满载。这个改动不需要动硬件只改驱动里拆分逻辑的阈值。我自己的习惯是每次拿到新板子先跑一次最小传输确认链路状态再调MPS和MRRS最后才考虑中断合并和亲和性。这套顺序帮我少踩了大半无效调试的坑希望帮到你。本文还有配套的精品资源点击获取