3. Vivado硬件管理器实战

Vivado Hardware Manager 是软硬件联调时最直接的“探针”。它通过 JTAG 链路与 Zynq 器件内的 TAP 控制器通信，既能识别芯片 ID、加载 PL 比特流，也能借助 AXI 事务访问 PS 寄存器与总线状态。理解它的能力边界和操作路径，是后续定位“PL 没起来”“PS 卡死”“AXI 挂死”等问题的基础。

一、连接目标与器件识别

打开 Hardware Manager 后，第一步是 Open Target → Auto Connect。工具会扫描 JTAG 链，读取 IDCODE 并与器件库比对。以 Zynq-7000 为例，XC7Z020 的 IDCODE 通常为 0x03727093，XC7Z010 为 0x03722093；Zynq UltraScale+ 如 XCZU3EG 则为 0x04738093。若 Auto Connect 失败，常见原因有三类：JTAG 时钟过快（可降到 1 MHz 以下）、链上存在未上电或未复位的从器件、以及 cable 驱动未正确安装。此时可用 open_hw_target -jtag_mode 手动指定链，或先用 report_hw_targets 查看当前可见目标。

识别成功后，Hardware 窗口会列出器件树：xc7z020_1 下挂 PL 的 xilinx.com:xdma 或用户 IP，以及 PS 侧的 PS7 或 PSU 节点。注意：Zynq 的 PS 在 JTAG 链上表现为一个独立 TAP，PL 是另一个 TAP，二者共享同一物理链路但逻辑上分开。这一点决定了后续“配置 PL”和“读 PS 寄存器”是两条不同的操作路径。

二、配置 PL：比特流加载与状态确认

配置 PL 的典型流程是：右键器件 → Program Device → 选择 .bit 文件。对于 Zynq，若 PS 已启动并运行了 FSBL 或 Linux，PL 可能已被配置过，此时需要先确认 PCAP 状态。在 Tcl Console 中执行：

open_hw_manager
connect_hw_server -url localhost:3121
open_hw_target
current_hw_device [lindex [get_hw_devices] 0]
refresh_hw_device -update_hw_probes false [current_hw_device]
set_property PROGRAM.FILE {./top.bit} [current_hw_device]
program_hw_devices [current_hw_device]

执行后观察 DONE 引脚状态。在 Hardware Manager 的器件属性中，DONE 为 1 表示配置成功；若为 0，需检查 INIT_B 是否被拉低、PROGRAM_B 是否正常释放、以及比特流是否与器件型号匹配。一个常见陷阱是：比特流为 XC7Z020 生成，却误连到 XC7Z010，此时 IDCODE 校验会直接报错 Mismatch，不会进入配置阶段。

配置完成后，PL 内的用户逻辑开始运行。此时若设计中有 AXI 从机（如自定义 IP），它已经挂到 PS 的 AXI 互联上，但 PS 侧可能尚未使能对应时钟或复位。因此“PL 配置成功”不等于“AXI 通路可用”，这是后续读寄存器前必须区分清楚的状态。

Vivado Hardware Manager 与 Zynq 的 JTAG / AXI 访问路径 主机 PC Vivado Hardware Manager Tcl Console / hw_server localhost:3121 JTAG Cable TCK / TMS / TDI / TDO Zynq 器件（JTAG 链上两个 TAP） PS TAP ARM Cortex-A9 / A53 PS 寄存器空间 SLCR / GPIO / UART IDCODE: 0x03727093 PL TAP 可编程逻辑 用户 IP / AXI 从机 DONE / INIT_B 比特流配置目标 AXI Interconnect GP0 / GP1 / HP 端口 · 地址映射 用户 AXI 从机 寄存器 / BRAM / FIFO 基地址示例: 0x43C0_0000 读取 PS 寄存器与 AXI 状态的典型 Tcl 路径 1. create_hw_axi_txn rd_ps -type read -address 0xF8000000 2. run_hw_axi rd_ps 3. report_hw_axi_txn rd_ps → 查看 DATA / RESP 4. 读 AXI 从机: address 0x43C00000, len 4 5. RESP=OKAY 表示通路正常; SLVERR/DECERR 表示异常 注: 地址与数据为教学示例，实际以 Address Editor 为准 DONE=1 · AXI RESP=OKAY DONE=0 · RESP=SLVERR

