企业官网建设流程全解析

项目标题: "Vivado XDMA仿真实战：从PCIe链路训练到DMA数据传输全解析"

干FPGA这行，做PCIe相关的板卡，最怕的就是板子回来后link起不来。示波器一挂，发现差分对上一点信号都没有，然后就是在BIOS里看不到设备、lspci里没有输出、Windows设备管理器里一堆未知设备之间反复折腾。我相信不少人都经历过这种绝望时刻。

后来我养成一个习惯：凡是涉及PCIe的工程，先花两三天时间把仿真跑透，再让板子出去打样。这套思路的核心就是——在Vivado里用XDMA IP把从链路训练（Link Training）到DMA数据传输的完整流程仿真一遍，把逻辑问题全部暴露在流片之前。今天这篇博文，就是把这个仿真实战过程完整拆解出来，包括LTSSM状态机怎么跑、XDMA IP怎么配、仿真工程怎么搭、DMA传输怎么验证，以及我在实际调试中踩过的一堆坑。

不管你是正准备做PCIe板卡的硬件工程师，还是想彻底搞懂PCIe协议底层机制的FPGA开发者，这篇文章都能帮你在动手前建立一套完整的仿真验证思路。

1. 仿真的价值：为什么先跑仿真再出板

1.1 开发环境与仿真库准备

先说环境。Vivado版本我建议用2019.1以上，XDMA IP在那个版本之后基本定型，该有的特性都有，网上资料也多。我自己主力用的是Vivado 2022.2，下面所有内容都基于这个版本。

但这里最关键的还不是Vivado本身，而是仿真库。PCIe的仿真必须要用Xilinx提供的pcie模型库，在Vivado里叫xilinx_pcie_2_1（UltraScale和UltraScale+系列是pcie3_ultrascale），这个库不会默认编译好，必须手动编译。

编译方法很简单：Tools -> Compile Simulation Libraries。但这里有个大多数人第一次都会踩的坑——如果只默认选Verilog，不选VHDL，后面仿真会报一堆莫名其妙的错误，因为XDMA IP的example design里部分核心文件是VHDL生成的。所以编译的时候，Language选项建议把Verilog和VHDL都勾上。另外一个坑是编译目标路径不要带中文和空格，否则无法生成编译报告，看起来编译成功其实什么都没生成。

仿真库编译完成之后，在工程的Simulation Settings -> Libraries里，手动把xilinx_pcie_2_1和xdma_v3_0相关的库路径加进去。这一步很多教程都不会提，但漏掉之后，行为仿真的compile阶段就会直接报“无法解析模块引用”，基本上那些Module <pcie_...> not found的报错，十有八九都是这个原因。

1.2 整体验证思路：先链路后数据

仿真和实际板级调试最大的不同是：仿真环境里，PCIe Root Complex（RC）和Endpoint（EP）都在同一个工程里，链路训练过程直接被抽象成一个行为模型。拿XDMA的example design来说，Vivado会给我们生成一个testbench，里面已经包含了一个PIO模式的Root Port模型或者一个简单的RC模型，我们跑仿真时看到的就是EP侧与RC模型之间的LTSSM交互过程。

这套仿真验证，我建议分成两个阶段来看。

第一阶段是链路训练阶段。这个阶段的目标只有一个：让LTSSM从Detect状态一路走到L0，同时观察user_lnk_up信号拉高。如果这一步在仿真里都跑不到，比如卡在Polling或者Configuration状态，那就先不要往下走，直接把原因找出来，多半是配置或者复位时序问题。

第二阶段是数据通路验证。链路起来之后，通过XDMA的寄存器接口发起DMA读写操作，在波形里确认PCIe TLP报文被正确构造和解析，验证数据从H2C（Host to Card）和C2H（Card to Host）通道搬移正确。到了这一步，实际上就是模拟了整个DMA数据的完整生命周期。

为什么这套流程能提前暴露问题？因为在仿真里，所有信号都是可观测的，你可以随时查看LTSSM当前停留在哪个状态、TLP包头里的字段对不对、完了没完。而一旦上了板子，这些问题全都变成了不可见的“黑盒”，只能靠外部仪器猜。仿真跑不出来的链路，硬件上大概率也起不来，而仿真能跑通的逻辑，至少可以保证协议层面的行为是没问题的。

