企业官网建设流程全解析

FPGA 工程做到一半，PS 端的 DDR 控制器、AXI 互联、时钟树全在 Block Design 里点好了，Validate Design 一片绿，地址分配也顺手点了 Assign。接下来要往里塞自己写的视频时序发生器、SPI 从机、按键消抖状态机，这时候多半会卡在同一步：BD 在 IP Integrator 里画得挺爽，可它毕竟不是一份 HDL 文件，没法定向读，于是“怎么在 top 文件里例化 BD 文件”就成了绕不过去的一道坎。这篇东西就把我这几年在 Zynq、Kintex、Versal 几个平台上反复走过的那条路完整捋一遍——包括 wrapper 到底是什么、什么情况下该把 BD 当子模块、例化时端口和约束怎么对齐、BD 改版之后怎么不翻车。内容偏实操，适合已经能在 Vivado 里跑通一个流水灯、但一遇到 BD 和 RTL 混搭就发懵的朋友，也适合那种 BD 早就搭完、就差把自定义逻辑接进去的中间阶段读者。

1. 先搞清楚 BD 文件和 top 文件到底谁管谁

1.1 BD 的本质是一份被图形界面包装过的脚本

很多人第一次接触.bd文件时，会下意识把它当成一个“大号的 Verilog 模块”，于是直接在工程里找design_1.v想读进去，结果发现根本没有。这事得从 BD 的存储形式说起。

.bd文件本体是一份 XML，记录了你在画布上放了哪些 IP、它们之间怎么连、哪些端口被引出成外部端口。Vivado 拿到这份 XML 之后，会在后台跑一连串 Tcl，把它翻译成两部分产物：一是各 IP 的配置信息（.xci），二是真正参与综合的 HDL 和网表。你看到的那份“能用”的代码，是工具生成出来的，不是你写的。

这带来一个很关键的结论：BD 不是一个可直接综合的源文件，它是一个设计容器。想让它参与综合，必须先让它“生成目标”，也就是 Generate Target。这一步做完，工程里会多出一个 wrapper 文件，它才是真正能被例化的那个 module。

我见过不止一个新手在 Tcl Console 里敲read_verilog design_1.bd，然后困惑为什么报语法错误。理解了这一层，后面所有操作就顺了：你要例化的从来不是 BD 本身，而是 BD 生成出来的那个 wrapper。

1.2 什么情况下必须把 BD 塞进 HDL 顶层

按道理，Vivado 是允许 BD 直接当顶层的——Create HDL Wrapper 之后把 wrapper 设为 Top，工程照样能综合、能实现、能上板。那为什么还有一大堆人非要在外面再套一层 HDL 顶层？我梳理了一下，动机基本落在三类。

第一类是顶层确实需要纯 RTL 的胶合逻辑。BD 里也能 Add Module 把 Verilog 塞进去，但那个流程对经常要在顶层改代码的人不友好：每次改动都得回到 IP Integrator 里，还要重新 Validate。而顶层的时钟分频、复位同步、按键消抖、自定义协议的收发状态机，这些和 IP 集成关系不大的东西，放在 HDL 顶层修改效率高得多，一行always就能搞定。

第二类是混合流程的工程习惯。有些团队的外设 IP 是自己用 Verilog 写的，走的是 IP 打包流程而不是 BD 画布，整个工程本来就是“RTL 为主、BD 为辅”的结构。这种情况下强行把 BD 设成顶层，等于让一个辅助部件爬到主位，层次会变得很别扭。

第三类是分工。系统工程师维护 BD 里的互联和配置，逻辑工程师维护顶层接口和自定义逻辑，两者靠 wrapper 的端口清单解耦。BD 内部怎么改都行，只要引出的端口不变，顶层就不用动。这种协作方式在大项目里非常常见，也是我目前最推荐的做法。

反过来说，如果你的整个设计都能在 BD 里完成——处理器、互联、外设全是 IP，顶多加两个 Add Module 的 RTL 模块——那就没必要多套一层 HDL 顶层。层级越少越好，多一层就是多一个出错的地方。

1.3 三条技术路线的取舍对照

把 BD 当成子模块例化，具体走法其实有三条。我把它们放在一起比一比，方便你对号入座。

