2. Vivado/Vitis工程创建与硬件导出

在 Zynq Linux BSP 与可编程逻辑协同工程中，硬件平台是整个软件栈的“地基”。Linux 内核、设备树、U-Boot、根文件系统以及用户态驱动，最终都要与一份确定的硬件描述保持一致。这份硬件描述在 AMD 工具链中由 Vivado 生成，并通过 XSA（Xilinx Support Archive）交付给 Vitis 与 PetaLinux。本节围绕“从空工程到可交付 XSA”的完整链路展开，重点讲清 Block Design 的搭建逻辑、Zynq Processing System 的关键配置、PL IP 的集成方式，以及 XSA 导出与版本管理中的工程约束。

一、工程创建与 Block Design 的定位

在 Vivado 中新建工程时，器件选择必须与目标板卡一致。以常见的 Zynq-7000 系列为例，若目标为 ZC702 评估板，器件应选 xc7z020clg484-1；若为 Zynq UltraScale+ MPSoC 的 ZCU102，则应选 xczu9eg-ffvb1156-2-e。器件选错会导致后续 IP 核不可用、引脚约束无法匹配，且 XSA 在 Vitis 中导入时会出现平台不兼容。工程类型选择 RTL Project，并勾选“Do not specify sources at this time”，因为 Zynq 系统的硬件结构主要通过 Block Design 以图形化方式构建，而非手写 RTL。

Block Design（BD）是 Vivado 中用于搭建处理器系统与 IP 互联的容器。它本质上是一张由 IP 实例、接口连接、时钟与复位网络、地址映射共同构成的原理图。对于 Zynq 协同工程，BD 中通常包含三类对象：Zynq Processing System（PS）、PL 侧自定义或官方 IP、以及连接两者的 AXI 互联与时钟/复位模块。理解 BD 的关键在于：它不是“画图”，而是在生成一份可综合、可导出、可被软件工具解析的硬件拓扑描述。

二、Zynq Processing System 的关键配置

在 BD 中添加 Zynq Processing System IP 后，双击进入配置界面。这里的选择直接决定 Linux 能否正常启动，因此需要逐项确认。

首先是 PS-PL Configuration。若 PL 侧需要通过 AXI 总线访问 DDR 或 PS 外设，必须使能对应的 AXI 主/从接口。例如，PL 作为 AXI Master 访问 DDR 时，需使能 S_AXI_HP0 或 S_AXI_HP1，并设置数据位宽（通常 64 位）与 FIFO 深度。若 PL 仅作为从设备被 PS 访问，则使能 M_AXI_GP0 即可。

其次是 Clock Configuration。PS 的 FCLK_CLK0 通常作为 PL 逻辑的主时钟，默认 100 MHz 可满足多数 AXI 外设需求；若 PL 需要更高频率，可在 50–250 MHz 范围内调整。需注意，FCLK_CLK0 的频率会写入设备树中的 clock-frequency 属性，因此修改后必须同步更新软件侧配置。

第三是 DDR Configuration。DDR 型号、位宽、时序参数必须与板卡原理图一致。以 ZC702 为例，DDR3 容量 1 GB、位宽 32 位、频率 533 MHz（等效 1066 Mbps）。若此处配置错误，U-Boot 阶段会出现内存校验失败或内核启动后随机崩溃。

第四是 Peripheral I/O Pins。使能 UART1 用于串口控制台、SD0 用于启动介质、Ethernet0 用于网络、USB0 用于外设、QSPI 用于 Flash 启动等。每个使能的外设都会在设备树中生成对应节点，未使能的外设不会出现在硬件描述中，Linux 也无法识别。

最后是 Interrupts。PL 侧 IP 若需要向 PS 发送中断，需在 IRQ_F2P 上连接中断信号，并在 BD 中通过 xlconcat 与 xlslice 将多路中断汇聚到 PS 的 pl_ps_irq0。中断号与设备树中的 interrupts 属性一一对应，配置时需记录映射关系。

三、PL IP 集成与 AXI 互联

PL 侧 IP 可以来自 Vivado 自带的 IP 目录，也可以是用户通过“Create and Package IP”封装的自定义逻辑。集成时，通常使用 AXI Interconnect 将 PS 的 M_AXI_GP0 与多个 PL IP 的 S_AXI 接口连接。若 PL IP 需要访问 DDR，则将其 M_AXI 接口连接到 PS 的 S_AXI_HP0。