2. 链路训练全解：LTSSM关键状态与报文流转

2.1 LTSSM状态机速览：从Detect到L0

链路训练这个事儿，说白了就是链路两端的设备从互不相识到建立连接的过程。PCIe协议把这套过程定义成LTSSM（Link Training and Status State Machine），它一共包含11个状态，但我们仿真时真正关心的核心链路是：Detect -> Polling -> Configuration -> L0。

Detect阶段是整个训练的第一步，它要解决的问题是“链路上有没有对端设备”。物理层通过检测接收端是否存在（Receiver Detection）来判断。在仿真波形里，你会看到一段时间内，发送端处于Detect.Quiet和Detect.Active两个子状态之间切换。这个阶段如果一直过不去，通常说明物理层模型没正确上电，或者差分信号没有正确驱动。

Polling阶段则开始交换训练序列。发送端不断发送TS1有序集（TS1 Ordered Set），此时设备在等待接收对端的TS1。当收到对端的TS1后，进入Polling.Configuration子状态，交换基本的链路信息。这里就涉及前面说的第一个波折点——如果某一侧的接收端没有正确响应TS1，状态机会超时后重新回Detect，然后整个训练过程重新来过。

真正复杂的是Configuration阶段。进入Configuration后，收发两端要通过TS1/TS2中的**link number（链路号）和lane number（通道号）**来完成链路宽度协商。链路宽度协商的意义是：如果物理层把8条lane都连上了，但某一侧的另外几条lane没有响应，那双方最终协商出来的链路宽度可能是x1、x2、x4等。在配置阶段中，状态机会经历Configuration.Linkwidth.Start、Linkwidth.Accept、Lanenum.Start、Lanenum.Accept等子状态，最终把实际使用的link number和lane number确定下来。

Configuration阶段结束时，链路会进入L0状态，这是正常工作状态，也是此后所有数据报文传输的基础状态。在L0里，设备可以通过TLP进行数据传输，也可以通过数据链路层报文（DLLP）进行流控和确认。如果链路出现不可恢复的错误或需要重新协商速率，设备会进入Recovery状态重新做一次训练，这个过程也属于链路训练的一部分。

2.2 链路速率与宽度协商的仿真观测

很多人会在两个点上犯迷糊：第一个是“训练时是先定速率还是先定宽度”，第二个是“Gen3速率是怎么协商出来的”。

我直接说结论：在初始训练过程中，链路宽度和速率的协商是交织进行的，但顺序大致是——Polling阶段通过TS1有序集中的速率标识字段向对端“亮出”自己支持的最高速率，Configuration阶段完成link number和lane number协商，最终在Configuration.Idle阶段把速率锁定。也就是说，宽度协商主要发生在Configuration阶段，速率协商在Polling阶段就开始，并在Configuration结束时定音。

对于PCIe Gen3及以上的速率，还有个关键的均衡（Equalization）过程，它发生在Configuration状态结束后、进入L0之前。这个过程通过TS1有序集里的预设系数（Preset）和系数更新（Coefficient Update）字段来调整发送端的去加重和接收端的均衡器。在Vivado的PCIe仿真模型里，这个均衡过程有时会被简化为固定几个循环，但如果你的XDMA IP配置为Gen3，还是会在波形里看到一大段反复的TS1交换，如果你不知道这是均衡过程，很容易误判是链路卡住了。

在仿真波形里观测这些协商结果，最直观的信号是LTSSM状态输出，通常以ltssm_state_o形式出现在XDMA IP的输出端口上。以pcie_ultrascale系列为例，LTSSM状态值是一个6位的信号，比如6'd1是Detect.Quiet，6'd8是Polling.Active，6'd16是Configuration.Linkwidth.Start。你可以在波形窗口里将它设为Analog显示，就能清楚地看到状态值的爬升过程。

另外，链路协商完成后，pcie_link_rate信号（2bit）会指示最终的速率：2'b01为Gen1（2.5GT/s），2'b10为Gen2（5GT/s），2'b11为Gen3（8GT/s）。看到这个信号稳定在期望值，基本说明速率协商成功了。

2.3 从LTSSM波形反推链路质量

