作者：Han Hong，AMD工程师；文章来源：AMD开发者社区
痛点：为什么需要新工具？
在 DFX 设计中，理解每个可重配置分区（Reconfigurable Partition, RP）实际占用了哪些硬件资源，是 floorplanning 成功的关键。过去我们依赖 hd_visual 脚本来生成可视化信息——但它有两个致命问题：
- 极慢：大型设计上可能跑数十分钟
- 信息有限：无法直接查询 PU、overlap、disjoint pblock 等高级信息
AMD 在 Vivado 2023.2 中引入了 get_dfx_footprint 命令，一步到位地解决了这些问题。
get_dfx_footprint 是什么？
get_dfx_footprint 是一条内置的 Vivado Tcl 命令，用于查询和可视化 DFX 设计中 RP 的 placement footprint、routing footprint 以及各种器件级属性。它直接返回 tile、site 和 cell 对象，可以无缝衔接 highlight_objects、resize_pblock 等命令使用。
支持器件：UltraScale、UltraScale+、Versal（不支持 7 Series）
前置条件：使用前需先定义好 reconfigurable Pblock，并在 post-synthesis 或 routed design 上运行。
选项速查表
下表列出了所有支持的选项。UltraScale/UltraScale+ 仅支持前三项，Versal 支持全部。
所有选项都通过 -of_objects 指定目标对象（通常是 RM cell 或 device tile）。
实战场景
场景一：快速查看 RP 的 Placement 和 Routing 范围
这是最基础也最常用的操作。routing footprint 总是大于等于 placement footprint，建议先高亮 routing，再高亮 placement，这样两层颜色不会互相遮挡：
# 先看 routing 范围（黄色）
highlight_objects -color yellow [get_dfx_footprint -route -of_objects [get_cells inst_rp]]
# 再看 placement 范围（蓝色）
highlight_objects -color blue [get_dfx_footprint -place -of_objects [get_cells inst_rp]]
在 Device View 中，你会看到蓝色的 placement 区域被黄色的 routing 扩展区包围——这就是 Vivado 为提升布线成功率自动扩展的 routing footprint。
图：蓝色区域为 placement footprint，黄色区域为 expanded routing footprint
场景二：排查多 RP 重叠问题
当设计中有多个 RP 时，Pblock 边界的 BLI tile 或 clocking tile 可能被意外共享，触发 HDPR-66 或 HDPR-156 DRC 错误。用 -overlap 可以一秒定位问题所在：
highlight_objects -color red [get_dfx_footprint -overlap -of_objects [get_cells design_0_i/rp1_rm1]]
如果需要对比两个 RP 的 placement 范围，可以用不同颜色分别标注：
highlight_objects -color yellow [get_dfx_footprint -place -of_objects [get_cells <RP1>]]
mark_objects -color blue [get_dfx_footprint -place -of_objects [get_cells <RP2>]]
重叠 tiles 会同时显示两种颜色，一目了然。
图：两个 RP 的 placement footprint 分别用黄色和蓝色标注，重叠区域在红圈内
场景三：探索器件的 Programmable Unit
Versal 的最小可重配置单元（PU）因资源类型而异。-pu 选项不依赖任何设计，只需加载器件即可查询：
# 加载器件（无需设计）
link_design -part xcvc1902-vsva2197-2MP-e-S
# 查询某个 CLE tile 的 PU
get_dfx_footprint -pu -of_objects [get_tiles CLE_E_CORE_X27Y4]
# 查询 DDRMC tile 的 PU
get_dfx_footprint -pu -of_objects [get_tiles -of_objects [get_sites DDRMC_RIU_X2Y0]]
图：白色框为 RP Pblock 的 PU 对齐范围
同样，-is_reconfigurable 也不依赖设计：
get_dfx_footprint -is_reconfigurable -of_objects [get_tiles CLE_W_CORE_X0Y623]
# 返回 1（可重配置）
get_dfx_footprint -is_reconfigurable -of_objects [get_tiles -of_objects [get_sites PS9_X0Y0]]
# 返回 0（不可重配置）
场景四：管理 Disjoint Pblock
当 RP 需要内部时钟资源（BUFGCE、MMCM 等位于器件底部 HSR），而逻辑区域在器件其他位置时，必须使用 disjoint Pblock。get_dfx_footprint 提供了完整的辅助命令：
set rm_cell [get_cells design_0_i/bramctrl_rm]
# 获取 fabric logic region 的 sites → 用于 child Pblock
set fsr_sites [get_dfx_footprint -site_type fsr -of_objects $rm_cell]
# 获取非时钟 cells → 必须分配到 child Pblock
set non_clk_cells [get_dfx_footprint -cell_type non_clock -of_objects $rm_cell]
# 配置 child Pblock
resize_pblock [get_pblocks pblock_child] -add $fsr_sites
add_cells_to_pblock [get_pblocks pblock_child] $non_clk_cells -clear_locs
这样，non-clock logic 被约束在 primary region（fabric），clock 和 clock control logic 留在 secondary region（HSR），避免跨 disjoint 区域的不可布线问题。
图：Disjoint Pblock 的两个区域——右上方为 primary fabric region，左下方为 secondary HSR clocking region
图：绿色高亮为 disjoint Pblock 的 routing footprint
图：创建 child Pblock 后，clock 资源留在 parent，其余逻辑分配到 child
图：BUFGCEs、MMCM、DPLL、XPLL 等时钟资源位于器件底部 HSR
场景五：HSR Pblock 范围优化
对于双 RP 设计，用 CLOCKREGION 级别约束 HSR 会自动拉入过多 BLI tiles，导致 footprint 扩展和重叠。推荐改用 site 级别约束：
# ❌ 不推荐：拉入整个 clock region
resize_pblock [get_pblocks pblock_rp0] -add {CLOCKREGION_X6Y0:CLOCKREGION_X6Y0}
# ✅ 推荐：只添加必要的 sites
resize_pblock [get_pblocks pblock_rp0] -add [get_sites ...]
用 get_dfx_footprint -place 验证调整后的 footprint 是否符合预期：
get_dfx_footprint -place -of_objects [get_cells <rm_cell>]
图：使用 CLOCKREGION 级约束后，绿色高亮的 sites 被自动拉入 placement footprint，可能导致与相邻 RP 重叠
与 hd_visual 的对比
小结
get_dfx_footprint 不仅仅是一个可视化工具——它是 DFX floorplanning 工作流的核心辅助命令：
- 验证 Pblock：快速确认 RP 的 placement/routing 实际范围
- 排查冲突：一条命令定位多 RP 的 tile 重叠
- 探索器件：不需要设计即可查询 PU 和可重配置属性
- 管理 Disjoint Pblock：自动获取正确的 site 和 cell 分配方案
- 优化 HSR 范围：避免 CLOCKREGION 级约束带来的 footprint 膨胀
如果你还在用 hd_visual，是时候切换了。