三、读取 PS 寄存器：从 SLCR 到 GPIO

PS 寄存器读取依赖 AXI 事务，但 PS 内部寄存器并不直接暴露在 PL 的 AXI 地址空间，而是通过 M_AXI_GP 端口映射。以 Zynq-7000 为例，SLCR 基地址为 0xF8000000，GPIO 为 0xE000A000。在 Hardware Manager 中，使用 create_hw_axi_txn 创建读事务：

create_hw_axi_txn rd_slcr -type read -address 0xF8000000 -len 1
run_hw_axi rd_slcr
report_hw_axi_txn rd_slcr

返回结果中，DATA 字段即为读回值，RESP 为 OKAY 表示事务成功。若返回 SLVERR，说明从机存在但拒绝访问，常见于时钟未使能或复位未释放；若返回 DECERR，说明地址未映射，通常是 Address Editor 中未分配该段地址。注意：读 PS 寄存器时，PS 必须处于运行状态且对应时钟域已开启，否则 AXI 事务会超时。

一个实用技巧是：先读 0xF8000000（SLCR 的 LOCK 寄存器附近），再读 0xF8000120（ARM_PLL_CTRL），通过对比已知复位值判断 PS 是否已初始化。例如 ARM_PLL_CTRL 复位值约为 0x0001E020，若读回全 0 或全 F，说明 PS 未上电或 JTAG 访问路径异常。

四、AXI 总线状态判读

AXI 事务的 RESP 字段是判断总线健康度的核心。Hardware Manager 支持批量读，例如 -len 16 可连续读 16 个 32 位字，适合扫描一段寄存器空间。若某一段地址连续返回 SLVERR，而相邻段正常，则问题通常在该从机的时钟/复位或地址译码，而非整条 AXI 互联。若所有地址都返回 DECERR，应检查 PS 的 M_AXI_GP 是否使能、以及 Vivado Block Design 中 Address Editor 是否已为 IP 分配偏移。

此外，Hardware Manager 的 refresh_hw_device 可刷新器件状态，但不会自动重读 AXI 事务结果；每次读操作都需要重新 run_hw_axi。对于调试“PL 配置后 AXI 无响应”的场景，建议按以下顺序排查：先确认 DONE=1，再读 PS 的 SLCR 确认 PS 活着，最后读用户 IP 基地址确认 AXI 通路。三步都通过，才说明软硬件链路完整。

在 Tcl Console 中可用 get_hw_axi_txns 列出当前所有事务，用 delete_hw_axi_txn 清理旧事务，避免地址混淆。批量读时建议从基地址开始，以 4 字节为步长，便于与寄存器手册逐项对照。

五、常见异常与判断依据

现象可能原因判断依据
Auto Connect 失败JTAG 时钟过快 / 从器件未上电降低 TCK 至 1 MHz 后重试；report_hw_targets 无输出
Program Device 报 IDCODE 不匹配比特流与器件型号不一致比对 IDCODE 与 .bit 头部器件信息
DONE 始终为 0INIT_B 被拉低 / 时钟缺失测量 INIT_B 电平；检查 PL 时钟源
AXI 读返回 SLVERR从机时钟/复位未释放读相邻正常地址对比；检查 IP 的 ACLK/ARESETN
AXI 读返回 DECERR地址未映射核对 Address Editor 中的 Offset 与 Range

需要强调的是，Hardware Manager 的 AXI 读写是“非侵入式”的，它不依赖 PS 上运行的操作系统，因此即使 Linux 已挂死，只要 JTAG 链路和 PS 时钟仍在，仍可读取寄存器。这一特性使它成为区分“PS 软件崩溃”与“硬件通路故障”的关键工具。实际调试中，建议先建立一条已知正常的读事务作为基准，再逐步扩展到目标地址，避免在复杂地址空间中盲目扫描。

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