简介：本资源是一套基于Verilog语言实现的FPGA SRIO高速串行通信回环测试例程，面向数字电路设计初学者、FPGA开发工程师及嵌入式高速接口学习者，旨在帮助理解SRIO协议物理层与链路层逻辑、验证FPGA端SRIO接口功能完整性，并掌握低延迟数据通路的自检方法。压缩包共452个文件，80.63MB，涵盖96个sdb（综合调试数据库）、57个v（Verilog源码）、51个xml（工程配置与约束描述）、33个vdb（仿真数据库）及多个bat脚本（如elaborate.bat、simulate.bat、runme.bat等），完整支撑从综合、仿真到比特流生成的全流程开发；另有xdc约束文件、tcl自动化脚本、rpt报告与log日志，便于调试分析与复现。目前已有3090人学习下载，提供可直接运行的回环验证环境、结构清晰的模块划分（含发送/接收/环回控制核心）及配套工程配置，是深入理解SRIO在雷达信号处理、多FPGA协同计算等高性能场景中落地实践的优质入门范例。

1. FPGA SRIO例程：为什么你跑通第一个 loopback 测试比想象中更难，但值得死磕到底

FPGA SRIO例程不是“点开即用”的 SDK 示例，而是嵌入式高速互连领域里一块典型的「硬骨头」——它表面是几个 Verilog 文件和一份 UG576 文档的组合，背后却横跨物理层眼图调试、链路训练状态机、事务层 TLP 封包规则、设备 ID 分配逻辑，以及最关键的：FPGA 与外部 SRIO 交换芯片（如 TI TSB8102/TSB43AB22）之间那根看似普通、实则对布线长度/阻抗/端接精度极度敏感的差分线。很多开发者卡在LINKUP = 0超过 48 小时，翻遍 Xilinx AR 文档才发现问题出在 PCB 上一对未做 100Ω 差分匹配的 RX_P/N 走线；也有人成功 linkup 后收不到 inbound write，最后发现是DEVICE_ID配置寄存器写成了十进制而非十六进制。这不是玄学，是信号完整性 + 协议栈 + 硬件协同的三重验证。如果你正在做多板同步采集、雷达信号回传或实时图像拼接系统，SRIO 是 PCIe 之外最稳的低延迟选择；如果你只是想快速验证 FPGA 高速接口能力，它也能给你远超 UART/JTAG 的真实工程体感。本篇不讲协议标准原文，只讲我亲手调通 Xilinx Kintex-7 + TSB8102 的完整路径：从 Vivado 工程搭建、IP 核关键参数设置、环回测试脚本编写，到示波器抓取 training sequence 的实操判断依据。

2. 用 Vivado 2022.1 搭建最小可运行 SRIO 工程：IP 核配置决定 80% 的成败

SRIO 在 Xilinx 生态中以 LogiCORE IP 形式提供，但它的配置项远比 AXI DMA 或 Ethernet MAC 复杂。核心在于：你不是在“添加一个 IP”，而是在“声明一个 SRIO 子系统”——包括物理层（PHY）、逻辑层（Logical Layer）、传输层（Transport Layer）三者的协同参数。以下步骤基于 Kintex-7 xc7k325tffg676-2（GTX 支持 3.125/6.25 Gbps），使用 TSB8102 作为外部 PHY 芯片（非集成 PHY 的 FPGA 型号）。

2.1 创建工程并添加 SRIO Gen2 IP 核

提示：必须使用SRIO Gen2 LogiCORE IP v5.5 或更高版本（Vivado 2022.1 自带 v5.6）。v5.4 及更早版本存在TX_BUFFER_DEPTH参数无法正确映射至 RTL 的 bug，会导致 link training 失败后无法复位。

# Vivado Tcl Console 执行（确保已设置好 part 和 board） create_project srio_loopback ./srio_loopback -part xc7k325tffg676-2 -force set_property board_part xilinx.com:kc705:1.4 [current_project] # 添加 IP create_ip -name srio_gen2 -vendor xilinx.com -library ip -version 5.6 -module_name srio_top

2.2 关键参数四选一：物理层与链路协商策略

SRIO IP 的Configuration页面有 4 组强耦合参数，必须按硬件实际设定，否则LINKUP永远为 0：