仿真环境里的链路质量是理想化的，没有实际PCB的插损、串扰、反射问题，所以仿真中的LTSSM无法验证电气性能。但反过来想，如果仿真中LTSSM状态都不正常，那硬件上大概率更加不可能正常。

我遇到过几个典型的仿真卡住案例，这里给个速查参考：

一个很好的习惯是：仿真的testbench里把ltssm_state_o打印出来，每隔一定时间用$display输出当前状态值。这样一旦链路训练异常，你直接在仿真日志里就能看到它在哪个状态卡住，不用开着波形一点点翻。这个习惯我一直保留到今天，实测非常高效。

3. XDMA IP配置关键点：从BMD模式到地址映射

3.1 IP配置参数逐项解析

链路训练只是热身，真正的重头戏当然是DMA传输，而这就要从XDMA IP的配置说起。在Vivado IP Catalog里搜索XDMA，双击打开配置界面，你首先会看到一大堆参数，这里我把仿真中影响最大的几个参数逐一说明。

Basic页签下的Mode：有DMA Only和DMA+Bridge两种，仿真验证通常选择DMA Only，它会生成一个纯粹的DMA引擎，不包含AXI Bridge逻辑，接口更干净。如果你的板卡后续需要RC侧直接访问FPGA内部寄存器或BRAM，才考虑DMA+Bridge方式。

DMA Interface：XDMA支持AXI4-Stream、AXI4-Memory Mapped和AXI4-Lite三类接口。仿真的话，大部分人会选择AXI4-Memory Mapped，因为它最接近真实的DMA搬移模型，地址映射清晰，便于观察地址和数据。AXI4-Stream接口则更适合将DMA数据直接灌给用户逻辑做流式处理。AXI4-Lite一般用于寄存器配置，XDMA内部自带这个接口。

Number of DMA Read/Write Channels：分别指C2H（Card to Host，即DMA读）和H2C（Host to Card，即DMA写）通道数。单通道配置最简单，仿真也足够用。如果后续要多通道，可以在仿真中把多通道的仲裁行为一并验证。

AXI Data Width：这个参数直接影响AXI总线的数据位宽，常见值是64位和128位。这里要结合PCIe链路速率来选：Gen3 x4下，PCIe的有效数据位宽是128bit，128bit AXI接口与之最匹配，可以避免位宽转换带来的额外时钟周期开销。但仿真里其实不必太纠结性能，我通常选128bit，这样AXI总线的地址对齐逻辑更直观。

Address Width：AXI地址宽度，通常设为64位。这个参数要和下文提到的BAR空间配置配合，否则地址映射会错位。

3.2 寄存器接口与描述符环机制

XDMA IP的核心工作机制是描述符环（Descriptor Ring）。这个概念搞懂了，XDMA就算理解了一半。

你可以把描述符环想象成一个“任务链表”：Host侧软件在系统内存里开辟一块区域，按固定格式填写描述符（Descriptor），每个描述符包含：控制字段（Control）、DMA操作的源地址/目的地址（Address）、传输长度（Bytes）。软件把所有描述符按顺序形成一个环状队列，然后告诉XDMA引擎“队列头在哪”（通过写Descriptor Base Address寄存器）和“队列尾到哪了”（通过写Tail Pointer寄存器）。XDMA引擎自动从内存中读取描述符，再执行实际的DMA搬移。

在BMD模式下，XDMA侧用户需要通过两个接口来操作DMA引擎：管理寄存器接口（通常是AXI4-Lite）和用户DMA接口。

仿真时，我们要模拟的就是Host侧的软件行为。在example design的testbench里，你可以看到Host模型通过AXI4-Lite接口往XDMA寄存器空间写地址描述符，然后触发Tail Pointer寄存器，DMA引擎随即发起一次读内存操作，把描述符内容取回来，接着开始数据搬移。

这里有个特别容易忽略的点：描述符环里的地址是PCIe空间的地址，也就是Host内存的物理地址，而不是FPGA侧所见到的AXI地址。而DMA搬移的目标地址，也就是XDMA AXI总线访问的FPGA侧地址，需要根据BAR配置做映射。这两套地址弄混是仿真中数据搬运错乱的最常见原因。

3.3 地址映射与AXI接口策略

