FPGA 原型验证专题 07：面向原型的 ASIC RTL 交付规范——层次树、黑盒、宏与电源域的交付清单
更新时间：2026-09-12。本文是「ASIC FPGA 原型验证系统」专题 06~25 深体系列分册，对应阶段 0（ASIC 设计团队交付）。总览见 06 原型验证系统全景与文档地图、全链路见 04 ASIC 原型验证全链路 RTL ID/GateID/层次映射。芯片侧的可综合纪律见 RTL 设计 与 可综合 RTL 编码规范。
这一篇在链路里的位置
阶段 0 的输出是后续所有自动化的输入。原始 RTL Hierarchy（源码模块实例树）在此时已确定、但还没有任何 ID；它是 Elaboration 分配 RTL ID、最终 Gate→RTL 回映的唯一锚点。层次混乱、黑盒不声明、模拟宏不隔离，会把问题全部推给 Compiler 团队并反复返工。
本文要回答的问题
- 模块层次该怎么划分，才利于后续分割、观测与回映？过深/过平各有什么问题？
- 哪些东西在 FPGA 上根本不存在（模拟宏、定制 SRAM、PHY、IO 宏、电源开关），交付时如何显式隔离？
- 黑盒/加密 IP/第三方 IP 如何声明，需要配哪些行为模型或占位模型？
- 时钟/复位网络为什么要"干净、单一、可识别"？内部生成时钟、门控时钟在原型上怎么处理？
- 参数化、`define、条件编译如何管理才能保证原型构建与 ASIC 构建行为一致？
- 一次合格的 RTL 交付包包含哪些文件与文档（checklist）？
一、交付物定位：一份 RTL，两个视图
ASIC 团队只维护一份面向流片的 RTL，但这份 RTL 要同时满足两个消费者：ASIC 流程（综合、DFT、STA、功耗签核）和原型 Compiler。原型视图不是 fork 一份代码去改——fork 必然漂移、很快与真芯片不一致——而是通过统一的条件编译开关、统一的层次、显式的隔离边界，让 Compiler 从同一份源码派生出原型配置。交付规范的目标只有一个：让「不可综合 / 黑盒 / 时钟域」三类问题在交付时就是已知、已声明、有模型的，而不是等 Compiler 展开时报几十万个错再回头猜。
二、层次设计：实例树即契约
原始 Hierarchy 是后续 RTL ID 分配（10 RTL ID 体系 分配规则/层次绑定/稳定性）、多 FPGA 分割（12 多 FPGA 分区算法 割集/容量/图划分）、信号回映（23 Gate→RTL 数据回映 查表/聚合/SAIF）的共同锚点。四条原则：
- 层次边界 = 功能边界 = 分割边界。子系统、IP、时钟域用清晰的 module 实例分开，Compiler 才能以模块为原子切到不同 FPGA；把所有逻辑摊平在一个万行 module 里，分区器只能在网线中间硬切，跨片连接爆炸；
- 深度适中。过深（十几层胶水 wrapper）让 RTL ID 路径冗长、观测信号难定位；过平又失去分割与复用粒度。经验上 5~8 层、每层 5~20 个子实例较健康；
- 保留边界要显式声明。需要保留层次的模块打
(* keep_hierarchy *)或交付清单里列出，防止后续综合跨边界打平（flatten）后无法回映； - 端口即观测窗。关键状态、总线尽量出现在模块端口或命名规范的内部信号上（如
dbg_*、trace_*），阶段 2 插桩（14 可观测性插桩 dont_touch/probe/可见性预算）时这些信号才保得住。
三、不可实现清单：FPGA 上不存在的东西
交付时必须把下列构造隔离在薄而显式的边界模块后面，并随交付包提供原型替身，而不是让它们散落在业务 RTL 里：
| 类别 | ASIC 里的形态 | 原型处理责任方 |
|---|---|---|
| 模拟/混合信号 | PLL 模拟部分、ADC/DAC、bandgap、晶振电路 | 整体旁路 + 数字行为模型/外部仪表（11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY） |
| PHY / SerDes 模拟前端 | DDR PHY、PCIe SerDes、MIPI | FPGA 硬核 PHY 直连或环回 + 数字模型 |
| 定制存储 | 编译 SRAM/ROM、register file、register file compiler 输出 | memory wrapper 映射 BRAM/URAM（11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY） |
| IO 宏 | 定制 pad、电平转换、ODT | FPGA IO bank + LVDS/SelectIO |
| 电源管理 | power switch、isolation、retention、level shifter、PMU | 折叠为常上电的功能模型 |
纪律是所有这类单元只通过统一 wrapper 例化（如 asic_sram_wrap、asic_pll_wrap），交付包提供同名 FPGA 实现，Compiler 改文件列表即可整体替换；禁止业务代码直接例化厂商标识符的硬宏。
四、黑盒与第三方 IP
加密/第三方 IP（CPU 核、DDR controller、PHY API）通常拿不到 RTL，交付时必须同时给三样东西：①黑盒声明（端口、参数、时钟复位要求），让 Elaboration 不报 unresolved；②行为模型或功能存根（仿真用 BFM 或可综合简化模型，二选一取决于原型要验证什么）；③License/使用边界说明（能否进 FPGA 比特流、是否允许上多片平台）。只丢一个黑盒、不给模型，是最常见的返工源——Compiler 无法凭空造出一个 CPU。模型与实物的功能差异必须登记进替换台账（08 不可综合构造识别与存根替换 模拟IP/时钟门控），避免软件团队拿原型行为当真芯片结论。
五、时钟与复位交付：干净、单一、可识别
Compiler 要据此生成时钟网表、跨片时钟与约束（18 原型约束体系 SDC/XDC/跨片时序/例外），交付包必须附时钟表：每个时钟的名字、源头（PLL/管脚/内部分频）、频率、占空比、驱动哪些模块、与哪些时钟异步。原型友好的纪律：
- 时钟只允许从 PLL/管脚/统一时钟模块出来，禁止计数器译码、组合逻辑造时钟（ASIC 里用 ICG 的地方在原型转成时钟使能 CE，见 08 不可综合构造识别与存根替换 模拟IP/时钟门控、11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY）；
- 内部分频时钟在原型上由 MMCM 直接生成同源时钟，或改为 CE 使能，不要真的造新时钟网络；
- 复位采用统一的「异步断言、同步释放」复位释放模块（参见芯片侧 复位设计），每个时钟域一个释放点，复位拓扑图画进交付文档，方便多片平台广播复位与对齐（13 跨 FPGA 互联与 TDM SerDes/跨片同步/降频）。
六、电源域 / UPF：无电源概念的 FPGA 怎么办
FPGA 的 LUT/FF 没有「断电」语义，UPF 描述的 power domain、power switch、isolation cell、retention flop 在原型上一律折叠为始终上电：隔离单元建模成常通连线（隔离值可配成常 0/常 1 以便软件演练隔离行为），保持锁存器按普通寄存器处理，电源开关用一个「虚拟电源开关」模型把开关事件转成时钟/使能冻结并记录。要点是电源控制寄存器接口必须保留——PMU 固件要在原型上完整演练上电/下电序列与状态机，只是看不到真实漏电变化。UPF 折叠规则做成替换库的一部分（11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY），并明确标注「功耗绝对值、retention 时序不可在原型验证」。
七、参数与配置管理：单一事实源
原型构建与 ASIC 构建行为必须一致，配置只能有一个事实源：
- 所有结构参数（地址宽度、队列深度、核数、使能特性）集中在顶层
define/parameter 配置包，禁止散落在各文件的 magic number 与defparam`； - 条件编译宏（
`ifdef FPGA_PROTO）只许出现在官方 wrapper/隔离层里，业务 RTL 中不得泛滥，否则两份视图必然漂移； - 每次交付给出配置指纹（宏集合 + 参数值 + git hash + 配置文件 hash），它必须能与后续 RTL ID 表、info_table、比特流版本对上（10 RTL ID 体系 分配规则/层次绑定/稳定性、20 比特流烧录与四方版本一致 manifest/门禁）。
八、交付 checklist 与典型返工
一次合格的阶段 0 交付包：① RTL 文件列表 + include 顺序；② 顶层与配置参数文件（配置指纹）；③ 时钟表、复位拓扑；④ 黑盒/第三方 IP 清单及模型；⑤ 存储实例清单（位宽×深度×数量×端口类型）；⑥ 不可实现单元隔离说明与 FPGA wrapper；⑦ 已知不可在原型验证项声明；⑧ 版本标签（与 ASIC 里程碑对应）。
| 典型返工 | 根因 | 本规范对应的预防条 |
|---|---|---|
| Elab 报上万 unresolved module | SRAM/PHY 裸例化、无 wrapper | §三 统一 wrapper |
| 分区器切不出好结果 | 逻辑全摊平、层次无功能含义 | §二 实例树即契约 |
| 原型比真芯片少中断 | 组合译码造时钟/门控未转 CE | §五 时钟纪律 |
| 软件在原型跑通、硅上 PMU 序列错 | 电源控制接口在折叠时被删 | §六 保留控制接口 |
| 改一行 RTL 后调试信号全错位 | 参数散落、ID 大面积漂移 | §七 单一事实源 |
九、交付门禁的自动化：让「可接收」不靠人肉评审
阶段 0 交付的质量如果靠专家逐行读 RTL 来把关，项目一大就必然失守；成熟流程把交付规范变成一组可机器执行的门禁检查，在设计团队提交时就给出红黄绿。第一层是结构检查：用脚本解析 RTL 的模块实例树，核对层次深度、单模块规模、例化名是否稳定唯一、是否存在例化数组（generate 展开后实例命名规则能否被展开器稳定复现）、是否有动态位选拼接导致的不可展开写法；这些检查与具体功能无关，纯属「编译器前端能不能吃」的语法工程问题，却占了早期返工的大头。第二层是可综合性检查：用综合器的 lint/elaborate-only 模式跑一遍，收集 latch 推断、多驱动、敏感表不完整、initial 块、延时、force/release、不可展开的系统任务等告警，按白名单分级——ASIC 流程里合法但 FPGA 不接受的构造要么改 RTL、要么在替换规则库里登记，不允许「先交了再说」。第三层是清单一致性检查：时钟复位表、黑盒清单、存储清单、参数单一事实源与 RTL 本身交叉核对——表里声明的每个时钟都能在 RTL 里追到源头，每个黑盒都有对应的 FPGA 模型或 stub，每个宏/参数的定义位置唯一。门禁结果与提交号绑定，红项不允许进入展开队列，黄项需 Compiler 团队签收。自动化的深层价值是把三方协作从「口头约定」变成「契约即代码」：设计团队提交前本地就能跑同一套检查，大部分问题在自己工位上五分钟内暴露，而不是等 Compiler 团队 overnight 展开失败后开扯皮会。门禁还应统计趋势——每次交付新增了多少告警、多少黑盒、多少例外——让质量退化在早期可见，而不是某天突然发现不可综合的特殊单元已经扩散到上百个模块。
十、两个视图的版本管理：RTL 一条线，原型适配另一条线
「一份 RTL、两个视图」要在版本管理上落地，关键是不让 FPGA 适配改动污染 ASIC 主线，同时保证两条线永远对得上版本。推荐的组织方式是：ASIC 设计团队的 RTL 仓库是唯一上游，原型侧的所有改造（时钟原语替换、stub、参数覆写、封装层）放在独立的适配层仓库或独立目录，通过明确的包含/覆盖机制在构建时合成「原型视图」，而不是直接 fork 一份 RTL 到处手改。fork 的死法都一样：主线修了 bug，fork 不知道；fork 为上板加的逻辑，回流时被当成功能改动评审，最后两份代码谁也说不清差异。适配层里每个文件头部必须记录：它替换/包裹的是哪个上游模块、为什么替换（对应不可实现清单的哪一条）、替换关系的等价性分级、适用的上游版本范围。构建系统按上游提交号 + 适配层提交号生成双坐标版本，ID 体系（见 54 篇）对「上游 RTL 未变则 ID 不变」负责，适配层变更则触发受影响子树的重新分配。原型团队发现的真 bug（功能错误，而非适配问题）必须走上游正常流程修复并回归，严禁在适配层里偷偷打功能补丁——那会造成「原型上验证通过的逻辑和即将流片的逻辑不是同一份」。反过来，设计团队重构模块名、例化名、层次之前，要能从 ID 影响面报告里看到这次改名会让多少采集配置、波形脚本、历史数据失效，从而选择合适的合并窗口。两条线的边界划得越干净，原型验证「代表真实设计」的可信度就越高；边界一旦模糊，所有上板结论的根基都会被质疑。
十一、存储与时钟信息的交付深度：最容易被低估的两件事
在所有交付信息里，存储清单和时钟复位信息看起来最琐碎，实际上决定了后续分区、时序和采集能不能自动化，值得单独提高交付标准。存储交付不能只给「设计里有几块 RAM」，而要列出每个存储实例的层次路径、深度、位宽、端口数与读写行为、是否可推断为双口 BRAM、复位策略、是否需要内容初始化（及初始化文件来源）、在目标 FPGA 上预期映射成 BRAM/URAM/分布式 RAM 中的哪类。原因在于存储器是 FPGA 上最「硬」的资源：它不能像逻辑那样被 LUT 随意拼凑，分区时存储落在哪片 FPGA 直接决定周围逻辑的归属，替换库（见 55 篇）也要凭这份清单选择模型。漏报一个深层小 FIFO，可能让分区算法在最后阶段被迫推倒重来。时钟复位交付要给出时钟拓扑图：每个时钟从哪里来（端口/MMCM/恢复时钟）、频率、占空比、哪些是同源、哪些异步、门控时钟（ICG）的位置和使能语义、复位是同步还是异步、复位断言与释放的预期电路、每个时钟域包含哪些模块。Compiler 据此把 ICG 转成时钟使能、插入复位同步器、在分区时避免把同一时钟域撕开、在约束阶段（见 62 篇）自动生成时钟关系。时钟复位信息只存在于「设计师脑子里」是最危险的状态——接手的人只能靠猜，猜错的代价是亚稳态和错版采集。把这两份清单的模板设计成「填不满就不能提交」，比任何文档宣讲都有效。
十二、参数、宏与配置项的治理：规模放大后最先失控的东西
小设计里参数散落在各个文件里无伤大雅，亿门级原型上它们会变成最隐蔽的错版来源——同一个地址映射在三个文件里各写了一份、某个特性开关在仿真配置打开而原型配置关闭、存储深度按工艺宏切换后忘了通知原型侧。参数治理的目标是让「一份设计的配置空间」只有一个事实源。集中配置包：所有影响结构的参数（地址基址与位宽、队列深度、实例个数、特性开关、工艺标识）定义在唯一的配置包/头文件中，RTL、软件头文件、验证环境、原型适配层都从它生成，禁止在模块内写魔数。结构化配置而非散落宏：用 parameter 显式逐层传递，比编译期全局宏可追踪——宏在编译命令行里被覆盖时不会在层次里留痕，而 parameter 传递链能从展开树里审计每个实例实际拿到的值。配置的矩阵化：一个芯片往往有多种 SKU 或裁配版本（通道数、核心数不同），每种配置是配置包里的一个命名目标；原型构建直接引用目标名，manifest 记录本次是哪个目标，避免「我以为跑的是 16 通道版本，实际是 8 通道」。差异审查：配置项的每次变更在评审里显示结构影响——哪些实例数、存储大小、地址映射变了，这些变化自动联动分区资源预估和软件链接/设备树生成。原型特有参数隔离：为上板引入的参数（TDM 槽位、观测点数量、降频比）属于适配层配置，与功能配置物理隔离、颜色不同、命名空间不同，杜绝为调试改的深度值误回流到 ASIC 主线。软件可见配置的一致性：硬件配置生成的软件头文件（寄存器地图、地址定义）必须与比特流同源同版，64 篇的版本握手在配置层面也要成立。参数治理没有炫技成分，它的全部价值在事故复盘时才看得清——大量「功能在仿真对、上板错」的案子，根因不是时序也不是 CDC，而是两处本应相同的参数悄悄分叉。
十三、第三方 IP 与黑盒的接收实践
真实芯片里第三方硬核/软核（处理器、接口控制器、PHY 配套逻辑、加密核）可能占整体规模的相当比例，它们在原型链路上的处理方式与自研 RTL 不同，值得专门的接收流程。交付物清点：第三方 IP 通常以加密 RTL、网表或二进制形式交付，原型团队拿不到源码。接收时要确认：黑盒边界（端口清单与时序模型）是否完整、是否提供功能仿真模型（行为模型往往与硬核模型分开授权）、在 FPGA 上的落地路径是什么（厂商有无官方 FPGA 包，没有则需要自研替换模型，工作量要提前评估）、授权是否覆盖原型用途（有些授权只允许仿真，上板另有费用和协议）。功能等价性的分级处理：有官方 FPGA 移植包的（如处理器核的 FPGA 原型包），可信度最高但接口可能不同（缓存控制器、时钟结构按 FPGA 改了），差异要登记；只有行为模型的，功能可跑但性能/时序不代表硬核，活动数据在该模块范围内不可用于签核；完全无模型的，只能做协议级 stub（52 篇），对应功能路径整体标灰。集成顺序：第三方 IP 应作为最早点亮的子系统之一——它们的问题不掌握在自己手里，越晚集成，等待对方支持的风险越靠近关键路径；先用最小环回测试确认 IP 与适配层、时钟、复位编排协同正常，再把自研逻辑挂上去。版本管理：第三方 IP 版本独立于你的 RTL 版本演进，manifest 必须记录其精确版本和补丁；供应商发新版时在隔离分支验证后再合入，不要在冻结窗口追新版本。责任界面清晰化：出问题时能快速区分是 IP 内部问题（走供应商工单，附最小用例）还是集成问题（时钟、复位、约束、管脚），靠的就是接收阶段建立的边界测试集——每个黑盒都有一个独立于系统的自测设计，证明「IP 本身在这块板上能工作」，系统问题排查时才能理直气壮地越过它。把第三方 IP 当成「有供货周期和独立版本节奏的外部组件」来管理，而不是一堆特殊的 RTL 文件，排期风险才会显形。
十四、交付成熟度模型：从「能跑」到「可接收」的分级
最后给设计团队一把自检尺子：原型可接收性不是布尔值，而有明确的成熟度梯度，每一级的特征和「还欠什么」可以直接对照。零级：能仿真。RTL 在仿真里功能正确，但从未考虑过任何物理实现——大量 initial、延时、行为存储、未定义黑盒。这是正常的开发中状态，不是可交付状态。一级：可展开。结构合法：层次稳定、例化完整、参数可解析、generate 规则，编译器能生成完整实例树而不报错；时钟复位表和黑盒清单初步存在。这一级解决的是「机器能不能读懂你的设计」。二级：可综合。所有结构都有 FPGA 落点：不可综合构造已改造或登记替换，存储可推断，时钟全部可识别（ICG 已转 CE），lint 红项清零。这一级解决「能不能变成门」。三级：可分区可实现。规模与接口预算经得起布局：资源多维预留裕量、IO 替换模型齐备、跨域结构清晰、时序约束输入完备，一次完整构建能产出全部比特流且时序满足原型频率。这一级解决「能不能装进板子并跑起来」。四级：可调试可追溯。观测点已规划，dont_touch 与 ID 体系稳定，替换台账和能力边界声明完整，任何上板现象都能查回 RTL 层次。这一级解决「跑出来的数据算不算数」。五级：可回归可运营。交付物支持自动化：门禁全绿、版本元数据齐全、BIST 可跑、配置可参数化复现，软件团队能自助使用而不需要原型工程师全程陪同。原型团队追求的接收目标是四级半到五级；停在二级就急着上板，是项目时间线最大的单一风险来源。成熟度评级应由门禁工具自动给出初稿、评审确认，随每次交付更新——它让「设计还要改几轮」从印象变成可计划的事实。
十五、从一次返工看交付规范的价值
规范的说服力最终来自事故。这里给出一个综合了多个真实项目要素的返工案例，展示交付清单上每一项是如何对应到真金白银的等待时间的。某项目在冻结后第三天上板点亮失败，排查序列如下：首先是一批黑盒端口对不上——上游模块把一个使能信号从电平改成脉冲，但黑盒清单没有变更记录，展开阶段的延迟绑定放过了不一致，直到综合收口才报错，修复加重新构建一天。接着，存储清单漏报了两个深层小 FIFO，它们在分区落定后才被发现，存储所在的芯片资源已紧，分区被迫重排，TDM 比整体抬升一档，又耗掉两天并让频率回到爬坡前。随后时钟评审发现一处逻辑分频时钟未登记，复位表也没有标注它的复位域，团队花了半天争论这个域该不该有独立复位同步器，最终改 RTL 再过夜构建。等链路训练通过，跑最小向量时发现一个第三方 IP 用的是旧版行为模型，与主线接口假设不符，而模型版本既不在清单里也不在 manifest 里，无法自动发现，靠人工翻邮件才定位，又是一天半。总计一周的点亮延期，逐项回看：端口契约检查会拦住第一项，完整存储清单会拦住第二项，时钟复位交付模板会拦住第三项，IP 版本登记和 manifest 绑定会拦住第四项——没有一项需要天才，全都是交付规范里的平凡条目。反例同样有教育意义：同团队的下一个项目严格执行门禁，首次点亮一次通过，之后的说法从「上板总有意外」变成了「意外都前移到了提交前五分钟」。交付规范不是文书工作，它是把本项目最贵的资源——多片平台的占用时间和整个下游团队的等待——保护起来的唯一手段。每个觉得填清单麻烦的设计师，都值得在板卡农场旁边坐一夜，看一次因为清单缺失导致的全平台空转。
十六、交付节奏：冻结窗口、变更通道与跨团队沟通机制
交付规范的条目再多，若没有配套的节奏与沟通机制，也会在项目压力下变形。原型项目里最常见的组织性事故，是设计团队在“冻结”之后继续修自己的仿真 bug，而 Compiler 团队拿到的仍是冻结当天的快照，双方各自推进一周后，上板现象与仿真对不上，排查半天才发现版本错位。可行的节奏设计是三窗口制：冻结窗口内只接受阻断级修复，任何合入必须附变更说明（改了哪个层次、端口是否变化、时钟/存储清单是否受影响），由 Compiler 团队评估对 ID、分区和比特流的冲击面；常规窗口接收一般功能变更，但约定固定的集成日（如每周两次），Compiler 只对集成点构建，避免“每小时追最新源码”的无效构建；预冻结窗口停止结构性改动，只允许不改变层次和接口的局部修复。每个窗口内，交付包不是一封邮件，而是落在制品库里带配置指纹（见 07 面向原型的 RTL 交付规范 层次/黑盒/电源域）的不可变快照，所有下游构建只能引用指纹，禁止直接拉取活动分支。
沟通机制上，两个低成本高回报的约定值得固化。一是变更通告模板：任何可能影响原型的合入必须回答四问——层次路径有无增删、端口/位宽/时钟有无变化、是否新增黑盒或存储、原型不可验证项是否变化；通告自动推送到 Compiler 与软件团队，结构变更（会引起 ID 漂移的那种，见 10 RTL ID 体系 分配规则/层次绑定/稳定性）要显式标红，因为观测脚本和波形回映依赖 ID 稳定。二是每日联合站会的最小议程：昨天交付了什么、今天上板验证什么、谁被什么阻塞，时间控制在十五分钟内，目的不是汇报而是让“等待”当天显形——原型平台的占用费和团队空转成本远高于沟通成本。当节奏、通道、责任人三者都固定下来，交付规范才从“文档上的要求”变成“没人能绕开的默认工作方式”。
十七、给 ASIC 设计师与原型工程师的双向清单
最后把规范压缩成两份可直接贴在工位上的短清单，分别面向交付的两端。ASIC 设计师交付前自检：第一，全局 grep 一遍 initial、延时符号、$random、force/release，确认它们只出现在仿真专用文件里，文件名或宏保护能被构建直接排除；第二，所有存储都经过统一 wrapper，没有任何业务模块直接例化工艺厂的 SRAM 编译器产物；第三，时钟只来自管脚、PLL 或统一时钟模块，所有 ICG 在原型宏下变成时钟使能，没有任何计数器译码当时钟；第四，复位极性、同步/异步断言方式在全设计一致，每个异步复位都有标准同步释放结构；第五，黑盒、加密 IP、模拟宏各有一份清单，端口、参数、时钟、模型文件与授权范围齐备；第六，时钟表与复位表填到“陌生人能据此写约束”的程度；第七，参数和宏只从唯一配置包取，本地没有散落的编译开关；第八，交付包附带配置指纹、版本标签和一份“原型不可验证项声明”，明确告诉下游哪些路径在 FPGA 上是假的、软件团队不能据此下结论。
原型工程师接收时核对：配置指纹能否干净重现一棵实例树，无 unresolved 模块；黑盒模型与交付清单中的版本完全一致；时钟表与 RTL 实际时钟点数量对得上，没有“清单外的时钟”；存储 wrapper 全部能映射到目标器件资源且总容量留有余量（见 11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY）；电源域替换后 PMU 寄存器接口仍然存在且可演练；结构变更影响面已用 ID 差异报告核对（见 10 RTL ID 体系 分配规则/层次绑定/稳定性）；不可验证项声明已同步给软件团队。双向清单的意义不是制造 paperwork，而是让两个团队在交付的第一天就对“这份 RTL 在 FPGA 上意味着什么”有完全相同的心智模型——原型项目里最贵的从来不是综合时间，而是一方以为对方知道、其实双方都不知道的那一周。
知识脉络
与系列及现有篇目的衔接
- 下一步（阶段 1）：09 编译器前端展开 Elaboration AST/实例树、10 RTL ID 体系 分配规则/层次绑定/稳定性
- 不可综合的处理细节：08 不可综合构造识别与存根替换 模拟IP/时钟门控
- 单元替换：11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY
- 现有基础：02 多 FPGA 原型系统 ASIC 分区/TDM、芯片侧 RTL 设计
总结
一句话总结：同一份面向流片的 ASIC RTL 要靠条件编译、统一层次与显式隔离派生出原型视图，而不是 fork 改代码；阶段 0 交付规范决定后面所有自动化的成本——原始模块实例树是 RTL ID、多 FPGA 分割和 Gate→RTL 回映的共同锚点，所以层次边界要等于功能边界与分割边界、深度适中、关键边界显式 keep_hierarchy、关键信号留在端口或规范命名上；模拟/混合信号、PHY、定制 SRAM、IO 宏、电源单元必须只通过统一 wrapper 例化并随包交付 FPGA 替身，加密第三方 IP 必须同时给黑盒声明、行为模型/存根和 License 说明；时钟复位要交一张完整时钟表并坚持「时钟只从 PLL/管脚/时钟模块来、ICG 转 CE、分频用使能、异步断言同步释放」的原型友好纪律；UPF 电源域在无电源语义的 FPGA 上折叠为常上电模型，但电源控制寄存器接口必须原样保留让 PMU 固件演练；结构参数与宏必须单一事实源并产出配置指纹，最终交付包至少包含文件列表、配置、时钟复位表、黑盒与存储清单、隔离 wrapper、原型不可验证项声明和版本标签八件套——交付时「已知、已声明、有模型」，Compiler 阶段的不可综合问题能下降一个数量级。