FPGA作为Root Complex：AXI转PCIe核的实战调试与枚举指南

做FPGA的兄弟，应该都有过类似的经历：看着一本几百页的IP手册，照着官方例程把工程跑起来，心里挺美，结果一到自己的板子上、自己的场景里，各种链路不up、地址不通、中断不触发的问题就全冒出来了。尤其是 PCIe 这种协议栈深的接口，调试起来比普通逻辑费劲得多。

这篇要聊的就是 Xilinx 的AXI Memory Mapped To PCIe核，重点放在FPGA 作为 Root Complex（RC）模式下的使用。咱们先把话挑明：这个模式不是给做PC加速卡的兄弟用的，而是给那些想让 FPGA 去主动控制、访问下游 PCIe 设备（NVMe SSD、网卡、视频采集卡，甚至另一块 FPGA）的人准备的。你不需要在板子上跑 Linux 或 Windows，不需要一颗强大的处理器，FPGA 自己当主机，这个 IP 负责把 AXI 协议翻译成 PCIe 事务，再帮你去枚举和管理下游设备。

官方例程能帮你把链路跑起来，但离「能实战」还有一段距离。这篇文章我会把从例程到实战这条路走一遍：参数怎么看、例程结构怎么读、初始化该做什么、问题排查从哪里下手。适合已经会基础 Vivado 操作、但对 PCIe 跨协议桥还一知半解的工程师。我的经验是，只要把地址映射和链路状态这两个命门抓住，RC 模式真没那么玄。

1. 这个核到底解决什么问题：先从 RC 模式说起

很多刚接触 FPGA PCIe 的朋友，一上来就掉进一个惯性思维：PCIe 嘛，不就是把 FPGA 当成一个 PCIe 板卡，插到电脑主板上，让 CPU 来读写我？这是 Endpoint（EP）模式的经典玩法，官方例程里 80% 都是这个场景，所以大家先入为主很正常。

但现实里有一类需求完全反过来：我的系统里没有通用 CPU，或者我不想让 CPU 掺和进来，而是想让 FPGA 自己作为主机，主动去访问外部的 PCIe 设备。比如，你要做一套 NVMe SSD 控制器，FPGA 要直接对固态盘发命令、搬数据；又比如，你想让 FPGA 作为数据中转站，把一块 PCIe 网卡收到的数据流直接处理后再发出去；再比如，用两块 FPGA 板卡通过 PCIe 互联，一块当主、一块当从，主端就得走 RC 模式。这些场合下，FPGA 的角色是 Root Complex，是整个 PCIe 系统的领导者。

1.1 RC 和 EP 的本质区别：谁说了算

RC 和 EP 最大的区别不在于速度，而在于总线上谁主导。

在 EP 模式下，FPGA 是被枚举的对象。外部主机上电后会去扫描 PCIe 总线，读 FPGA 的 Vendor ID、Device ID、BAR 空间，然后给 FPGA 分配地址，之后双方便通过这个地址窗口通信。FPGA 那边通常只需要提供一个 AXI Slave 接口，被动接收读写请求就行。

在 RC 模式下，FPGA 变成主动方。它要去扫描下游设备，读它们的配置空间，判断设备类型、能力、BAR 大小，然后决定把设备的地址空间映射到哪个位置。这个过程叫枚举，以前是主板上 BIOS 或操作系统干的活，现在全部落到你 FPGA 的逻辑里。更关键的是，RC 模式下 FPGA 需要一个 AXIMaster 接口，主动向设备的地址空间发起读写请求，这是和 EP 模式最直观的差异。

一句话总结：EP 模式下 FPGA 是「被访问的」，RC 模式下 FPGA 是「访问别人的」。很多朋友在 RC 模式上卡壳，就是因为思维还没转换过来，总想着等外部主机来配，结果发现根本没主机来配它。

1.2 官方例程的定位：够用，但只是起点

Xilinx 的AXI Memory Mapped To PCIe核（新版 Vivado 里可能显示为 AXI PCIe）在生成 IP 时往往会提供一个 Example Design。这个例程绝大多数是以 PIO（Programmed I/O）为主，核心逻辑就是一小段状态机，响应外部主机通过 BAR 发过来的读写请求。链路起来之后，主机能读回你的寄存器数据，例程就算验证通过了。