方案 A 最简单，适合纯 IP 集成、后期不再大改的工程。方案 B 是这篇文章的主角，适合顶层还有大量自定义逻辑的场景。方案 C 介于两者之间，好处是 BD 被当成一个标准 IP 对待，可以进 IP Catalog、可以做版本管理，代价是每次改动都要重新 Package，而且打包时对端口命名、总线接口的要求更严格。

我个人的习惯是：只要顶层有超过 200 行的 RTL 逻辑，就走方案 B。如果 BD 本身就是一个完整子系统，以后要复用给别的项目，那就先走方案 B 调试，定稿之后再考虑转成方案 C。

2. 生成 wrapper 是把 BD 变成可例化模块的关键一步

2.1 auto-update 与手动副本，到底选哪个

在 Sources 面板里右键 BD 文件，Create HDL Wrapper，弹窗里只有两个选项，很多人点完就忘了，其实这两个选项决定了后面几个月的维护体验。

第一个是 Let Vivado manage wrapper and auto-update。选它，工具会在<project>.gen/sources_1/bd/<bd_name>/hdl/下面生成一个只读的 wrapper 文件。注意路径里的.gen，说明它是生成产物，不会出现在你的 srcs 目录里，也不会被版本控制系统正常纳入（除非你手动改配置）。好处是 BD 一改、重新 Generate，wrapper 立刻同步，端口增减自动反映出来。

第二个是 Copy generated wrapper to allow user edits。选它，wrapper 会被复制到<project>.srcs/sources_1/bd/<bd_name>/hdl/下面，变成一份你可以随便编辑的普通 Verilog 文件。代价是失去自动同步——BD 里加了个端口，这份副本不会自己更新，你得手动改，或者重新生成一次覆盖掉自己的修改。

我的建议很明确：走方案 B 的话，默认用 auto-update。理由很简单，wrapper 这份代码本来是工具生成的名字映射，你手动改它没有任何收益，只会引入不必要的差异。只有在极少数情况下——比如你需要给 wrapper 强行加一些端口注释、或者工具生成的端口顺序影响了某个老旧脚本——才考虑手动副本。

有一个实际会遇到的细节：当 wrapper 不是顶层时，综合日志里偶尔会看到关于 wrapper 顶层属性的提示信息。这不影响功能，BD 依然会正常展开，只是工具在提醒你当前的层次关系和默认预期不同。看到这类提示不用慌，先看综合是否真的完成。

2.2 wrapper 文件逐段拆开看

生成的 wrapper 代码量很小，但每一段都值得看明白。下面这份是我随手从工程里摘的，端口做了简化。

// design_1_wrapper.v // 由 Vivado 自动生成，请勿手动编辑 module design_1_wrapper (DDR_0_addr, DDR_0_ba, DDR_0_cas_n, // ... 中间省略一大堆 DDR 引脚 sys_diff_clock_clk_p, sys_diff_clock_clk_n, clk_100m, rst_100m_n); output [14:0]DDR_0_addr; output [2:0] DDR_0_ba; output DDR_0_cas_n; // ... 端口方向与位宽声明 input sys_diff_clock_clk_p; input sys_diff_clock_clk_n; output clk_100m; output rst_100m_n; design_1 design_1_i (.DDR_0_addr(DDR_0_addr), .DDR_0_ba(DDR_0_ba), .DDR_0_cas_n(DDR_0_cas_n), // ... 一一对应 .sys_diff_clock_clk_p(sys_diff_clock_clk_p), .sys_diff_clock_clk_n(sys_diff_clock_n), .clk_100m(clk_100m), .rst_100m_n(rst_100m_n)); endmodule

第一段是端口列表，注意这里用的是“外部端口名”，也就是你在 BD 里给 External Port 起的名字，加上位宽和方向的声明。第二段是内部实例化，模块名是 BD 的设计名（默认design_1），实例名固定是design_1_i。

这里有两个坑值得提前说。其一是端口名在 wrapper 里已经被“展平”了。BD 里如果用了 Interface 类型的端口，比如 AXI 或者差分时钟，画布上显示的是一个总线符号，但在 wrapper 里会拆成xxx_clk_p、xxx_clk_n这样的扁平信号。你在顶层连接时必须按扁平名来连，不能写总线名。

其二是实例名design_1_i会直接决定你的约束路径。后面写 XDC 时，凡是引用 BD 内部的 cell，路径前缀都要带上你顶层的例化名再加这个design_1_i。这一点在第四节还会展开。

2.3 例化之前必须确认的三件事