时钟与复位方面，PL IP 的 aclk 应连接 FCLK_CLK0，aresetn 连接 peripheral_aresetn。若 IP 需要不同频率，可通过 Clocking Wizard 生成。地址映射在 Address Editor 中完成，每个 PL IP 的 AXI 从接口会被分配一段基地址，例如 0x43C0_0000。该地址将出现在设备树中，用户态驱动通过 mmap 映射后即可读写寄存器。

完成连接后，必须执行 Validate Design。常见错误包括：时钟未连接、复位未连接、地址未分配、接口位宽不匹配。验证通过后，右键 BD 选择“Create HDL Wrapper”，生成顶层 HDL 文件。随后执行综合、实现、生成比特流。若仅需导出硬件描述而不下载到板卡，可跳过比特流生成，但 XSA 中若包含比特流，则 PetaLinux 可自动打包 BOOT.BIN。

Zynq 硬件平台构建与 XSA 导出链路 Zynq Processing System DDR3 1GB / 32bit / 533MHz UART1 · SD0 · ETH0 · USB0 FCLK_CLK0 = 100 MHz M_AXI_GP0 → PL 控制 S_AXI_HP0 ← PL 数据 IRQ_F2P ← PL 中断 Programmable Logic (PL) AXI Interconnect M_AXI_GP0 → 多从设备 自定义 IP / AXI GPIO 基地址 0x43C0_0000 AXI DMA / 数据通路 → S_AXI_HP0 → DDR 中断汇聚 xlconcat → IRQ_F2P Clocking Wizard · 复位同步 GP0 HP0 IRQ XSA 导出 system.hdf / .xsa 含 BD · 地址 · 中断 可选 bitstream Vitis / PetaLinux 导入 版本号 + Git 提交 Export 版本管理要点 1. XSA 文件名建议包含日期与版本：zynq_bd_v1.2_20240615.xsa 2. 每次导出后提交 Git，并记录 Vivado 版本、器件型号、BD 变更摘要 3. 软件侧 PetaLinux 工程通过 --hw-description 指向对应 XSA，避免硬件软件版本错配 4. 若仅更新 PL 逻辑而不改 PS 配置，可复用同一 XSA 结构，但需重新导出并更新 bitstream

四、XSA 导出与版本管理

综合与实现完成后，通过 File → Export → Export Hardware 导出 XSA。若已生成比特流，勾选“Include bitstream”；若仅用于软件编译，可不勾选以减小文件体积。XSA 内部包含 Block Design 的 XML 描述、地址映射、中断映射、PS 配置参数以及可选的比特流文件。Vitis 导入 XSA 后会自动生成平台工程，PetaLinux 则通过 petalinux-config --get-hw-description 读取 XSA 并生成设备树与 U-Boot 配置。

版本管理是协同工程中最容易被忽视的环节。XSA 是二进制归档，直接 diff 无法看出差异，因此必须配合工程源文件一起管理。建议将 Vivado 工程中的 .bd 文件、.xdc 约束、.xsa 以及导出日志一并纳入 Git。每次导出 XSA 时，在提交信息中记录：Vivado 版本、器件型号、BD 变更点（如新增 IP、地址调整、中断号变化）、对应的软件分支。若 PL 逻辑频繁迭代，可为 XSA 建立独立标签，例如 hw-v1.0、hw-v1.1，软件侧通过标签检出对应硬件描述，避免“硬件已更新、软件仍用旧设备树”的典型故障。

XSA 导出后，建议在 Vitis 中先执行一次“Validate”或重新生成平台，确认地址映射与中断号与 BD 一致。若 PetaLinux 编译时报设备树节点缺失，优先检查 XSA 是否包含最新的 BD 变更，而不是直接修改设备树源文件。
不要将 XSA 与比特流文件混用不同版本。比特流与 BD 结构必须来自同一次实现，否则 PL 配置后 AXI 接口可能无法响应，表现为内核访问 /dev/mem 时挂起或返回全 0。

至此，硬件平台从 Block Design 搭建、PS 配置、PL IP 集成到 XSA 导出与版本管理形成闭环。下一阶段，软件侧将基于这份 XSA 生成设备树、内核与根文件系统，而硬件描述的准确性直接决定 Linux 能否顺利启动并识别 PL 侧外设。

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