但问题是：这个 PIO 例程默认的模式是 Endpoint，不是 RC。如果你的项目确实是 RC 模式，你会发现例程能给你提供的帮助主要在两块：第一是完整的 PCIe 物理层和事务层集成，告诉你 REFCLK 怎么接、复位怎么拉、AXI 接口怎么暴露；第二是跑通一条最基础的 TLP 通路，让你知道链路起来了是什么样子。但「如何主动发起配置访问去枚举下游设备」「如何把下游设备的 BAR 映射到自己的 AXI 地址空间」这些真正属于 RC 应用的糖和肉，例程里基本不会替你做好。

这就是为什么很多人在官方例程上栽跟头：例程跑通了，以为万事大吉，结果一换到 RC 模式，连基本的枚举都做不出来。我的建议是，拿到例程先别急着跑，把它当成一本「接线说明书」和「时序参考手册」，重点看 IP 例化、时钟复位、AXI 接口的握手逻辑，然后在此基础上自己写 RC 相关的初始化控制逻辑。

1.3 核心组成：M_AXI、S_AXI 和配置管理接口

搞清楚这个 IP 的接口分工，是理解整个设计的第一步。AXI Memory Mapped To PCIe核在接口上大体分三块：

• M_AXI（AXI Master 接口）：用来主动发起 PCIe 事务。RC 模式下，你通过它去读写下游设备的 BAR 空间；EP 模式下，它通常用来访问主机内存（DMA 场景）。
• S_AXI（AXI Slave 接口）：当外部主机访问 FPGA 的 BAR 空间时，请求会从 S_AXI 进来。RC 模式下这个接口依然存在，主要接收来自下游设备方向的请求（比如中断消息、特殊访问），只是使用频率比 EP 模式低。
• 配置管理接口：在部分 7 系列和后续 IP 中，RC 模式会提供一个额外的配置访问途径，用户逻辑或软核可通过 AXI 接口去读写 PCIe 配置空间，这是实现枚举的关键。

调试的时候，很多人一上来就盯着 M_AXI 发数据，发现数据死活出不去。原因往往就是没搞清：RC 模式下第一步不是发数据，是先去枚举——通过配置管理接口，把总线上有哪些设备、它们的 BAR 空间在哪里全部搞明白，之后 M_AXI 发出去的数据才有地方可去。顺序错了，后面全乱。

2. 动手前必须吃透的参数配置：IP 核配置逐项拆解

Axi Memory Mapped To PCIe 这个 IP 的参数不算少，但在 RC 模式下真正决定你后面能不能顺利调通的关键参数，其实就那么几个。我按「先物理层、再事务层、最后应用层」的顺序，逐个过一遍。

2.1 链路参数：速率、宽度和参考时钟

打开 IP 配置界面，第一步要面对的就是 PCIe 链路配置。

• 设备/端口类型：这里是你 RC 应用的第一个分岔口。例程默认通常是 Endpoint，记得改成 Root Complex。选错的话，IP 的管脚行为、配置空间逻辑会完全不同，而且硬件上已经接死了链路两端主从关系，软件改不回来。
• 链路速率和宽度：这个要看你板卡上的 PCIe 物理连接。是 x1、x4，还是 x8？是 Gen2（5GT/s）还是 Gen3（8GT/s）？不是越大越好，而是要和你的参考时钟、PCB 布线、金手指连接保持一致。我见过有人把 x8 的板卡配置成 x4，导致实际带宽减半，后面调性能时怎么都上不去，最后才发现是配置和硬件不匹配。
• 参考时钟：板子上的 REFCLK 必须给到 IP 对应的时钟管脚，频率一般就是 100MHz 差分对。很多链路不起振的问题，查到最后要么是 REFCLK 没接、要么是频率不对。这里有个非常容易忽略的点：有些高集成度板卡的 REFCLK 是由 PCIe 插槽提供的，有些是自己板载晶振，上电顺序也可能影响 REFCLK 稳定，调试时一定要先在示波器上确认 REFCLK 波形干净且持续。