配置BAR是XDMA IP配置里绕不开的一环。BAR（Base Address Register）是PCIe设备向RC暴露的可访问地址空间。在XDMA的配置界面里，你可以配置最多6个BAR，常用的是BAR0和BAR2。

BAR0通常配置为64-bit非可预取（Non-Prefetchable）空间，用来映射XDMA的寄存器控制区域。Host侧软件通过PCIe MWr/MRd报文访问BAR0，最终在FPGA内部转换为AXI4-Lite总线上的寄存器读写操作。这个映射关系是固定的：任何访问BAR0的TLP，都会直接落到XDMA内部的寄存器管理逻辑上，不需要用户额外处理。

BAR2一般配置为64-bit可预取（Prefetchable）空间，它用来映射到用户AXI接口上的地址。Host侧访问BAR2的TLP，会通过XDMA的AXI Bridge逻辑转成AXI4总线上的读/写请求。这意味着，如果Host软件通过BAR2往偏移地址0x0000_0000写数据，FPGA用户逻辑的AXI4接口上就会看到一次地址为0x0000_0000的写事务。

在实际仿真中，我经常用BAR2来做寄存器回环测试：Host模型往BAR2地址写一段数据，FPGA侧AXI接口上的BRAM就把数据接住，再让Host模型从相同地址读回来比对。这套流程跑通之后，相当于验证了RC侧到EP侧AXI的完整通路，再往后做DMA就非常有信心。

地址映射有个实操经验：AXI Data Width为128bit时，AXI地址的bit[3:0]会被当成字节使能处理，实际AXI数据地址最低位是bit[4]对齐。如果你在Host模型里写入BAR2地址的时候偏移按字节计算，而FPGA侧BRAM的地址又是按128bit对齐的，数据错位就会非常隐蔽。仿真这一层时，多检查一次地址换算关系，能省下来不少排查时间。

4. 仿真工程搭建与脚本化运行

4.1 工程创建与仿真库编译

下面进入最实战的部分：在Vivado里把XDMA仿真工程跑起来。

第一步是创建工程。这里我推荐直接创建RTL工程，然后把XDMA IP添加进去，再在IP的example design上跑仿真，而不是在Block Design里连SVF流程。原因很简单：example design自带的testbench和约束文件都配置好了，省去自己写testbench的麻烦，而且example design里包含了完整的Root Port模型，打开就能跑。

具体步骤：

1. 新建RTL工程，器件选你的实际芯片型号。
2. 在IP Catalog里搜索XDMA，双击配置IP。按照上一节提到的参数配置好，点Generate生成IP。
3. 在Sources窗口里找到生成的XDMA IP，右键选择Open IP Example Design。Vivado会创建一个新的工程，里面包含IP实例、testbench、约束文件等。

打开example design工程后，第一件事就是检查仿真库是否添加正确。在Simulation Settings里，确认xilinx_pcie_2_1（或pcie3_ultrascale）库已经加到仿真库列表中。如果先前编译仿真库这一步没做，在这里就会卡住。

4.2 仿真参数与XDMA模型配置

example design里的testbench已经非常完整，但还是要根据自己的需求做两处调整。

第一处是仿真链路的速率和宽度。testbench里通常有定义链路参数的宏，比如parameter LINK_RATE = 3（对应Gen3）和parameter LINK_WIDTH = 4（对应x4）。如果你的FPGA侧被配置成Gen3 x4，而testbench里的RC模型默认是Gen2 x2，链路训练时双方就会协商成Gen2 x2，虽然也能跑通，但后续DMA吞吐的仿真结果就不准了。建议把testbench的RC模型参数调成和EP侧一致。

第二处是AXI侧的内存模型。example design默认在AXI接口上接了一个简单的BRAM模型，用来模拟FPGA侧的可访问空间。这个BRAM模型的地址位宽通常是固定的，如果你的AXI Data Width是128bit，需要在BRAM模型上确认地址位和字节使能的换算关系。这里我建议给BRAM模型增加一个简单的初始填充任务，把已知的测试数据预先写进去，这样DMA搬移后方便做对比。

很多教程会建议直接修改testbench里的task来发起DMA，我也这么干。但更好的方案是在testbench里新增一个task，封装好一次完整的DMA操作，方便反复调用。下面我给出一个伪代码风格的task结构，具体接口信号以你的example design为准：