逻辑说明：这些参数直接生成srio_top.v中的GENERIC MAP，例如C_LANE_WIDTH => 4会控制rx_lane_sync模块的 lane 对齐逻辑；C_LINE_RATE => 2（对应 6.25G）则影响tx_rate_gen的计数器分频系数。参数错一个，RTL 生成的握手逻辑就与硬件物理层失配，这是 link 不上的根本原因，不是驱动或软件问题。

2.3 地址映射与维护通道使能：让 FPGA 能“看见”自己和对方

SRIO 的地址空间分为两部分：Maintenance（维护）通道用于读写配置寄存器，Data（数据）通道用于 payload 传输。初学者常忽略 Maintenance 通道配置，导致无法确认 link 状态。

// 在 top module 中例化 IP 后，必须连接以下信号（关键！） assign srio_top_srio_maint_read_data = srio_maint_read_data; assign srio_top_srio_maint_write_data = srio_maint_write_data; assign srio_top_srio_maint_address = {4'h0, srio_maint_addr[11:0]}; // 注意：地址高位补 0，UG576 P.42 明确要求 assign srio_top_srio_maint_byte_en = srio_maint_be; assign srio_top_srio_maint_write = srio_maint_write; assign srio_top_srio_maint_read = srio_maint_read;

参数说明：srio_maint_address必须是 12-bit（对应 Configuration Space 的 4KB 空间），且最高 4-bit 固定为0。若写成 16-bit 全地址，IP 核内部maint_decode模块会将访问路由到错误寄存器，DEVICE_ID读出来永远是0x0000。这是血泪经验：某开发者花两天查DEVICE_ID读不对，最后发现地址总线连错了两位。

3. 硬件环回测试：用最简 Verilog 脚本验证物理链路与协议栈

Linkup 成功 ≠ 数据通。必须用硬件级环回（Hardware Loopback）排除软件栈干扰。TSB8102 支持两种环回模式：PHY Loopback（物理层）和 Logical Loopback（逻辑层）。我们优先验证后者，因为它覆盖了完整的 SRIO 协议栈（PHY → Logical → Transport）。

3.1 启用 Logical Loopback 并触发训练

TSB8102 的LOOPBACK寄存器（offset0x1004）控制环回模式。需通过 I2C 或并行配置总线写入：

// Verilog 状态机：上电后 100ms 写入 LOOPBACK=0x0001（Logical Loopback Enable） always @(posedge clk_100m) begin if (!rst_n) begin i2c_wr_addr <= 16'h1004; i2c_wr_data <= 16'h0001; i2c_wr_en <= 1'b0; end else if (state == IDLE && timer_cnt > 10000000) begin // 100ms delay i2c_wr_en <= 1'b1; // 启动 I2C 写 state <= WRITE_LOOPBACK; end end

逻辑说明：LOOPBACK=0x0001使 TSB8102 将收到的 inbound packet 直接转发给 outbound path，绕过外部设备。此时 FPGA 发送的NWRITE包会被 TSB8102 “原样送回”，FPGA 的srio_rx_tlp_valid信号应在一个 clock cycle 后拉高，srio_rx_tlp_type为0x0A（Response with Data）。这是协议栈工作的铁证。

3.2 编写最小发送-接收检测逻辑

不依赖 AXI DMA 或 MicroBlaze，用纯 RTL 实现NWRITE发送与响应捕获：

// 发送 NWRITE 到自身（地址 0x10000，长度 4 bytes） reg [31:0] tx_payload = 32'hDEADBEEF; wire tx_ready = srio_top_srio_tx_tlp_ready; wire tx_valid = (state == SEND_NWRITE) ? 1'b1 : 1'b0; assign srio_top_srio_tx_tlp_valid = tx_valid; assign srio_top_srio_tx_tlp_type = (state == SEND_NWRITE) ? 4'h2 : 4'h0; // NWRITE = 0x2 assign srio_top_srio_tx_tlp_destid = 16'h0001; // 本机 DEVICE_ID assign srio_top_srio_tx_tlp_srcid = 16'h0001; assign srio_top_srio_tx_tlp_faddr = {16'h0000, 16'h10000}; // 32-bit address assign srio_top_srio_tx_tlp_length = 4'h4; // 4 bytes assign srio_top_srio_tx_tlp_data = tx_payload; // 检测响应 always @(posedge clk_100m) begin if (!rst_n) rx_resp_seen <= 1'b0; else if (srio_top_srio_rx_tlp_valid && srio_top_srio_rx_tlp_type == 4'hA) // Response w/ Data rx_resp_seen <= 1'b1; end