链路宽度和速率的选择直接影响后续的 AXI 带宽计算，别拍脑袋选，先看硬件。

2.2 AXI 侧参数：位宽、时钟频率与带宽匹配

IP 生成的时候会让你选 AXI 接口的数据位宽和用户时钟频率。常见的有 64 位、128 位和 256 位，时钟频率通常可选 125MHz、250MHz 等。这里有一个非常实用的计算公式：

PCIe 理论带宽 = 链路速率 × 链路宽度 ÷ 8（编码开销另算）

以 Gen3 x8 为例：8GT/s × 8 lane ÷ 8 = 8GB/s，这是物理层总带宽，实际有效带还要扣除帧开销和控制字符，实际大概 7GB/s 左右。再看 AXI 侧的带宽：128 位 @ 250MHz = 4GB/s，64 位 @ 250MHz = 2GB/s。

如果你选 64 位 AXI 口，即使 PCIe 链路是 Gen3 x8，你的数据也过不了 2GB/s 这道坎，链路带宽优势根本发挥不出来。我的经验是：64 位 AXI 只适合 x1 或 x2 的简单的低带宽场景，真要做数据搬运，起步 128 位，256 位更稳妥。一上来就 64 位，后面数据量一大，你一定会回来改 IP 重新综合。

2.3 BAR 空间与地址映射：RC 模式的命门

BAR（Base Address Register）是 PCIe 世界里地址映射的核心。EP 模式下，BAR 描述的是 FPGA 自己占据的地址空间；RC 模式下，BAR 描述的是下游设备的地址空间，FPGA 需要把它们的 BAR 映射到自身的 AXI 地址空间里。

RC 模式的地址映射逻辑大概是这样的：

• FPGA 的 M_AXI 发出一个地址，比如 0x0000_0000_8000_0000；
• 桥内部把这个地址和下游设备的 BAR 配置值做比较；
• 命中某个 BAR 后，生成对应的 PCIe Memory Read/Write TLP，发到目标设备；
• 设备返回 Completion，桥再把它转成 AXI Read 数据或写响应。

这听起来不复杂，但实际配置的时候有三个坑：

第一，AXI 地址宽度要开够。下游设备 BAR 如果很大（NVMe 的 BAR 通常 4KB～64KB，但某些采集卡 BAR 可能到 GB 级），你 AXI 地址位宽就得配 64 位，否则高位地址直接被截断，怎么访问都是乱的。

第二，BAR 类型要看清。大部分设备 BAR 是 Memory 类型，但也有少数设备带 IO BAR。RC 模式下一般只映射 Memory BAR，如果设备要求 IO 空间，很多桥核不支持，你就得查 Pin 的替代方案或者干脆换设备。

第三，地址窗口要预留。你在配置 IP 时看到的 BAR 参数，在 RC 模式下其实对应的是「你留了多少空间给下游设备」，而不是「你占了多少空间」。这些值要结合你实际要访问的设备来填，不然枚举时你会发现读回来的 BAR 大小和配置对不上。

注意：在 RC 模式下，M_AXI 发出的地址不是直接拿到线上去用的，首先要经过内部地址解码，命中 BAR 窗口后才会转成 TLP。所以排查地址问题时，别只盯着 AXI 地址，先确认这个地址是否落在已配置的 BAR 空间内。

2.4 中断机制：MSI / MSI-X 该怎么配

RC 模式下中断是比较容易忽视的环节。PCIe 中断有两种流派：INTx（边带信号式的中断，靠专用消息）和 MSI/MSI-X（通过 Memory Write TLP 来通知中断）。现代高性能设备，像 NVMe SSD，基本都要求支持 MSI-X。

FPGA 作为 RC，它要做的事情是：

• 在枚举阶段，读取下游设备的中断能力结构；
• 为设备分配一个「MSI 地址」和「MSI Data」——这个地址其实是 FPGA 自己内存空间中的一个地址，当设备要发中断时，会往这个地址写一个数据；
• FPGA 侧的逻辑收到这个写的请求后，产生中断标志给上层应用。