task automatic dma_h2c; input [63:0] host_addr; input [63:0] card_addr; input [31:0] byte_len; begin // 1. 等待 user_lnk_up 拉高 wait(user_lnk_up === 1'b1); // 2. 写描述符基地址寄存器 axi_lite_write(DMA_DESCRIPTOR_BASE, host_addr); // 3. 写DMA控制寄存器，配置方向(H2C)和传输长度 axi_lite_write(DMA_CONTROL, {direction, byte_len}); // 4. 写Tail Pointer寄存器，触发DMA引擎取描述符 axi_lite_write(DMA_TAIL_POINTER, 1'b1); // 5. 等待DMA完成中断/状态位 wait(dma_done_flag === 1'b1); end endtask

这段代码里的寄存器偏移需要根据你实际生成的XDMA IP地址映射来填，不同版本寄存器偏移略有差别，但机制是一致的。关键在于搞清楚“配描述符地址 -> 配控制字 -> 踢Tail Pointer -> 等中断”这个流程顺序，顺序错了DMA是绝对不会启动的。

4.3 跑通第一条链路：仿真结果判读

设置完成后，就可以跑行为仿真的了。跑仿真这个动作本身没有太多可说的，关键是怎么读结果。

仿真跑起来之后，第一步看日志。example design的testbench会打印出一些关键信息，比如“Link is up”、“Rate：Gen3”之类的。如果testbench没有这些打印，那你就在波形窗口里手动添加ltssm_state_o、user_lnk_up、pcie_link_rate这几个信号，重点观察它们的变化。

正常情况下的波形应该是这样一个顺序：复位释放后，ltssm_state_o从低数值状态开始逐步增加，先是Detect的几个状态值，然后跳到Polling，再跳到Configuration，最后稳定在L0对应的状态值。user_lnk_up在进入L0后会拉高，紧接着pcie_link_rate变成对应的速率值。

如果波形看不清楚，我建议在testbench里加一个简单的监控任务：