动手写顶层代码之前，有三件事花五分钟确认一下，能省掉后面至少半小时的排错。

第一，Validate Design 必须是绿的。BD 里任何一个 IP 的配置有问题、任何一个时钟引脚悬空，Validate 都会报出来。带着红的 BD 去生成 wrapper 再综合，报的错会拐好几个弯，排查成本翻倍。

第二，端口清单要逐条过一遍。在 BD 里把 External Port 的属性面板打开，看名字、位宽、方向。特别是位宽，BD 里写[15:0]还是[16:0]，直接决定顶层连线对不对得上。我踩过的坑里，最常见的就是 DDR 地址线位宽差一位，综合不报错，实现后跑起来就是读写异常。

第三，确认 wrapper 是否已经被设成了 Top。在 Sources 面板右键 wrapper 文件，看 Set as Top 是不是灰的。如果它是 Top，你需要把它取消，然后把你的新 top 设上去。这个动作顺序有讲究：先写 top 文件、加进工程、设成 Top，再去处理 wrapper 的顶层属性，否则综合会报“找不到顶层模块”。

# 确认并重设顶层 set_property top top [current_fileset] update_compile_order -fileset sources_1

update_compile_order这条命令看着不起眼，但它是很多人合成报“Module not found”的元凶。手工添加的 Verilog 文件，Vivado 不会立刻知道它们之间的依赖关系，必须刷一遍编译顺序，工具才能正确解析模块层级。

3. 把 BD 当子模块例化进 top 的完整实操

3.1 工程目录怎么规划才不容易乱

先说我自己的目录约定，这套结构用了好几个项目，暂时没翻过车。

project_x/ ├── project_x.xpr ├── srcs/ │ └── sources_1/ │ ├── top.v # 我维护的 HDL 顶层 │ ├── uart_rx.v │ └── uart_tx.v ├── constrs/ │ └── top.xdc # 顶层约束 ├── sims/ └── bd/ # BD 相关（工具自动管理）

关键在于：我自己的 RTL 全部放在 srcs 下，BD 生成的 wrapper 交给工具放在.gen下，两者物理隔离。这样每次从版本库拉代码，只要你的 wrapper 是 auto-update 模式，就不用把生成产物传上去，本地重新 Generate 一遍即可。如果传了生成产物，反而容易因为工具版本不一致导致 wrapper 内容有差异，产生莫名其妙的 diff。

添加文件的 Tcl 写法大致是这样：

# 添加自定义 RTL add_files -fileset sources_1 [list ./srcs/sources_1/top.v] add_files -fileset sources_1 [list ./srcs/sources_1/uart_rx.v] # 生成 BD 的 wrapper 并导入 make_wrapper -files [get_files design_1.bd] -top -import # 重设顶层并刷新编译顺序 set_property top top [current_fileset] update_compile_order -fileset sources_1

make_wrapper这三个参数值得解释一下：-files指定 BD，-top表示生成顶层 wrapper（即便它后面不当顶层，这里也要加，因为你要的是完整端口列表的那一份），-import表示把生成的文件加入工程。少了-import，wrapper 只在磁盘上存在，工程里看不到，综合时照样报找不到模块。

3.2 top 模块里例化 wrapper 的写法

wrapper 本身就是一个普通 module，例化方式和你例化任何一个 Verilog 模块没有区别。区别在于端口特别多，尤其是带 DDR 或者 PCIe 的 BD，动辄上百个端口。

下面是一个相对完整的例子，包含自定义逻辑和 wrapper 例化两大部分。

