ZCU104 DPU 架构扩展与 DPU-only 测评操作指南
1. 文档目的
这份文档面向普通用户，目标是教你如何基于现有 DPU-PYNQ 工程，为 ZCU104 扩展不同的 DPUCZDX8G 架构，并在板端做 DPU-only 推理测评。
本文默认你的目标不是运行时切换架构，而是：
- 在主机端修改 DPU 配置。
- 重新生成新的
bit/hwh/xclbin。 - 使用匹配的新
arch.json重新编译xmodel。 - 将新产物放到板子上。
- 用统一脚本测量纯 DPU 推理时延。
2. 先说清楚几个关键结论
2.1 你现在手里的 DPU IP 能不能继续用？
可以。
你本机已经有完整的 DPU IP 和 ZCU104 工程，不需要再去外部重新找一套新的 DPU 源码包。
关键路径如下：
- DPU 通用 IP 包：
- ZCU104 已打包 kernel：
2.2 改架构后，能不能不重新编译，直接生成新 bitstream？
不可以。
只要你修改了 DPU 架构参数，例如：
B4096改成B23041 core改成2 coresRAM_USAGECHANNEL_AUGMENTATION
就必须重新跑硬件构建流程。也就是说：
- 需要重新综合
- 需要重新实现
- 需要重新链接
- 最终重新生成新的
dpu.bit / dpu.hwh / dpu.xclbin
2.3 改了 DPU 架构后，旧 xmodel 还能继续用吗？
原则上不要继续用。
最稳妥的做法是：
- 每个 DPU 变体使用自己的
arch.json - 每个
arch.json对应重新编译一份xmodel
即使只是改核数，也建议统一按"新硬件对应新 arch.json，再重编 xmodel"处理，避免模型和硬件不匹配。
3. DPU 架构有哪些
DPUCZDX8G 支持的卷积架构一共 8 种：
B512B800B1024B1152B1600B2304B3136B4096
你本地仓库中也能看到这 8 档定义：
对于 ZCU104，DPU-PYNQ 官方 README 中给出的已验证配置是：
B40962 cores
参考：
4. 你现在已经有的基线
你已经确认并验证通过了一套官方 DPU-only 基线目录：
- 板端目录：
/home/xilinx/dpu_arch_eval/zcu104_b4096_2core_official
其中包含：
dpu.bitdpu.hwhdpu.xclbinZCU104_CustomResNetDPUFixed.xmodeltest_dpu_only.py
这个目录现在可以作为后续所有 DPU 变体测试的参考模板。
5. 推荐的目录组织方式
5.1 主机端目录
建议每个变体在主机端保留独立目录，不要所有版本都混在 boards/zcu104 一个目录里。
推荐组织如下：
text
E:\0Project\DPU-PYNQ\boards\
zcu104_b4096_2core_official\
zcu104_b4096_1core\
zcu104_b2304_1core\
zcu104_b1600_1core\
zcu104_b1024_1core\每个目录都保留自己的一套：
dpu_conf.vhprj_configplatform.xsascripts/- 最终产物
dpu.bit / dpu.hwh / dpu.xclbin - 导出的
arch.json
5.2 板端目录
建议板端保持和主机端同名的变体目录：
text
/home/xilinx/dpu_arch_eval/
common/
input_tensor.npy
test_dpu_only.py
zcu104_b4096_2core_official/
dpu.bit
dpu.hwh
dpu.xclbin
arch.json
ZCU104_CustomResNetDPUFixed.xmodel
results/
zcu104_b2304_1core/
...
zcu104_b1600_1core/
...这种组织方式的优点是：
- 每个变体自成一套，不会串文件。
bit/hwh/xclbin/arch.json/xmodel能严格一一对应。- 后续做论文表格和实验复现更方便。
6. 推荐的扩展顺序
第一轮不要把所有变量一起扫完。
推荐先做：
B4096_2core_official
说明：你已经有了，可作为基线。B4096_1core
说明：先拆出核数影响。B2304_1core
说明：中高档。B1600_1core
说明：中档。B1024_1core
说明：较小档。
这样可以先回答最关键的问题：
- 固定模型和输入时，
T_DPU如何随架构变化 - 同一架构下，核数变化是否主要影响吞吐而非单次时延
7. 实际操作流程
下面以新增一个变体 zcu104_b2304_1core 为例。
步骤 1：复制一份新的 ZCU104 工程目录
不要直接在原始 boards/zcu104 上改。
推荐从当前 boards/zcu104 复制出一个新的变体目录：
powershell
Copy-Item -Recurse E:\0Project\DPU-PYNQ\boards\zcu104 E:\0Project\DPU-PYNQ\boards\zcu104_b2304_1core如果磁盘空间紧张，也可以复制最小必要文件，但对普通用户来说，直接整目录复制最不容易漏文件。
步骤 2：修改 DPU 架构配置
编辑新目录中的：
E:\0Project\DPU-PYNQ\boards\zcu104_b2304_1core\dpu_conf.vh
将：
verilog
`define B4096改为：
verilog
`define B2304对第一轮实验，建议保持以下项不变：
URAM_ENABLERAM_USAGE_LOWCHANNEL_AUGMENTATION_ENABLEDSP48_USAGE_HIGH
原因是你这轮的目标是比较架构本身，不要同时改太多开关。
步骤 3：选择核数模板
你当前 boards/zcu104/prj_config 已经被你改成了集成 hls_search 的版本，不适合直接拿来做 DPU-only。
DPU-only 时，请从官方模板复制：
- 单核模板：
- ZCU104 双核模板：
如果你要做 B2304_1core：
- 用
prj_config_1dpu覆盖新目录中的prj_config
如果你要做 B4096_2core：
- 用
prj_config_104_2dpu覆盖新目录中的prj_config
步骤 4：不要把 packaged_kernel_* 当主编辑入口
你可以参考：
但对普通用户来说，不建议直接修改这个目录后就开始构建。
更稳的做法是：
- 修改变体目录里的
dpu_conf.vh - 修改变体目录里的
prj_config - 然后基于这个变体目录跑整套构建
原因是：
packaged_kernel_*更像已经打包好的 DPU kernel 中间产物boards/<variant>才是更适合作为"项目入口"的目录
步骤 5：进入 Vivado / Vitis 构建环境
这一步必须要用 Vivado / Vitis。
推荐使用与你现有工程一致的版本线：
Vivado 2022.1Vitis 2022.1XRT
如果你用的是 Linux shell，官方写法是：
bash
source <vitis-install-path>/Vitis/2022.1/settings64.sh
source <xrt-install-path>/xilinx/xrt/setup.sh如果你用的是 Windows，本质上也是一样，只是通常是在：
- AMD 提供的
Vitis 2022.1命令行环境里执行 - 或你已经验证可用的本地构建命令窗口里执行
步骤 6：生成硬件产物
官方 DPU-PYNQ 的文档入口是：
官方推荐方式是：
bash
make BOARD=<变体目录名>例如：
bash
make BOARD=zcu104_b2304_1core如果你的本地工程已经不是走纯 make，而是走你现有的 Vivado + v++ 手动流程，也可以继续沿用。但最终必须拿到以下 3 个文件：
dpu.bitdpu.hwhdpu.xclbin
这是硬件侧最小交付物。
步骤 7：导出并保存 arch.json
每个硬件变体都要留自己的 arch.json。
常见来源包括：
- 构建后生成的 DPU IP 目录
- Vivado 工程中对应的 DPU 实例目录
你本地已经看到过类似路径：
- boards/DPUCZDX8G/prj/Vivado/srcs/top/ip/top_DPUCZDX8G_0_1/arch.json
boards/zcu104/.../DPUCZDX8G_1_0/arch.json
建议把该变体对应的 arch.json 复制到变体目录根部，和 dpu.bit 放在一起：
text
E:\0Project\DPU-PYNQ\boards\zcu104_b2304_1core\
dpu.bit
dpu.hwh
dpu.xclbin
arch.json步骤 8：重新编译匹配的 xmodel
这一步通常在 Linux 或 Vitis AI Docker/VM 中完成。
不要把旧变体的 xmodel 直接拿来复用。
你本地 DPU-PYNQ 里已有一个辅助脚本：
它的默认逻辑也说明了一个事实：
- 编译时必须指定目标
arch.json
如果你是 model zoo 模型，可以用它。
如果你是自己的前端模型，核心原则一样：
- 用新变体的
arch.json - 重新编译得到新
xmodel
常见命令形式如下：
bash
vai_c_xir --xmodel <量化后的输入模型> \
--arch <新变体的 arch.json> \
--output_dir <输出目录> \
--net_name <模型名>步骤 9：把新变体上传到板子
板端建议新建对应目录，例如：
text
/home/xilinx/dpu_arch_eval/zcu104_b2304_1core/上传以下文件：
dpu.bitdpu.hwhdpu.xclbinarch.json- 对应新变体编译的
xmodel test_dpu_only.py
步骤 10：在板上做 DPU-only 测试
你已经有一份可用的 DPU-only 测试脚本样例：
- 板端示例：
/home/xilinx/dpu_arch_eval/zcu104_b4096_2core_official/test_dpu_only.py
- 本地样例：
运行时注意两点：
- 要使用 PYNQ venv
- 要用
sudo，因为下载 overlay 到 PL 需要 root
板端运行命令示例：
bash
cd /home/xilinx/dpu_arch_eval/zcu104_b2304_1core
echo xilinx | sudo -S env XILINX_XRT=/usr /usr/local/share/pynq-venv/bin/python test_dpu_only.py建议每个变体记录以下结果：
overlay_load_msmodel_load_msinput_shapeoutput_shapelatency_mean_mslatency_median_mslatency_stdev_ms
8. 哪些改动必须重编 xmodel
以下改动，统一按"必须重编 xmodel"处理：
B512/B800/.../B4096DPU core countRAM_USAGECHANNEL_AUGMENTATIONALU_PARALLELCONV/ALU RELU 类型
以下改动通常更偏硬件资源/实现层，但为了避免混淆，建议也把它们记录到变体信息里：
URAM_ENABLE / URAM_DISABLEDRAM_ENABLE / DRAM_DISABLEDSP48_USAGELOWPOWER
9. 普通用户最容易踩的坑
9.1 直接改 boards/zcu104
不建议。
原因是你后面会很快分不清：
- 哪个版本是 DPU-only
- 哪个版本是 DPU+KNN 集成
- 哪个版本是 B4096
- 哪个版本是 B2304
9.2 拿错 prj_config
这是目前最危险的坑之一。
你当前 boards/zcu104/prj_config 已经被改成了带 hls_search 的版本。
如果你要做 DPU-only，不要直接拿它用。
9.3 旧 xmodel 直接复用
不要这样做。
最稳的规则是：
- 新硬件变体
- 新
arch.json - 新
xmodel
9.4 只保留 bit，不保留 arch.json
这会让后面模型编译和实验复现非常被动。
建议每个变体目录必须同时保留：
bithwhxclbinarch.jsonxmodel
10. 给你的实际建议
如果你现在就要开始扩展，不要一次做 8 个。
第一批建议只做：
zcu104_b4096_2core_officialzcu104_b4096_1corezcu104_b2304_1corezcu104_b1600_1corezcu104_b1024_1core
这样工作量可控，而且已经足够支撑：
- 前端
T_DPU对比 - 不同架构下的时延差异
- 后续论文里的资源与性能分析
11. 参考资料
-
AMD PG338, DPUCZDX8G 架构说明
https://docs.amd.com/r/en-US/pg338-dpu/Architecture-of-the-DPUCZDX8G
-
AMD PG338, DPU 核数说明
-
DPU-PYNQ 官方 README
-
本地 DPU-PYNQ 硬件构建说明
boards/README.md