initial begin wait(user_lnk_up === 1'b1); $display("[%0t] PCIe link is up, rate = %0d", $time, pcie_link_rate); #1us; $finish; end

这个任务的意义是：仿真一旦跑到链路起来就自动结束，不用一直开着眼看波形等。对于批量跑仿真，比如调整参数后重新跑，这种自动判定的方式要高效得多。

5. 从链路训练到DMA传输：仿真中的完整数据通路

5.1 发起DMA传输的仿真初始化流程

链路训练完成后，接下来要验证DMA数据传输。前面提到过，example design的testbench里自带了一些DMA操作的task，但实际使用的时候，我更喜欢完全按自己的流程来初始化。

完整的仿真DMA初始化流程，我总结为以下四步。

第一步，确认链路已经起来。这是所有操作的前提，务必在user_lnk_up为高之后再发起任何DMA操作。在testbench里可以用一个wait语句挂起，等到user_lnk_up拉高再继续。

第二步，在“主机内存模型”中建立描述符环。这一步的具体做法取决于你的testbench结构。如果example design里是用BRAM模拟Host内存，那就直接往BRAM的特定地址写入描述符数据；如果是用一个AXI Slave VIP来模拟Host内存，那就要通过AXI写事务来填充描述符。

描述符的数据结构是固定的，控制字里除了方向（C2H还是H2C），还有地址增量模式和Completion通知方式。仿真时有一个容易被忽视的参数——地址增量模式。如果描述符里的地址为递增模式，DMA引擎搬移数据时会自动递增地址；如果为固定模式，数据会重复写到同一地址。这个模式没设对，会导致数据覆盖而不是搬移。

第三步，配置XDMA的寄存器。包括写入描述符基地址、中断掩码、DMA控制字等。这里要特别提醒：寄存器配置必须通过AXI4-Lite接口来完成，也就是testbench通过模拟RC侧的寄存器访问行为来写XDMA内部的寄存器空间，而不是在testbench里直接“force”内部信号。直接force内部寄存器虽然简单，但绕过了真实的寄存读写通路，反而掩盖了一些问题。

第四步，写Tail Pointer寄存器触发DMA引擎。Tail Pointer寄存器写入后，DMA引擎会立即开始工作：先通过PCIe的MRd TLP去读取描述符，然后根据描述符启动实际的DMA搬移。到这里，DMA传输的仿真流程才算真正开始。

5.2 在波形里读懂TLP报文

到了DMA数据传输阶段，TLP报文的观测就成了核心中的核心。很多人看PCIe仿真波形，觉得那一堆信号眼花缭乱，其实只要抓住几个关键信号，报文结构非常清晰。

在XDMA IP的PCIe物理层接口上，有一组AXI4-Stream接口，发送方向通常是m_axis_r_tdata，接收方向是s_axis_r_tdata。当DMA引擎发起读描述符操作时，你会在s_axis_r_tdata（实际上是发送方向，命名因IP版本而异）上看到一个完整的MRd TLP，它的包头结构是：

• Header Byte0：Fmt=0b010（3DW Header，无数据），Type=0b00000（MRd）
• Header Byte4-7：Request ID（Bus/Device/Function号）
• Header Byte8-11：Tag和最后两个DW的BE
• Header Byte12-15：32位地址或64位地址的低32位

要不要逐字节去核对这些字段？我的经验是——除非你在调试特定问题，比如Tag耗尽了、地址映射错了，否则不建议在正常DMA验证阶段把精力放在逐字节检查TLP上。更高效的做法是检查更高层的现象：

对于H2C DMA，先看AXI接口上是否有对应的写事务（AW通道和W通道上的地址/数据），再回到PCIe接口上看是否有对应的MWr TLP发出。对于C2H DMA，则反过来，先看PCIe接口上的MRd TLP（读请求），再等CPLD（Completion with Data）返回，最后在AXI接口上确认读出的数据。

这条追踪链路是判断DMA通路是否正常的黄金法则：先用高层现象定位问题，再深入到TLP层去分析根因。

5.3 验证数据一致性

DMA的最终目的就是数据搬移，数据搬完了一致性必须验证，否则DMA等于没做。

我在仿真中最常用的数据一致性验证方法，是特征值比对。

思路很简单：

1. 在DMA搬移之前，往源侧地址空间写入一组已知数据。H2C方向的源侧是Host内存模型，C2H方向的源侧是FPGA侧BRAM。
2. 启动DMA进行搬移。
3. DMA完成后，读取目标侧地址空间的数据，和已知数据做逐字节比对。

实际操作时，我会先填一种非常醒目的数据模式，比如每个字节按地址递增，即地址0x00的位置写0x00，地址0x01写0x01，依次类推。这种模式的好处是，一旦DMA搬移过程中地址偏移了一个字节或者数据位序错乱，比对结果会立刻暴露出来。

比对方法也很简单，用testbench里的Verilog任务同步读取目标侧BRAM的值，用for循环逐字节做比对，遇到不匹配就打印出错位置和数据：

task automatic check_data; input [63:0] start_addr; input [31:0] byte_len; integer i; reg [7:0] expected, actual; begin for (i = 0; i < byte_len; i = i + 1) begin expected = i[7:0]; actual = bram_model.mem[start_addr + i]; if (actual !== expected) begin $display("[%0t] DATA MISMATCH at addr %0h: expected %02h, actual %02h", $time, start_addr + i, expected, actual); $finish; end end $display("[%0t] DATA CHECK PASSED, %0d bytes verified", $time, byte_len); end endtask

有一个细节值得注意：BRAM模型的地址访问是带延迟的，读数据需要等到下一个时钟周期。如果在比对时忘记加#CLK_PERIOD延时，很可能读回来的全是X态，结果会误报数据不一致。这一点我在第一次写类似task时就踩过，后来养成习惯，每次读BRAM模型都会在地址拉高和数据采样之间加一个时钟周期。

6. 常见问题与避坑指南

6.1 仿真中常见的四类问题

把XDMA仿真完整跑通之后，我总结出四类最高频的问题，按仿真过程顺序排列如下：链路训练、描述符访问、数据搬运、仿真库与工程配置。每类问题都有一些固定套路可以快速定位。

6.2 描述符访问阶段的独家排查技巧

描述符访问阶段最容易出的问题，是DMA引擎在发起读描述符的MRd报文之后，等不到对应的CPLD返回。这个问题在实际板卡上很难排查，但在仿真里相对容易定位。

典型的现象是：testbench里等了很久，m_axis_r_tvalid上一直没有CPLD返回，DMA引擎一直处于等待状态。

排查思路分两步。

第一步，确认MRd报文确实从EP侧发出去了。在PCIe发送接口上看有没有对应的TLP。如果MRd根本没发出去，说明描述符基地址寄存器没写对，或者XDMA引擎根本没有启动。

第二步，如果MRd已经发出去，确认RC侧模型是否正常响应。example design自带的RC模型对MRd的处理逻辑，通常是把请求的目标地址映射到一个内部BRAM上。如果描述符基地址超出了RC模型BRAM的地址范围，RC模型就不会有响应，DMA引擎自然永远等不到CPLD。

我第一次做XDMA仿真的时候就栽在这个问题上。当时我把描述符基地址设成了Host内存的0x0000_0000_1000_0000，结果RC模型的BRAM只做到了0x0000_0000_0000_FFFF，然后仿真就永远挂起。后来把RC模型的BRAM地址范围扩大，或者在testbench里把描述符基地址设到RC模型支持的范围内，问题就解决了。

6.3 数据搬运错误的定位思路

如果链路和描述符都正常，但DMA搬移的数据错位了，这类问题通常和数据位宽、地址对齐有关系。

比如AXI Data Width是128bit，但H2C DMA的长度不是16字节对齐的，这时AXI总线上的写数据就会涉及部分字节使能，处理不当很容易导致数据错位。仿真里排查这类问题，我会在AXI接口上观察写地址和数据通道，对照描述符里的地址和长度，人工判断是否对齐。

另一个常见原因是：XDMA的AXI数据总线位宽和用户逻辑的BRAM数据位宽不一致。XDMA产生128bit的写数据，但BRAM控制器配置成32bit宽度，中间如果缺少位宽转换逻辑，数据的字节顺序就会错乱。仿真里看到写地址正确但写入内容错位，十有八九就是这个原因。

我处理这个问题的方法是：在testbench里，BRAM模型统一用和XDMA AXI接口相同的数据位宽，并且严格按地址对齐规则访存。同时，在BRAM初始化和数据比对的时候，使用与AXI数据位宽一致的数据类型来操作，避免位宽转换带来的隐性错误。

6.4 仿真与板级调试的差异认知

最后说一点关于仿真和板级调试差异的心得。

仿真最大的优势是可见性，任何内部信号都可以看，可以任意设置断点和触发条件。但仿真也有它固有的局限——它永远无法代替真实的电信号传输。PCIe的高速差分信号、抖动、串扰、参考时钟质量，这些都是仿真无法覆盖的。

所以我的建议是：仿真可以帮你在逻辑层面把问题降到最低，但不要指望仿真通过就等于板卡一定能正常工作。完成仿真验证后，板级调试时仍然需要预留调试手段，比如PCIe的调试逻辑分析仪（ILA with PCIe interface）、BDF检测、link training的示波器观测点等。

换句话说，仿真帮你排除了“逻辑设计错误”这一类问题，接下来的板级调试重点，要自然地转移到物理层和系统集成层面。

最后的个人经验

这套XDMA仿真的流程，我已经在不止一个项目里用过。每次开PCIe工程，我都会先花两三天把链路训练和DMA搬移的仿真跑通，再让板子出去打样。这习惯至少救过我两次：一次是配置里BAR地址设错了，另一次是AXI数据位宽和BRAM不匹配——这两个问题如果等到板子回来再查，大概率要花上一两周的测试时间，中间还要反复改代码、重新编译、再上板交替进行。

最后再分享一个小技巧：跑仿真的时候，不要把整个testbench从头到尾自动跑完就算了，建议在DMA传输完成后，额外花几分钟手动把PCIe的事务层信号、数据链路层信号逐个点出来看一眼。这个“人工巡检波形”的过程看起来慢，但真的能帮你把PCIe协议里那些容易混淆的概念——TLP和DLLP的区别、NP和P报文的差别、流控的credit机制——彻底理解到位。基本的仿真跑通只是第一步，能把波形里的报文流转讲清楚，这套技能才算真正长在你自己身上了。