很多人在这一步卡住，是因为根本没给设备分配 MSI 地址，设备的中断消息发不出去。分配之后还要确保这个地址不和其他访问地址冲突，且 AXI 地址解码规则能正确地把设备的中断写事务识别出来。你可以在调试时先用 INTx 兜底，把流程跑通后再切到 MSI/MSI-X，这样能减少变量。

2.5 官方例程结构：建议从哪几个文件开始读

官方例程看起来文件多，但核心就几个。我一般会按下面这个顺序看：

1. IP 例化顶层：看 IP 的时钟、复位、AXI 接口怎么裸露出来，这个文件决定了你自己顶层怎么接；
2. PIO 状态机：看例程里怎么响应读写请求。虽然 PIO 是 EP 思维，但这段代码帮你理解 AXI 到 TLP 的映射关系，非常有参考价值；
3. 约束文件：看 PCIe 引脚约束、参考时钟约束、复位引脚约束，直接决定你的板卡能不能跑起来；
4. 仿真测试环境（如果有）：快速跑一遍仿真，能直观看到 TLP 和 AXI 事务的对应关系。

一句话：例程不是让你拿来直接跑的，是让你拿来「拆」的。把这几段吃透，你再去改 RC 模式就有底气了。

3. 从官方例程到自定义工程：RC 模式配置与初始化实操

理论说了一堆，下面进入实操。我的目标很简单：在 RC 模式下，让 FPGA 主动去读下游设备（比如一块 NVMe SSD）的配置空间，确认链路能通、配置读写能返回正确数据。这一步打通了，后面的数据访问才谈得上。

3.1 工程搭建与 IP 例化：Vivado 里的关键选择

在 Vivado IP Catalog 里搜AXI Memory Mapped To PCIe，双击进入配置。除了前面提到的设备类型选 Root Complex、链路速率宽度按硬件选之外，有几个选项要特别注意：

• AXI 接口位宽：根据你的带宽需求选，数据搬运场景至少 128 位；
• AXI 用户时钟频率：选的时钟频率要能和你后续挂在 AXI 总线上的逻辑时钟对齐，避免跨时钟域处理；
• 配置管理接口：如果 IP 提供了配置访问接口（和版本有关），一定要勾上，这是 RC 模式枚举的基础。

下面是一个常见的 Tcl 例化片段，方便你快速落核：

set axi_pcie_0 [create_bd_cell -type ip -vlnv xilinx.com:ip:axi_mem_mapped_to_pcie:2.6 axi_pcie_0] set_property -dict [list \ CONFIG.PCIE_BAR0_ENABLE {true} \ CONFIG.PCIE_BAR0_SIZE {64} \ CONFIG.PCIE_BAR0_TYPE {MEMORY} \ CONFIG.MODE {Root_Complex} \ ] $axi_pcie_0

这里的PCIE_BAR0_SIZE填 64 是指你为下游设备预留的 BAR 空间大小，单位是 K 还是 M 要看 IP 具体定义，建议生成后读一下 IP 手册确认。例化完成后，先把user_clk和axi_aresetn接好，把 M_AXI 的读写通道都接出来，方便后面抓波形。

3.2 不依赖 CPU 也能枚举：配置访问的核心流程

RC 模式的灵魂在枚举。没有 Linux 帮你做，就得自己写。最简单的方式有两种：

• 用 MicroBlaze 软核：挂一个 MicroBlaze，通过 AXI 接口往配置管理寄存器里写数据，用 C 代码循环扫描总线，开发效率和可读性都比较高，适合功能复杂的项目；
• 用纯状态机：不需要软核，自己写一个小模块，按顺序生成配置读请求，把返回的数据存到寄存器里。代码量不大，适合想彻底控制流程的场景。

不管哪种方式，枚举的过程都长一个样：