参数说明：srio_tx_tlp_type = 4'h2是 SRIO 规范定义的NWRITE（Non-posted Write）类型；destid/srcid = 0x0001是 FPGA 自身的设备 ID（需提前通过 Maintenance 通道写入DEVICE_ID寄存器0x000C）；faddr必须是 32-bit，高位补零。若rx_resp_seen在发送后 10us 内变为 1，则证明：
✅ 物理链路眼图达标（GTX 收发器锁定）
✅ Link Training 完成（LTSSM_STATE = 0x0F）
✅ 逻辑层 TLP 解析正确（rx_tlp_type解码无误）
✅ 传输层响应生成正常（NWRITE触发Response）

4. SRIO 链路调试避坑指南：5 条真实翻车记录与后悔药

SRIO 调试不是线性过程，而是高频次“现象→抓信号→改参数→再失败→再抓”的循环。以下是我在 3 个不同项目中踩过的坑，每一条都附带示波器/ILA 抓取证据和可立即执行的解决动作。

4.1 现象：LTSSM_STATE卡在0x01（Detect），RX_LOS信号持续为高

• 原因：PCB 上 SRIO RX 差分对未做 100Ω 端接，或走线过长（>15cm）未做等长控制，导致接收端眼图闭合。TSB8102 的RX_LOS是硬件比较器输出，不依赖 FPGA 配置。
• 解决：用 1GHz 示波器探头测量 RX_P/N，在 FPGA BGA 焊盘处观察眼图。若眼高 < 150mV，立刻检查：① 是否在 TSB8102 RX 引脚就近放置 100Ω 贴片电阻（0402 封装）；② 是否启用 FPGA GTX 的RX_TERMINATION（Vivado 中GT Wizard→RX Settings→Termination=100 Ohm）；③ 若走线 >10cm，强制在 FPGA 端加 33Ω 串联电阻（降低反射）。

4.2 现象：LTSSM_STATE跑到0x0F（LinkUp），但srio_rx_tlp_valid永远不拉高

• 原因：DEVICE_ID配置错误。SRIO 规范要求每个设备有唯一 16-bit ID，且destid必须与远端设备srcid匹配。若 FPGA 写入DEVICE_ID = 0x0000（默认值），TSB8102 会丢弃所有 inbound packet。
• 解决：用 ILA 抓srio_maint_read_data，读取0x000C（DEVICE_ID 寄存器）确认值。若为0x0000，立即用 Maintenance 通道写入有效 ID（如0x0001）：

  assign srio_maint_address = 12'h00C; // DEVICE_ID offset assign srio_maint_write_data = 16'h0001; assign srio_maint_write = 1'b1;

  注意：写操作需等待srio_maint_write_done信号拉高后再发下一个包。

4.3 现象：NWRITE发送后收到Response with Error（srio_rx_tlp_type = 4'hB）

• 原因：faddr（目标地址）超出 TSB8102 的 BAR（Base Address Register）范围。TSB8102 默认 BAR0 起始地址0x00000000，大小 1MB（0x100000），若写faddr=0x200000，则返回Address Error。
• 解决：用 Maintenance 通道读取BAR0寄存器（offset0x0010），确认其值（如0x00000000），然后确保所有NWRITE的faddr在[0x00000000, 0x000FFFFF]范围内。

4.4 现象：ILA 抓到srio_tx_tlp_valid拉高，但srio_tx_tlp_data全为0x00000000

• 原因：srio_tx_tlp_data信号在tx_tlp_valid为高时才有效，但初学者常误以为它持续输出。若未在 valid 有效沿同步采样，会看到全零。
• 解决：ILA 触发条件必须设为srio_tx_tlp_valid == 1，且 data 总线深度至少 128 samples。观察srio_tx_tlp_data是否在 valid 为高时出现预期值（如0xDEADBEEF）。

4.5 现象：LinkUp 后，用 ChipScope 抓srio_rx_tlp_type为0x00（Unknown）

• 原因：srio_rx_tlp_type是 IP 核内部解码结果，依赖srio_rx_clk时钟域同步。若srio_rx_clk未正确约束（XDC 中未添加create_clock -name srio_rx_clk -period 1.6 [get_ports srio_rx_clk]），则解码逻辑亚稳态，输出随机值。
• 解决：在 XDC 文件中显式约束srio_rx_clk（周期 = 1000 / line_rate_ps，6.25G 对应 160ps → 6.25GHz → 周期 160ps → 时钟周期 1.6ns），并运行report_clock_networks确认无 unconstrained clock。

