4. Kria开发环境搭建与工程创建

Kria SOM 的高速串行链路调试与验证，第一步不是接上示波器，而是把工具链、板级支持包和示例工程三件事理顺。Kria 与普通 FPGA 开发板最大的区别在于：它是一块"带 PS 端 Linux 的 SOM + 载板"的组合体，PL 端的 GT 收发器、PS 端的 DDR/以太网、以及 SOM 上的启动固件分属不同工具管理。如果环境搭建阶段把 Vivado、Vitis、板级文件（Board File）和 SOM 启动镜像混在一起处理，后续在 GT 眼图扫描或误码率测试时，往往连"链路没起来"是硬件问题还是软件配置问题都分不清。

工具链的版本匹配与安装

Kria 官方支持的工具链是 Vivado + Vitis 的统一安装包（Unified Installer），当前主流版本为 2022.2 / 2023.2 / 2024.x。选择版本时有一条硬性约束：Vivado 版本必须与 Kria SOM 的板级支持包（Board Support Package）版本一致。例如 Kria KV260 的 Ubuntu 22.04 官方镜像对应 2022.2 的 BSP，若用 2024.1 的 Vivado 打开 2022.2 的板文件，虽然工程能打开，但 GT 参考时钟约束、PS 端 IP 的版本号会出现不匹配警告，综合时可能直接报 IP 版本冲突。

安装时在 Unified Installer 的器件选择页勾选 Zynq UltraScale+ MPSoC，并在"Boards"选项卡中勾选 Kria KV260 或 Kria KR260。这一步决定了后续创建工程时能否在 Board 列表中直接选到 SOM，而不是手动填器件型号。安装完成后建议检查两个路径：

# Vivado 板文件安装位置（Linux 默认）
/opt/Xilinx/Vivado/2022.2/data/boards/board_files/
# 应能看到 kria_kv260 目录，内含 part0_pins.xml 与 preset.xml

# Vitis 平台目录
/opt/Xilinx/Vitis/2022.2/platforms/

如果 board_files 下没有 Kria 目录，说明安装时未勾选板文件，需要重新运行安装器补装，而不是从网上下载一个板文件丢进去——版本错配的板文件会导致 PS 端 DDR 地址映射错误，这类问题在 GT 链路调试中会表现为 DMA 搬数失败，很难定位。

Kria SOM 板级支持包与启动镜像

Kria 的"板级支持包"实际包含两层内容：一层是给 Vivado/Vitis 用的 Board File（描述 SOM 引脚、时钟、PS 配置预设），另一层是给板子运行的 启动镜像（BOOT.BIN + image.ub + rootfs）。调试高速串行链路时，通常采用"官方 Ubuntu 镜像启动 + 自定义 PL 比特流加载"的方式，这样 PS 端 Linux 环境稳定，PL 端可以反复替换测试逻辑。

官方镜像烧录到 SD 卡后，SOM 上电会从 SD 启动。此时 PL 端默认加载的是 Kria 出厂的基础比特流（通常只包含一个简单的 LED 闪烁或空逻辑）。要加载自己的 GT 测试逻辑，有两种方式：一是通过 xmutil 工具加载 .xclbin 加速器文件；二是直接用 fpgautil 加载 .bit.bin 比特流。对于 GT 链路调试，推荐第二种，因为它不依赖 Vitis 加速器框架，加载更快、更直接：

# 在 Kria 板卡 Linux 终端中加载自定义比特流
sudo fpgautil -b gt_test.bit.bin -o /lib/firmware

# 查看 PL 是否加载成功
cat /sys/class/fpga_manager/fpga0/state
# 期望输出：operating

这里有一个容易踩的坑：Vivado 导出的 .bit 文件不能直接给 Linux 用，必须先用 bootgen 转成 .bit.bin。转换命令如下，其中 gt_test.bif 是一个描述文件：

# gt_test.bif 内容
all:
{
    gt_test.bit
}

# 转换命令
bootgen -image gt_test.bif -arch zynqmp -process_bitstream bin

创建含高速收发器的示例工程

环境就绪后，在 Vivado 中创建工程。关键操作是：在"Project Device"页面选择 Boards 选项卡，搜索 Kria KV260，选中后 Vivado 会自动填入 xck26-sfvc784-2LV-c 器件和 SOM 预设。这一步比手动选器件重要得多，因为板文件会自动带入 GT 参考时钟的引脚约束和 PS 端 DDR 配置。