1. 等待链路 training 完成（检查 Link Status，或读取状态寄存器）；
2. 从 Bus 0 开始，对每个 Device 的 Function 0 发起配置读，读取 Vendor ID；
3. 如果读到0xFFFF_FFFF，表示这个位置没有设备，跳到下一个；
4. 如果读到有效 Vendor ID，就继续读 Device ID、Class Code、BAR 寄存器；
5. 通过往 BAR 寄存器写0xFFFF_FFFF、再读回的方式，计算出 BAR 实际大小；
6. 把有效的 BAR 地址写回到下游设备的配置空间，完成地址分配。

这里我贴一小段状态机的核心伪代码，帮你理解枚举中最关键的「探测设备是否存在」这个动作：

// 简化版枚举探测状态机 localparam IDLE = 3'd0; localparam CFG_RD_CMD = 3'd1; localparam CFG_RD_WAIT= 3'd2; localparam CHECK_DATA = 3'd3; localparam DONE = 3'd4; always @(posedge user_clk) begin if (!axi_aresetn) begin state <= IDLE; // ... end else begin case (state) IDLE: begin // 目标地址：Bus0, Dev0, Func0, 寄存器偏移0 (Vendor ID) cfg_addr <= {10'd0, 5'd0, 3'd0, 6'd0}; state <= CFG_RD_CMD; end CFG_RD_CMD: begin // 发起配置读请求，拉高读写握手 s_axi_ctl_arvalid <= 1'b1; state <= CFG_RD_WAIT; end CFG_RD_WAIT: begin s_axi_ctl_arvalid <= 1'b0; if (s_axi_ctl_rvalid) begin vendor_id <= s_axi_ctl_rdata[15:0]; state <= CHECK_DATA; end end CHECK_DATA: begin // 0xFFFF 表示总线上该位置没有设备 if (vendor_id != 16'hFFFF) begin // 找到设备，继续读取 BAR、能力寄存器... found_device <= 1'b1; end state <= DONE; end endcase end end

注意：这里只是个示意，实际 IP 的配置接口时序要查手册。但核心思想不变：枚举就是不断读配置空间、判断返回值的过程。如果没有设备，返回的全 1 数据会告诉你总线是空的。

3.3 修改例程：发起你的第一个 AXI Master 读写事务

枚举完成后，工作重点转移到 M_AXI 上。此时你已经知道下游设备的某个 BAR 被映射到了某个地址空间，接下来就可以发起一个最基础的 AXI 读请求去验证数据通路。

举个例子：假设下游设备的 BAR0 被映射到你的 AXI 地址空间中的0x0000_0000_8000_0000，你想读它偏移0x00处的 32 位数据。你只需要在 M_AXI 上构造一个 AXI Read 事务：

• araddr = 32'h8000_0000
• arlen = 0（读 1 个数据）
• arsize = 2'b010（4 字节）
• arburst = 2'b00（FIXED，或 01 单次 increment）

然后在arready && arvalid握手成功后，等待rvalid && rready，从rdata里取回你的数据。同样地，要写数据就构造一个 AXI Write 事务，走aw、w、b三个通道。

第一次做的时候，我强烈建议用一个简单的状态机，在 AXI Master 接口上只发一次读、一次写，然后用 ILA 全程抓波形。重点关注握手的时序是否正确、数据返回是否有效、返回的响应信号是OKAY还是SLVERR。看到SLVERR不要慌，第一反应应该是：这个地址没有命中对端设备的 BAR，或者对端设备根本没响应。

3.4 板级验证要点：跑起来之前先检查这几处

板级调试和仿真完全是两回事，仿真里一切都干干净净，真实板子上全是信号完整性和上电时序问题。第一次上板，我一般按这个顺序检查：

• 供电：PCIe 需要多路供电，电源没起来，链路一定起不来；
• REFCLK：示波器测 100MHz 差分对，之前遇到过板载晶振虚焊导致 REFCLK 丢失，查了两天；
• 复位：PERST# 引脚必须正确释放，释放时机不能太早也不能太晚；
• AXI 复位：axi_aresetn必须保持足够长，确保 IP 内部状态机稳定；
• 引脚约束：翻一遍 XDC，确认所有 PCIe 引脚都被正确分配，尤其是收发差分对和时钟。

前面这些没问题了，再到逻辑里找问题。硬件调试的黄金法则是：先确认芯片级链路，再确认协议级枚举，最后才确认数据级读写，顺序反了，排查效率会低一半。