5. 进阶技巧：用 ILA 实时观测 SRIO 事务流与自定义错误注入

当基础环回跑通，下一步是构建可复现、可验证的数据通路。与其依赖仿真（SRIO 仿真耗时且难以覆盖眼图缺陷），不如用 FPGA 片上逻辑分析仪（ILA）直接观测真实事务流。这招让我在某雷达信号回传项目中，30 分钟定位到NREAD请求超时的根本原因——不是链路问题，而是远端设备响应延迟超过 SRIO 规范允许的 1024 cycles。

5.1 ILA 配置：抓取 5 个关键信号，构建事务时间轴

在 Vivado 中添加 ILA core，触发条件设为srio_tx_tlp_valid || srio_rx_tlp_valid，捕获以下信号（宽度需严格匹配）：

提示：ILA 的DATA DEPTH至少设为 2048，因为一次NREAD事务包含 Request → Response 两个包，中间可能夹杂 Maintenance 包，需要足够深度捕获完整序列。

5.2 自定义错误注入：验证系统鲁棒性的终极手段

真正健壮的 SRIO 系统必须能处理链路瞬断、TLP 校验失败等异常。与其等现场出问题，不如主动注入错误：

// 在 TX path 插入可控 CRC 错误（模拟传输损坏） reg [2:0] crc_error_cnt; always @(posedge clk_100m) begin if (rst_n == 1'b0) crc_error_cnt <= 3'd0; else if (srio_tx_tlp_valid && crc_error_cnt < 3'd5) crc_error_cnt <= crc_error_cnt + 1'b1; end // 当 cnt==3 时，翻转 tx_tlp_data 的 bit[0]，破坏 CRC assign srio_top_srio_tx_tlp_data_corrupt = (crc_error_cnt == 3'd3) ? {srio_top_srio_tx_tlp_data[31:1], ~srio_top_srio_tx_tlp_data[0]} : srio_top_srio_tx_tlp_data;

逻辑说明：SRIO 的 CRC-16 校验由 PHY 层硬件完成，srio_tx_tlp_data_corrupt会触发 TSB8102 的CRC_ERROR中断（INTERRUPT_STATUS[1]）。此时你的固件必须能：① 读取中断寄存器；② 清除中断；③ 重发事务。这就是真实场景的预演——某次现场部署中，正是靠这套注入逻辑，提前发现了中断服务程序未清除INTERRUPT_STATUS导致中断风暴的问题。

5.3 用 Python 脚本自动化测试：把 ILA 数据转成可读报告

ILA 抓取的.ltx文件可导出为 CSV，用 Python 分析事务成功率、延迟分布：

import pandas as pd df = pd.read_csv("ila_srio.csv") # 计算 NWRITE 成功率 nwrite_sent = len(df[df['srio_tx_tlp_type'] == 2]) nwrite_resp = len(df[(df['srio_rx_tlp_type'] == 10) & (df['srio_rx_tlp_valid'] == 1)]) print(f"NWRITE Success Rate: {nwrite_resp/nwrite_sent*100:.1f}%") # 统计 NREAD 延迟（从 tx_valid 到 rx_valid 的 cycle 数） nread_rows = df[df['srio_tx_tlp_type'] == 4].copy() nread_rows['delay'] = nread_rows['srio_rx_timestamp'] - nread_rows['srio_tx_timestamp'] print(f"NREAD Avg Delay: {nread_rows['delay'].mean():.0f} cycles")

这个脚本让我在某图像拼接项目中，发现NREAD延迟在温度升高后从 850 cycles 涨到 1120 cycles，超出 SRIO 规范的 1024 cycles 限制，从而推动硬件团队优化 TSB8102 的散热设计。工具本身不创造价值，但把原始信号变成可量化的指标，才是工程师的核心能力。

我坚持在每个新项目启动时，先用 2 小时跑通这个 ILA+Python 流程，不是为了炫技，而是把“链路是否可靠”从主观判断变成数字结论。它不能替代示波器看眼图，但能让你在 10 分钟内回答客户：“当前 1000 次 NWRITE，成功率 99.97%，平均延迟 842 cycles，无超时”。这种确定性，是交付信心的基石。希望帮到你。

本文还有配套的精品资源，点击获取