工程创建后，按以下顺序搭建一个最小可用的 GT 测试链路：

  1. 添加 Zynq UltraScale+ MPSoC IP，在 PS-PL Configuration 中使能一个 PL 时钟（例如 100 MHz）和 AXI HP 接口，用于后续 DMA 搬数。
  2. 添加 GTH Transceiver Wizard IP（Kria 的 GT 类型为 GTH，位于 Quad 226/227）。在 Wizard 中选择"Start from scratch"，Line Rate 设为 10.3125 Gbps，参考时钟 156.25 MHz，编码方式选 64b/66b。这个组合对应常见的 10G 以太网/ Aurora 场景，是 Kria 载板上 SFP+ 接口的典型配置。
  3. 在 Wizard 的"Shared Logic"页面选择 Include Shared Logic in core，这样 GT 的 QPLL 和参考时钟缓冲会一并生成，避免手动例化 IBUFDS_GTE4。
  4. 添加 AXI DMA 和 AXI SmartConnect，把 DMA 的 MM2S/S2MM 接口与 GT Wizard 的用户接口对接，形成"PS DDR → DMA → GT TX → 外部环回 → GT RX → DMA → PS DDR"的闭环。

完成连线后，在 XDC 约束文件中确认 GT 参考时钟引脚与 SOM 实际连接一致。Kria KV260 的 GTH Quad 226 参考时钟来自载板上的时钟源，若使用 SFP+ 接口，参考时钟通常由 SFP 模块或板载 156.25 MHz 晶振提供。约束示例：

# GT 参考时钟约束（示例，需按实际载板确认）
create_clock -period 6.400 -name gt_refclk0 [get_ports gt_refclk0_p]

# 若参考时钟来自 IBUFDS_GTE4，需约束其输入引脚
set_property PACKAGE_PIN H9 [get_ports gt_refclk0_p]
set_property IOSTANDARD LVDS [get_ports gt_refclk0_p]

综合、实现并生成比特流后，用 write_bitstream 导出，再按前文方法转成 .bit.bin 加载到板卡。此时可以在 Vitis 中创建一个裸机或 Linux 应用，通过 AXI DMA 向 GT 发送递增数据包，并在接收端比对。若链路正常，DMA 的 S2MM 通道会收到与发送端一致的数据；若 GT 未锁定，gt_powergood 和 gt_pll_lock 信号会保持低电平，这是判断链路是否建立的第一手依据。

Kria SOM 高速收发器示例工程数据通路 PS 端 (Zynq MPSoC) DDR 数据缓冲区 Linux / 裸机应用 AXI HP 接口 AXI DMA MM2S / S2MM 数据搬移 GTH Transceiver 10.3125 Gbps 64b/66b 编码 QPLL / CPLL SFP+ 环回 光纤/同轴 TX→RX AXI AXI-S TX RX 回环数据 链路状态判读关键信号 gt_powergood 高电平 = GT 供电正常 gt_pll_lock 高电平 = QPLL 锁定 gt_rx_cdr_lock 高电平 = CDR 锁定 DMA S2MM 计数 递增 = 数据回环成功 判读顺序：gt_powergood → gt_pll_lock → gt_rx_cdr_lock → DMA 计数递增 任一环节为低或计数不增，说明链路未建立，需回查参考时钟、约束或环回连接

上图把工程的数据通路和状态判读顺序放在一起，实际调试时建议按图中顺序逐级确认：先看 gt_powergood，再看 gt_pll_lock，然后 gt_rx_cdr_lock，最后看 DMA 计数。如果前三个都正常但 DMA 计数不增，问题多半在用户接口的握手信号或数据位宽匹配上，而不是 GT 本身。

创建工程时若 Board 列表中找不到 Kria SOM，优先检查 Vivado 安装目录下的 board_files 是否包含对应版本，而不是手动修改器件型号。手动选器件会丢失 SOM 预设的 PS 配置和 GT 参考时钟约束，后续调试会引入额外变量。

至此，开发环境、板级支持和示例工程三部分已经打通。这个最小工程的价值在于：它把 PS、DMA、GT 和外部环回串成了一条可观测的链路，后续做眼图扫描、误码率统计或协议层验证时，都可以在这个框架上替换或增加 IP，而不必重新搭建基础环境。

← 上一章 📖 返回目录 下一章 →