4. 调试实录：从链路失败到读写顺畅的完整排查套路

这章是我最想写的部分。下面这些坑，我基本都在项目里踩过，每次踩完都是一身冷汗，但搞明白之后再看 PCIe，就再也没慌过。

4.1 链路起不来，先别急着查代码

RC 模式下第一个大坑是链路 training 失败，也就是物理层根本没起来，后面的枚举、数据访问全是空中楼阁。你会看到的现象是：M_AXI 发出去的访问全部超时，配置接口读不到任何有效数据。

排查顺序很重要：

• 看 REFCLK：示波器确认差分波形正常，频率稳定在 100MHz；
• 看复位：PERST# 是否释放，释放时间是否在 REFCLK 稳定之后；
• 看链路状态：IP 通常有寄存器或用户状态位来指示当前 LTSSM 状态，正常应该到L0状态；
• 看 AXI 用户时钟：确认user_clk真的有输出，axi_aresetn已经拉高。

如果在超级终端或串口打印里看到链路状态一直卡在Detect或Polling，大概率是物理层的问题，和你的 AXI 逻辑没关系。这时候你去改状态机、改寄存器配置都属于做无用功。

一个小技巧：在顶层把user_lnk_up（链路正常指示信号）引到一个 LED 上，板子上电后一眼就能看到链路状态。这个信号对于调试效率的提升，真的比任何逻辑分析仪都直观。

4.2 枚举不到设备：配置访问出了问题

链路起来了，但你去扫描总线，发现读 Vendor ID 返回的全是0xFFFFFFFF，说明总线上好像没设备。可设备明明就插在板上，怎么回事？

这个问题在 RC 模式下尤其常见。原因通常是：

• 配置访问请求地址不对：你要访问 Bus0、Dev0，但发出的配置请求格式不对，或者被桥拦截了；
• 配置访问类型错了：访问 Bus0 的设备用的是 Type0 配置请求，访问 Bus0 之外的设备要用 Type1 请求，有的桥核不会帮你自动区分，需要你手动指定；
• 下游设备还在复位：设备没上电或者 PERST# 一直被拉低，它自然不会有任何响应。

排查方法：用 ILA 抓配置管理接口的波形，看读事务有没有正常发出、返回数据有没有及时回来。如果发现请求发了，但没有返回，再用示波器测一下目标设备的 PERST# 和辅助电源，确认物理上它是活着的。

这里我再强调一次：不要以为设备插上了就一定是上电状态，PCIe 端点的电源可能由 RC 控制的，而你根本还没写那个 GPIO。

4.3 读写返回超时或 SLVERR：命中和访问规则问题

枚举成功了，设备也找到了，但你通过 M_AXI 去读设备某个地址时，返回SLVERR或者直接超时。这个问题大概率出在「地址解码」环节。

RC 模式下，M_AXI 发出去的地址首先要经过桥内部的 BAR 窗口判断。如果你的访问地址没有落在任何已配置的 BAR 窗口内，桥根本不会把它转成 TLP，严重的直接返回错误。所以排查地址问题时的第一步是：

• 确认你访问的地址，确实落在这个设备的某个 BAR 映射范围内；
• 确认这个 BAR 已经在枚举阶段被正确写入设备配置空间；
• 确认 M_AXI 的地址宽度覆盖了你需要的所有高位。

另外还有一个容易忽略的点：有些设备的部分 BAR 是 64 位可预取 BAR，这种情况下地址高位不能随便忽略，你要确保 AXI 地址的高 32 位也正确。

4.4 中断不触发：MSI 配置细节

中断在 PCIe 里看着简单，用起来全是细节。RC 模式下，下游设备发 MSI 中断时，实际上是往你分配好的某个地址写一个数据。你的 FPGA 收到了这次内存写，才知道设备有事件要通知。

常见问题有这么几个：