`timescale 1ns / 1ps module top ( // 外部差分时钟 input wire sys_clk_p, input wire sys_clk_n, // 按键复位，低有效 input wire rst_n, // DDR3 接口 output wire [14:0] ddr3_addr, output wire [2:0] ddr3_ba, output wire ddr3_cas_n, output wire ddr3_cke, output wire ddr3_ck_p, output wire ddr3_ck_n, output wire ddr3_odt, output wire [3:0] ddr3_dm, inout wire [31:0] ddr3_dq, inout wire [3:0] ddr3_dqs_p, inout wire [3:0] ddr3_dqs_n, // 自定义外设 output wire led0, input wire uart_rx, output wire uart_tx ); // ---- 来自 BD 的时钟与复位 ---- wire clk_100m; wire rst_100m_n; // ---- 顶层本地胶合逻辑：心跳计数 ---- reg [23:0] heart_cnt; always @(posedge clk_100m or negedge rst_100m_n) begin if (!rst_100m_n) heart_cnt <= 24'd0; else heart_cnt <= heart_cnt + 1'b1; end assign led0 = heart_cnt[23]; // ---- 自定义 UART 收发 ---- wire [7:0] rx_data; wire rx_valid; uart_rx u_rx ( .clk (clk_100m), .rst_n (rst_100m_n), .rx_pin (uart_rx), .data (rx_data), .valid (rx_valid) ); uart_tx u_tx ( .clk (clk_100m), .rst_n (rst_100m_n), .data (rx_data), .valid (rx_valid), .tx_pin (uart_tx) ); // ---- 例化 BD wrapper ---- design_1_wrapper u_bd ( // DDR 侧 .DDR_0_addr (ddr3_addr), .DDR_0_ba (ddr3_ba), .DDR_0_cas_n (ddr3_cas_n), .DDR_0_cke (ddr3_cke), .DDR_0_ck_p (ddr3_ck_p), .DDR_0_ck_n (ddr3_ck_n), .DDR_0_odt (ddr3_odt), .DDR_0_dm (ddr3_dm), .DDR_0_dq (ddr3_dq), .DDR_0_dqs_p (ddr3_dqs_p), .DDR_0_dqs_n (ddr3_dqs_n), // 时钟与复位 .sys_diff_clock_clk_p (sys_clk_p), .sys_diff_clock_clk_n (sys_clk_n), .clk_100m (clk_100m), .rst_100m_n (rst_100m_n) ); endmodule

这份代码里有几个值得单独拎出来的点。

第一个是命名映射的灵活性。wrapper 里的端口叫DDR_0_addr，我的顶层端口叫ddr3_addr，例化时用.DDR_0_addr(ddr3_addr)一一对应即可，不需要两边名字一样。这其实是方案 B 相对方案 A 的一个隐性优势：BD 里起名字可以随意（系统工程师的命名习惯），顶层可以按自己的编码规范重新命名，中间由例化语句做桥。

第二个是时钟的来源方向。上面这个例子里，BD 内部有 Clocking Wizard，从差分时钟进来之后分出clk_100m，再通过一个外部端口引出来给顶层的自定义逻辑用。这是最省事的做法——时钟树集中在 BD 里，顶层只管用。反过来也可以，顶层自己做 IBUFDS 和 MMCM，把单端时钟喂给 BD，但这样 BD 里的时钟约束和顶层就分散了，时钟多了之后很难统一管理。我的偏好是前者。

第三个是复位极性的统一。BD 里的 Processor System Reset IP 默认输出低有效复位，所以我顶层的自定义逻辑也统一用rst_100m_n低有效。千万别出现一半低有效一半高有效的情况，那种 bug 在综合阶段看不出来，上板之后行为诡异，排查起来非常痛苦。

3.3 顶层约束文件要跟着层次一起改

这一步是方案 B 与方案 A 差异最大的地方，也是最多人翻车的地方。

当 BD 是顶层的时候，你写的 XDC 里所有get_ports都是针对 BD 外部端口的，所有get_cells都是相对于 BD 顶层的相对路径。一旦在 BD 上面又套了一层 HDL top，情况就分成两半。

顶层端口那一半完全不受影响。因为你的引脚最终还是从顶层引出去，get_ports led0、get_ports sys_clk_p这些照样能用，引脚约束、IO 标准一个都不用改。

内部路径那一半则全部要加一层。以前写get_cells clk_wiz_0，现在要写成get_cells u_bd/design_1_i/clk_wiz_0。这一层就是你在顶层例化 wrapper 时起的实例名u_bd，加上 wrapper 内部的固定实例名design_1_i。

# 顶层端口引脚约束，不受层级变化影响 set_property -dict {PACKAGE_PIN Y9 IOSTANDARD LVCMOS33} [get_ports led0] set_property -dict {PACKAGE_PIN F19 IOSTANDARD LVDS} [get_ports sys_clk_p] set_property -dict {PACKAGE_PIN E19 IOSTANDARD LVDS} [get_ports sys_clk_n] # 端口的时序约束 create_clock -period 10.000 -name sys_clk [get_ports sys_clk_p] # 引用 BD 内部 cell，必须带上顶层例化名和 wrapper 实例名 set_property C_CLK_OUT1_FREQ_HZ 100000000 [get_cells u_bd/design_1_i/clk_wiz_0]

如果你不确定路径到底该写什么，最笨也最有效的办法是在 Tcl Console 里现场试。综合完成后敲get_cells -hier -filter {NAME =~ *clk_wiz*}，工具会把匹配到的完整层次路径打出来，直接复制粘贴进 XDC 就行。我到现在写稍微复杂一点的内部约束还是这么干，比凭记忆猜路径靠谱得多。

还有一类约束需要注意：IP 自带的 XDC。BD 里各个 IP 自己会带一份约束文件，比如 DDR 控制器的引脚时序、MMCM 的输出频率设定。这些约束由工具通过scoped_to_ref机制管理，作用域绑定在 IP 实例上，不受你在外面多套一层的影响。也就是说，这部分不用你管，工具会自己搞定。真正需要你操心的只有两类：BD 外部端口的引脚约束，以及你自己写的、引用 BD 内部路径的那几条。

3.4 综合实现阶段该盯哪几个点

代码写完、约束改完，跑综合之前先看一眼综合设置里的顶层模块是不是已经指向你的top。然后跑综合，重点看三处日志。

第一处是模块解析。综合日志开头的Analyzing Verilog file部分，应该能看到你的top.v和一堆design_1_*.v。如果只看到 top.v 没有 BD 相关的文件，说明生成目标没做，或者编译顺序没刷新。

第二处是黑盒警告。综合日志里如果出现[Synth 8-3331] design xxx has unconnected port或者black box类的警告，多半是端口没连全。这里要特别注意，端口没连不一定是错误级别，有时候只是 warning，综合照样能过，但实现后功能是坏的。凡是有 unconnected 字样，都值得点进去看看到底是哪个端口。

第三处是层次结构。综合完打开 Synthesized Design，看 Hierarchy 面板。正常情况应该是你的top下面挂着u_bd，u_bd下面挂着design_1_i，再往下才是各个 IP。如果u_bd下面空空如也或者显示成一个黑盒方块，说明 BD 没有正确展开。这时候去检查 Generate Target 是不是真的跑过，以及.gen下面的产物是否完整。

跑完实现之后，还有两个必看的报告：report_utilization看资源是否合理，report_timing_summary看有没有未约束的时钟。后者特别重要——如果你发现时序报告里出现了Unconstrained Paths，并且路径落在 BD 内部，那八成是某条时钟约束没传进去，回头检查上一节讲的路径问题。

4. 端口与约束适配中最容易踩的那些坑

4.1 报“Module not found”时的排查顺序

这个报错我遇到过无数次，原因就那么几种，按下面的顺序查基本三步之内能定位。

先确认 wrapper 文件是否真的在工程里。在 Sources 面板展开 Hierarchy，找design_1_wrapper这个 module。如果没有，说明make_wrapper没加-import，或者生成之后没刷新工程。

再确认编译顺序。在 Tcl Console 敲update_compile_order -fileset sources_1，然后重新打开 Sources 面板。手工添加的 RTL 文件如果顺序不对，综合器会先解析 top.v，此时它还不知道design_1_wrapper的定义在哪里，于是就报找不到。

最后确认顶层设置。report_property [current_fileset]或者直接看 Sources 面板顶部的 Top 标记。如果顶层还是指向 wrapper 或者别的模块，综合器会从那儿开始解析，自然看不到你的 top 里引用的东西。

还有一种比较隐蔽的情况：BD 被 Disable 了。在 Sources 面板里 BD 文件的属性如果被设成了 disable，工具不会生成它的 wrapper，也不会综合它。这种情况通常发生在你为了临时排除某个 IP 而手动禁用之后忘了恢复。

4.2 BD 一改，顶层就编译不过怎么办

这是方案 B 的固有代价，也是最需要提前做好心理准备的地方。系统工程师在 BD 里加了一根 AXI 信号、把某个外部端口从 8 位扩到 16 位，或者干脆改了端口的名字，你的顶层例化语句立刻就编译不过。

应对办法有三层。

第一层是端口命名解耦。前面说过，wrapper 端口名和顶层端口名不需要一致，中间靠例化映射。所以 BD 里端口改名时，只要方向位宽没变，你只要改例化语句左边那一半，顶层自己的信号名一个都不用动。这个设计让 BD 的改动影响被限制在一处。

第二层是把 wrapper 的端口清单当成接口契约。每次 BD 改动之后，重新 Generate 一遍，然后用 diff 工具比较 wrapper 前后两个版本的端口列表。有变化的地方，逐条对应到顶层的例化语句上。我用的是版本控制自带的 diff，直接看.gen下面那份 wrapper 的变化，比对着 BD 画布找差异快得多。

第三层是保留一份端口清单的文档。听起来很土，但真的很管用：把 wrapper 的端口名、位宽、方向、对应的顶层信号名整理成一张表，放在工程 README 里。BD 每次大改之后手动更新这张表。团队里新人接手、或者过半年自己回头看，这张表能省下大量重新读图的时间。

4.3 XDC 路径写错会以什么形式暴露

约束路径写错这件事有个特点：它几乎从不报“错误”，只是安安静静地不生效。所以你需要知道它不生效时是什么样子。

最常见的是引脚约束落空。你在 XDC 里写[get_ports led0]，但实际顶层端口叫led_0，这条约束匹配不到任何对象，Vivado 会在实现阶段报一条 Critical Warning：No objects matched 'get_ports led0'，然后这个端口就随机分配到某个引脚上。这类问题在上板前一定要清零，因为同样的约束换块板子可能就变成另一个引脚，行为完全不可复现。

其次是内部路径约束落空。你写[get_cells clk_wiz_0]，但实际路径是u_bd/design_1_i/clk_wiz_0，匹配不到。表现是这条约束被忽略，MMCM 的输出频率还是按 IP 默认值走。等你发现时钟频率和你预期不符时，已经烧了好几个 bit 流了。

排查方法还是那句：在 Tcl Console 里用get_cells -hier、get_ports、get_clocks现场验证。写完一条约束，立刻敲一遍对应的 get 命令，看返回的对象数量和名字对不对。这个习惯养成之后，XDC 相关的坑能少踩一大半。

4.4 常见问题速查表

5. 用历史用例做检索与适配的复用工作流

5.1 值得归档的到底是什么

做的时间长了会发现，BD 例化这件事本身没多少新东西，难的是每次都要重新翻旧工程找“上次那个 DDR 的顶层是怎么连的”。所以我现在的做法是建一个私人的代码片段库，专门归档这几类东西。

一是 wrapper 的端口清单。每个做过的工程，把.gen下那份 wrapper 的端口声明部分抽出来，去掉位宽之外的注释，存成一个<项目名>_bd_ports.vh。下次新工程端口结构类似，直接拿来做对照。

二是顶层例化模板。把 top.v 里例化 wrapper 的那一大段单独抽成一个模板文件，端口名保留成占位符。新项目开工时先把模板贴进去，再按新 wrapper 的端口清单逐条替换，比从零敲一遍快得多，也不容易漏端口。

三是 XDC 里的常用约束片段。差分时钟的 IBUFDS 引脚约束、常见 IO 标准的配置、内部时钟路径的引用方式，这些都整理成带注释的小块。新工程直接复制。

四是那次踩坑的记录。哪个端口位宽容易写错、哪个 IP 的复位极性反了、哪类约束在不同层级之间要怎么改，这些写在片段旁边一行注释里，比写在正式文档里更容易被翻到。

5.2 检索比对的落地做法

归档的东西多了之后，怎么快速找到需要的那一份就是个问题。我的做法是在库的根目录维护一个索引文件，每条记录包含项目名、芯片型号、BD 里包含的主要 IP（比如 DDR3 + AXI DMA + VDMA）、顶层端口数量。找的时候先按芯片型号和 IP 组合筛，通常能定位到两三个候选。

如果手上有本地知识库工具，也可以把这份索引喂进去做语义检索——比如直接问“带 VDMA 和 DDR3、1920x1080 视频输入的那个工程的顶层复位是怎么接的”，工具能把相关的片段捞出来。这部分的重点不在于工具本身，而在于你的归档要足够结构化：片段要独立成块，每块要有明确的用途标签，否则检索出来的东西还得自己拼。

检索出来之后一定要做适配，不能直接抄。适配的检查项我列了这么几条：

• 芯片型号是否一致，不一致的话 IO 标准、时钟资源、DDR 类型都要重新确认
• BD 的 IP 版本是否一致，不同版本的 IP 端口名有时会有细微差别
• 复位极性是否一致，这个最容易忽略
• 时钟频率是否一致，频率变了 MMCM 的配置参数和时序约束都要跟着改
• 差分对的引脚是否落在同一个 Bank 的合法位置

5.3 适配完成后的自检清单

历史用例复用完之后，我习惯在综合之前走一遍这个清单。它花不了十分钟，但能拦住绝大多数低级问题。

• 顶层模块名和工程顶层设置是否一致
• wrapper 的端口数量与例化语句的连接数量是否相等
• 每个inout端口是否都有对应的顶层inout声明
• 所有时钟输入是否都有create_clock约束
• 所有复位信号在顶层和 BD 之间的极性是否统一
• 有没有哪个端口只连了()空括号，也就是悬空
• 综合日志里unconnected相关的警告是否已经逐条确认过

这套流程跑顺了之后，一个新工程从 BD 定稿到顶层例化完成，通常半天之内就能进综合。省下来的时间都花在真正的逻辑调试上，而不是在端口名和约束路径之间来回折腾。

6. 几种进阶情形下的处理思路

6.1 一个顶层里塞两个 BD

多 BD 在中等规模项目里很常见。比如一个 BD 专门管处理器系统和 DDR，另一个 BD 管高速收发器和协议处理，两者在顶层通过 AXI 或者自定义流接口对接。

这种结构的做法是每个 BD 各自生成一份 wrapper，顶层里分别例化，实例名取成u_bd_ps、u_bd_gt这样能区分的名字。约束路径也要相应地分开写，u_bd_ps/design_1_i/...和u_bd_gt/design_1_i/...。

需要注意的是两个 BD 之间的接口。如果它们在画布上没有直接连线，而是在顶层用 RTL 对接，那接口信号的位宽和握手协议必须由你自己保证一致。这时候前面说的归档工作流就特别值钱——接口定义整理成一张表，两边改的时候对着表核。如果两个 BD 都想直接用 AXI 互联，也可以把其中一个 BD 的 AXI Master 引出来，在顶层接到另一个 BD 的 AXI Slave 端口上，但这样会多出一层组合逻辑，时序上要留意。

6.2 同一份 BD 想复用两份怎么办

这是个经典问题。你的 BD 里封装了一套图像处理流水线，一个工程里需要跑两路，是不是直接把 wrapper 例化两次就行了？

答案是不行。BD 生成出来的是一个带 OOC 综合单元的完整子系统，内部的 IP 实例名、时钟资源、甚至 ILA 都是全局唯一的。例化两次会直接撞车，实现阶段报错。

正确的做法是把 BD 复制一份。在工程里对 BD 文件做 Copy，改个新名字，然后在新 BD 里改掉 IP 实例名冲突的部分。这是最稳妥的路子，虽然看起来笨。另一种是走方案 C，把 BD 打包成 IP，IP 本身支持多实例，但打包时对端口和总线接口的要求更严格，适合长期复用的场景。

6.3 什么时候该转成 Package IP

如果你发现同一个 BD 已经在三个以上项目里被复制粘贴过，那大概率应该转成方案 C 了。把 BD 打包成 IP 之后，它能进 IP Catalog，可以按版本号管理，别的工程从 IP 仓库里拉就行，改动也只需要在一个地方改。

打包的操作路径是 Tools 里的 Create and Package New IP，选择 Package your current project 或者 Package a block design。打包过程中会要求你确认端口、设置 IP 的版本号和描述信息。打包完成之后，这个 IP 会出现在ip_repo目录下，通过set_property ip_repo_paths加到工程里就能用。

代价是每次 BD 改动都要重新 Package 一遍，而且打包之后的 IP 端口命名规则更严格，一些在 BD 里随手起的名字可能不过检。所以我的建议是先用方案 B 调通功能，等接口稳定了再打包，别一上来就上打包流程，那样调试阶段会被频繁的重新打包打断节奏。

顶层的例化这件事，说到底就是把 BD 生成的 wrapper 当成一个普通 module 对待，剩下的全是端口对齐和约束路径的细活。真正费时间的从来不是写那几行例化代码，而是 BD 改版之后怎么快速定位受影响的地方、怎么把历史工程里的经验安全地搬过来。我这几年的体会是，端口归档和约束片段的复用做得越早，后面越省事——哪怕只是一个放在工程根目录的 README，把 wrapper 的端口清单抄一遍，半年后再打开这个工程时你会感谢自己。