• 没有分配 MSI 地址：枚举时，你必须在设备配置空间的 MSI Capability 结构里，写入「消息地址」和「消息数据」两个字段。很多人漏掉这一步，设备想发中断都不知道往哪发；
• MSI 地址和现有映射冲突：你给设备分配的 MSI 地址，必须落在 FPGA 自己接收中断消息的那个地址空间内，且不能被当作普通的数据访问地址；
• 中断消息的 AXI 事务没被识别：MSI 本质上是一个 Memory Write，如果你的接收逻辑只是简单地把所有写请求都当成数据写，没有单独识别中断消息，那中断自然不会被触发。

调试中断时，我会分为两步：先用 INTx 或者简单电平中断把流程跑通，确认逻辑链路没问题；再切到 MSI/MSI-X，用 ILA 抓中断消息对应的 AXI 写事务，检查和设备配置空间里填的地址/数据是否一致。一口吃不成胖子，中断这种异步信号，只能一层一层剥。

4.5 性能上不去：位宽、Burst 与地址对齐

链路也 up 了、数据也能读写了，但速度很慢，很多人这时候就怀疑是不是 PCIe 链路没有跑满。

先算一算：如果你的 AXI 位宽是 64 位、时钟 250MHz，理论带宽也就 2GB/s，就算 PCIe 链路是 Gen3 x8，你也只能到 2GB/s，瓶颈在 AXI 侧而不是 PCIe。这种情况下别调 PCIe，回 IP 配置里改 AXI 位宽或者时钟。

第二个常见问题是 Burst 长度太短。PIO 风格的一次读写几个数据，性能自然上不去。要做吞吐率，必须用 AXI Burst，一次传输尽量长的数据，同时保证地址对齐。PCIe 对读请求是有完成边界限制的，地址不对齐可能把一个长读请求拆成好几个小请求，性能损失很大。

还有一点要特别注意：PCIe 的读操作是有延迟的，Memory Mapped 模式下，每次读请求发出后要等设备返回数据，这个往返延迟决定了读吞吐率的极限。如果项目对读性能要求极高，建议考虑 DMA 或者整块数据搬移，而不是单次读。

4.6 调试工具组合拳：ILA、串口、lspci、devmem2

最后讲讲工具。我调试 RC 模式时，从来不是单靠一种工具，而是组合拳：

• Vivado ILA / 硬件管理器：最基础、最靠谱的调试手段。把 M_AXI、S_AXI、配置管理接口的关键信号全部抓下来，看握手、看数据、看响应，链路状态一目了然。
• 串口调试助手：如果你用 MicroBlaze 或者状态机做枚举，把每一步的枚举结果、Vendor ID、BAR 大小通过串口打印出来，配合串口调试助手看日志，比瞪着一堆波形舒服太多。尤其在定位「枚举到第几个设备卡住」这种问题时，打印日志的效率极高。
• lspci 与 devmem2：如果你手头正好有一台 Linux 主机，可以把 FPGA 板卡插到主板上，用lspci -vvv看设备配置空间能不能被正确识别，用devmem2直接读写物理地址，快速验证 FPGA 内部寄存器和 BAR 空间是否工作正常。这在 RC 模式开发初期，是个非常好的辅助验证手段。
• PCIe 协议分析仪：预算允许的话，这东西能帮你把 TLP 层、数据链路层的问题看得清清楚楚。没有它，你只能靠 ILA 一层层猜，效率天差地别。

用 ILA 抓信号时，我习惯先把触发条件设成「配置读请求的arvalid拉高」这个事件，然后看这个请求之后的整个链路。这样能快速确认配置访问有没有正确发起，又是卡在哪一步。

针对上面这些经验，我整理了一个速查表，方便你遇到问题时快速定位：

最后再分享一条我用真金白银换来的经验：不管你的目标功能多花哨，第一次上板调试，先只做一件事——用 AXI Master 发起一次针对下游设备 BAR 的 32 位写，再用 ILA 抓回来，确认链路和桥都工作正常。PIO 通了，后面无论是加 DMA、加中断、加多队列，都是在一条已经证明可行的通道上做加减法；PIO 不通，一切都是空中楼阁。记住：RC 模式下，PCIe 的秘密全藏在「枚举」和「地址映射」这两件事里，把这两关过了，剩下的就都是时序和性能调优的体力活了。