极客工场

Appearance

共 7,662 字预计阅读约 26 分钟

FPGA 原型验证专题 04：ASIC 原型验证全链路 RTL ID/GateID/层次映射 ​

本文是 FPGA 原型验证专题第 04 篇。多片怎么分区、跨片怎么互联见 02 多 FPGA 原型系统 ASIC 分区/TDM，平台搭好后怎么逐片点亮见 03 原型平台 bring-up 多片点亮/trace，片上调试寄存器怎么访问见 01 原型验证 Debug IP 寄存器是怎么被访问的。本篇不展开具体某一类分析，只讲一条通用的 FPGA 原型验证标准链路：数据怎么一步步流转、每步谁负责、三个关键标识在什么时刻诞生。

一、先理清三个“身份标识” ​

整条链路最容易混淆的，是三个名字很像、但产生时机和所处“域”完全不同的东西。先把它们立住：

标识属于哪个域什么时候有标识对象是否进比特流
RTL Hierarchy（原始层次）RTL 域ASIC 团队交付 RTL 时就存在源码里的模块实例树否
RTL IDRTL 域Compiler 前端展开（Elaboration）后分配每个 module 实例 / 端口 / 内部信号否
GateIDGate（网表）域Compiler 逻辑综合后分配网表里的每个 cell、每条 net否

一句话记住时间线：先有 Hierarchy（源码自带）→ 展开后有 RTL ID（随 RTL 固定）→ 综合后才有 GateID（随网表产生）。

三者靠一张 info_table 映射表串起来：GateID ↔ RTL ID ↔ 原始 RTL hierarchy 路径。没有这张表，上板采到的门级数据就是一堆“看不懂属于哪个模块”的网线翻转。

FPGA 原型验证专题 04：ASIC 原型验证全链路 RTL ID/GateID/层次映射 示意图（第 3 张）

二、全链路分阶段拆解 ​

下面按阶段 0~7 拆开。每一步都标注归属团队、输入、输出，并在关键位置提示 ID 的诞生时机。参与方有三个：

  • ASIC 设计团队——设计的源头与最终使用方；
  • Compiler 团队——原型编译器（把 ASIC RTL 变成 FPGA 可用网表的工具链）；
  • FPGA 原型验证团队——把网表落进 FPGA、跑起来、采数据。

阶段 0：前置输入交付（ASIC 设计团队） ​

  • 输入：SoC 项目规格。
  • 输出：完整的 ASIC SoC RTL（Verilog/SystemVerilog），面向 ASIC 流片开发，里面包含 SRAM、模拟宏、电源域、模块层次定义。
  • 要点：此时已有原始 RTL Hierarchy（源码的模块实例树），但还没有分配 RTL ID。

这份 RTL 是“为芯片写的”，天然带着 FPGA 无法直接实现的东西（定制 SRAM、模拟/PLL 宏、IO 宏），后面要靠 Compiler 做等价转换。

阶段 1：Compiler 前端——解析与展开 Elaboration（Compiler 团队） ​

  • 输入：ASIC SoC RTL 源码。
  • 输出：
    1. 设计的 AST（抽象语法树），以及实例展开后的完整层次树；
    2. 全局唯一的 RTL ID 表——给每一个 module 实例、端口、内部信号分配 RTL ID，并绑定到原始 RTL 层次路径；
    3. 设计检查报告：不可综合语法、黑盒清单、时钟域清单。
  • 核心工作：宏展开、条件编译、模块实例展开；遍历整棵设计树分配 RTL ID。

✅ RTL ID 在本阶段产生。只要原始 RTL 不修改，RTL ID 就固定不变。 这一阶段仍在 RTL 域，没有逻辑综合，因此不存在 GateID。

阶段 2：原型适配、设计转换、多 FPGA 分割（Compiler 团队） ​

  • 输入：带 RTL ID 的展开 RTL 实例树 + 原型平台硬件约束（FPGA 数量、跨片互联带宽限制）。
  • 输出：
    1. 适配 FPGA 的可综合 RTL——把 ASIC 专属单元替换掉（ASIC SRAM → FPGA BRAM，移除模拟 IP、ASIC IO 宏等无法在 FPGA 实现的部分）；
    2. 多 FPGA 分割后的子设计（多片平台场景），并生成跨 FPGA 互连与同步逻辑；
    3. 约束标记（dont_touch），保护需要观测的信号，避免后续综合优化把网线删掉。
  • 核心工作：ASIC RTL → FPGA 等价逻辑转换；模块分割、跨 FPGA 接口生成；全程保留原始 RTL 层次与 RTL ID 的关联。

分割与跨片 TDM 的具体取舍见 02 多 FPGA 原型系统 ASIC 分区/TDM。本阶段仍没有 GateID。

阶段 3：Compiler 逻辑综合——FPGA 逻辑网表 + GateID + info_table（Compiler 团队） ​

这是原型编译器自己的逻辑综合，区别于后面 Vivado 的厂商综合。

  • 输入：阶段 2 处理完的 FPGA 可综合 RTL。
  • 输出：
    1. FPGA 逻辑网表（EDIF/Verilog），描述布尔逻辑与网线连接——注意它不是 ASIC 标准单元网表；
    2. GateID：给网表内每一个 cell、每一条 net 分配全局唯一 ID；
    3. info_table 映射表初稿：GateID ↔ RTL ID ↔ 原始 RTL hierarchy 路径。
  • 核心工作：把 RTL 翻译成布尔网表；为所有单元/网线分配 GateID；回溯建立网表单元、网线与原始 RTL 实例的映射；保留 dont_touch。

✅ GateID 在本阶段产生，Gate 域到 RTL 域的映射基础也在此打下。

阶段 4：Vivado 综合 + 布局布线 P&R（FPGA 原型验证团队执行，Compiler 提供约束） ​

  • 输入：① Compiler 输出的 FPGA 逻辑网表；② SDC 时序约束、管脚约束、dont_touch 约束。
  • 输出：
    1. FPGA 原语级网表（LUT、FF、BRAM、DSP、BUFG 等原生可编程资源）；
    2. 时序报告、资源利用率报告；
    3. 比特流文件 .bit/.bin。
  • 核心工作：逻辑打包（technology pack），把 Compiler 的逻辑映射到 FPGA 硬件原语；布局、布线、收敛时序，达到原型运行频率。

🔑 比特流只包含 FPGA 芯片的配置二进制数据。网表、GateID、RTL ID、映射表都不会下载到芯片，只保存在工程服务器的文件里。

阶段 5：FPGA 上板运行（FPGA 原型验证团队） ​

  • 输入：比特流文件 + 测试激励/测试用例。
  • 输出：运行波形、内部信号 dump、运行日志、功能测试结果。
  • 核心工作：加载比特流配置 FPGA，SoC 等效逻辑开始执行激励；抓取内部信号、记录翻转、捕获波形。

上板怎么逐片点亮、怎么解决多片信号可见性，见 03 原型平台 bring-up 多片点亮/trace。

FPGA 硬件层面只识别映射后的物理网线。硬件采集到的信号属于 Gate 域、只关联 GateID，它不感知 RTL ID，也不知道原始 RTL 层次。

阶段 6：后处理——用 info_table 映射回 RTL 域（原型团队 + Compiler 团队配合） ​

  • 输入：① 上板采集的 Gate 域原始信号数据（波形/翻转统计）；② Compiler 交付的完整 info_table（GateID → RTL ID + RTL hierarchy）。
  • 输出：RTL 层次化的信号数据（如按 RTL 层次组织的翻转/波形文件），对齐到原始 ASIC RTL 层次。
  • 核心工作：查表映射，把 Gate 域数据翻译回原始 RTL 模块层次，按 RTL 实例聚合，输出 ASIC 设计工具能读取的文件。

这一步是整条链路“还得上、看得懂”的关键：没有 info_table 映射，板级数据无法被 ASIC 侧工具消费。

阶段 7：ASIC 后端分析（ASIC 设计团队） ​

  • 输入：映射后的 RTL 层次数据、ASIC 门级网表、ASIC 工艺库 .lib。
  • 输出：模块级 / 全芯片的功耗、时序等签核分析报告。
  • 核心工作：用 ASIC 流片对应的真实工艺库，完成静态/动态分析。

注意这里已经回到 ASIC 域：在 FPGA 上跑出的只是“等效逻辑的行为数据”，真正的签核结论要用 ASIC 网表和 ASIC 工艺库得出，FPGA 原型负责提供真实激励下的活动信息，而不是替代 ASIC 签核。

三、一张表看清全链路 ​

阶段负责团队输入输出关键 ID / 层次产出
0 前置交付ASIC 设计团队SoC 规格ASIC RTL 源码原始 RTL Hierarchy
1 Compiler 前端 ElabCompiler 团队ASIC RTLAST 实例树、RTL ID 表✅ RTL ID，全程固定不变
2 原型转换、多 FPGA 分割Compiler 团队带 RTL ID 的 RTL 树FPGA 适配 RTL、跨片逻辑、dont_touch保留 RTL ID，GateID 尚未生成
3 Compiler 逻辑综合Compiler 团队适配后 RTLFPGA 逻辑网表、GateID、info_table 初稿✅ GateID，建立 GateID↔RTL ID 映射
4 Vivado 综合 P&RFPGA 原型团队网表 + 约束FPGA 原语网表 + 比特流ID 不变；逻辑打包到 LUT/FF 等资源
5 FPGA 上板运行FPGA 原型团队比特流 + 测试激励Gate 域原始采集数据硬件只识别 GateID 对应的网线
6 后处理映射原型 + Compiler 团队Gate 域数据 + info_tableRTL 层次化数据文件GateID 查表映射回 RTL ID / 层次
7 ASIC 签核分析ASIC 设计团队RTL 域数据 + ASIC 网表 + .libASIC 分析报告基于 RTL ID / 层次做统计分析

四、通用链路图 ​

FPGA 原型验证专题 04：ASIC 原型验证全链路 RTL ID/GateID/层次映射 示意图（第 4 张）

五、最容易踩的三个认知坑 ​

  1. 把两级综合当成一级。 Compiler 的逻辑综合产出的是与器件无关的 FPGA 逻辑网表并分配 GateID；Vivado 才把它打包映射到具体型号的 LUT/FF/BRAM。前者保映射关系，后者出能下载的比特流。
  2. 以为 ID 会跟着比特流上板。 比特流只有配置数据，RTL ID、GateID、层次、映射表全部留在服务器。所以上板采到的信号天生是 Gate 域，必须回服务器查 info_table 才能还原成 RTL 信号。
  3. 以为改一点 RTL，ID 还能对得上。 RTL ID 只在“RTL 不改”时固定；一旦源码改动重新展开，RTL ID/层次可能漂移，对应的 GateID 与 info_table 也要随那一版网表重新生成。版本对齐（RTL 版本 ↔ 网表/比特流版本 ↔ info_table 版本）是后处理能查表的前提，这和 03 原型平台 bring-up 多片点亮/trace 强调的“RTL/比特流/软件四方版本一致”是同一条纪律。

六、阶段 0 详解：可原型化 RTL 的交付标准 ​

原型链路的质量在 ASIC 团队交付 RTL 的那一刻就已基本决定，Compiler 不能无中生有地修复不可综合或不可观测的设计。交付标准至少包括以下内容。可综合性：时钟由显式时钟树产生而不是门控逻辑拼出（门控要可被识别替换）、无 initial 依赖（FPGA 上电态与仿真不同）、异步路径有明确的同步器结构、存储用行为级 SRAM 宏以便替换为 BRAM 模型；ASIC 专属单元（PHY、PLL、定制 RAM、模拟宏）必须有清晰的边界和 FPGA 替代模型（行为模型、降速接口或 transactor），这些替换清单是原型适配的第一份文档。层次纪律：模块边界与物理分区倾向一致——跨大层次的隐式全局状态和海量细粒度信号会让分区割集爆炸（02 多 FPGA 原型系统 ASIC 分区/TDM 的核心矛盾）；需要观测的总线和状态机应保持稳定的层次路径和命名，频繁重命名会让信号探针、波形配置和回归脚本全部失效。

时钟与复位声明：交付包要显式列出所有时钟域、源、频率关系和复位树，因为原型会改变频率（降频）并插入跨片时钟；依赖具体周期数的电路（波特率发生器、超时计数器、训练序列）要参数化或走真实速率外设岛。存储与地址图：SRAM 宏清单（容量、端口、时序）、地址映射、可替换为外挂 DDR 的大存储标注清楚。验证资产：软件可见的启动方式、最小可运行固件、已知失败列表、需要真实接口的清单。阶段 0 的评审应是三方评审（ASIC、Compiler、FPGA 团队），任何“到时候工具会处理”的假设都要落到具体替换方案；原型阶段 80% 的非物理问题都能追溯到交付标准未闭环。

七、阶段 1～3 详解：Compiler 到底改了设计什么 ​

原型编译器不是简单的格式转换器，它在保持功能等价的前提下对设计做了一系列 FPGA 适配和物理分割，理解这些变换才能读懂后续所有 ID 和约束。**前端展开（Elaboration）**处理参数、generate、宏和条件编译，把设计实例化成一棵确定的层次树，在这一步分配的 RTL ID 绑定到“实例路径+端口/信号”；这也是为什么源码里参数化实例的数量变化会导致后续 ID 漂移。原型转换包括：ASIC 门控时钟转成 FPGA 时钟使能或 BUFGCE、保持寄存器（latch）转触发器、三态/上拉等 FPGA 不支持的网内结构改写、存储宏替换为 BRAM/URAM 或外接 DDR 行为模型、时钟分频/握手插入；多 FPGA 分割在这一层完成，跨片信号被 TDM 宏和同步器包裹（02 多 FPGA 原型系统 ASIC 分区/TDM 第六节）。所有这些变换都必须保留可观测性——关键内部信号要有“保持点”（dont_touch 类属性），否则综合优化后无法映射回 RTL。

逻辑综合把适配后的 RTL 编译成厂商无关的门级网表，分配 GateID，并生成 info_table：每条 net、每个 cell 对应到哪个 RTL ID、属于哪个层次路径，经过了哪种变换（直通、复制、TDM 打包、存储替换）。这张表是后面所有调试和分析的“罗塞塔石碑”，它必须和具体一次网表构建严格绑定。阶段间的版本纪律：RTL 改动即使只加一个寄存器，也可能改变实例编号和门级映射，因此正确流程是每次原型构建产出一个不可变的构建 ID，RTL 快照、适配脚本、网表、info_table、后续比特流和波形配置全部挂在该 ID 下；混用不同构建的表和比特流是原型数据错误中最难发现的一类——系统“能跑”，但观测到的波形归属错模块。

八、阶段 4 详解：两级综合的边界与常见失败 ​

Compiler 网表进入 Vivado（或厂商工具链）后发生第二级综合：逻辑门被打包（pack）进 LUT/FF/BRAM/DSP/CARRY 等物理原语，再布局布线到时序收敛并生成比特流。两级综合各有不可替代的职责：第一级回答“ASIC 语义如何等价地变成 FPGA 逻辑并保持可映射性”，第二级回答“这些逻辑如何装进具体型号并达到原型频率”。工程上最常见的失败是把第二级的问题误投给第一级。其一，时序不收敛：原因多为跨片 TDM 路径、跨 SLR 长线、原型时钟域约束错误，而不是功能问题；手段是分区约束（紧耦合同片）、Pblock、降低原型时钟，不能通过修改 RTL 功能去“适配”。其二，资源映射冲突：行为存储模型被推断成分布式 RAM 导致 LUT 爆掉，或多端口 SRAM 替换模型端口时序不合法，需要在适配层改存储映射。其三，黑盒/未解析单元：ASIC 宏的替代模型缺失，网表里留下未实现模块，这类问题在 link 阶段必须报错而不是静默通过。

其四，约束漂移：Compiler 输出的时序/引脚约束与板级版本不匹配（收发器 lane、时钟引脚、平台固件版本），需要把板级约束作为平台数据单独版本化。其五，优化吃掉观测点：用于调试的信号被第二级综合优化消失，需要在网表层保持并在物理实现后用工具的调试网络重新接入。实践中应把“Compiler 输出可装入率”（网表在目标平台资源、引脚、TDM 预算内的比例）和“一次实现通过率”作为流程指标，分别度量转换质量和平台容量健康度。比特流生成后必须回读构建 ID（经管理口/版本寄存器），确认板上跑的正是对应 info_table 的那一版——这一步在 03 原型平台 bring-up 多片点亮/trace 的版本矩阵中强制执行。

九、阶段 5～6 详解：采集数据为什么必须回服务器映射 ​

上板运行阶段产生的数据天然是 Gate 域的，理解这一点能解释许多“波形对不上模块名”的困惑。FPGA 下载后只包含配置位，trace 网络把选中的物理网线在触发时刻的翻转采样进片上缓冲（03 原型平台 bring-up 多片点亮/trace 讲了 trace 系统本身），这些网线在硬件上的身份就是布局布线后的物理标识；它与 RTL 信号之间隔了两级综合的优化：一个 RTL 信号可能被复制成多份（高扇出复制）、被常量传播消除、与其它信号合并进同一个 LUT、被打包进 TDM 帧跨片传输，多个 RTL 信号也可能分时共享一条物理资源。反过来，一条被采集的 net 通过 GateID 能在 info_table 里查到它源于哪个/哪些 RTL ID、经过了什么变换；遇到复制和合并，映射工具需要按变换规则还原（或明确标注该信号不可直接观测）。

因此后处理不是简单的改名，而是一次带语义的查表变换：Gate 域波形按 info_table 还原到 RTL ID，再按层次路径聚合成 ASIC 工具的波形/活动文件（如用于功耗分析的 SAIF、用于调试的波形数据库）。这一步必须在工程服务器上完成，原因有三：info_table 体量大且是公司 IP 映射信息，不下发；映射规则随 Compiler 版本演进；分析要和 RTL 版本、综合脚本、ASIC 工艺库严格对齐。实践中的易错点包括：用旧构建的表分析新比特流的数据（版本错位，必须用构建 ID 拦截）、trace 点选在了被优化信号上（应在综合前的信号清单里指定 keep 属性）、跨片 TDM 信号没做时间对齐（各片 trace 需要全局触发和时间戳，见 03 原型平台 bring-up 多片点亮/trace）。把“采集在板、解释在服务器、版本必须同源”作为铁律，后处理问题会大幅减少。

十、阶段 7 的正确定位：原型能签什么、不能签什么 ​

ASIC 团队最终消费原型数据做后端分析时，必须清楚 FPGA 原型提供的是“真实激励下的活动信息”，而不是硅片时序、功耗或物理特性。可以签/强支持的：功能正确性、软硬件协同、完整软件栈和长周期场景（仿真无法达到的周期数）、真实接口互操作、模块活动率/翻转率输入（结合 ASIC 网表和工艺库做功耗分析，活动来自 FPGA 但计算用 ASIC .lib）、架构性能的量级评估（带宽、吞吐、缓存命中率等与频率关系不绝对的指标）。不能签的：ASIC 时序（STA 和门级仿真负责，FPGA 经过降频和 TDM，延迟完全不同）、绝对功耗和漏电（器件工艺不同）、模拟/RF 行为、精确到周期的接口时序（真实 PHY 子系统另有验证）。

组织上要防止两种极端：一是“原型都跑通了所以流片没问题”——忽视形式验证、STA、CDC 等本应由工具签核的项；二是“原型反正不代表时序所以没价值”——浪费了唯一能在流片前跑完整操作系统和真实流量的平台。正确定位是把它放进分层验证体系：仿真负责定向和覆盖率，仿真加速（emulator）负责超大规模周期和统一调试，FPGA 原型负责真实软件/接口与高吞吐活动数据（与 02 多 FPGA 原型系统 ASIC 分区/TDM 的能力边界一致）。分析报告应明确标注每个数字的来源域和换算方法，功耗报告里翻转率来自原型、电容/延迟来自 ASIC 库，两者不可混淆。

十一、三方协作的接口工程 ​

链路跨三个团队，绝大多数效率损耗发生在团队接缝而不是技术本身，接口要像 IP 契约一样管理。ASIC→Compiler 的交付接口：固定节奏的 RTL 快照（tag）、可综合性报告、时钟/复位/宏清单、存储替换需求、信号观测需求（希望在原型上抓的总线和状态机，综合前声明）、最小固件；变更要走变更说明（哪些模块/层次受影响），因为即使功能等价，重命名或搬层次也会使观测配置失效。Compiler→FPGA 团队的交付接口：适配后的网表、板级约束（哪些片、引脚、TDM 速率）、info_table、构建 ID、未解析/被替换单元清单、已知不可观测信号表、建议的原型频率；任何“工具自动处理”的部分都要有报告可审。FPGA→两方的回流接口：上板结果按构建 ID 归档（功能通过/失败、能跑到的频率、资源利用率、TDM 延迟、trace 数据），失败时区分平台问题（板级/链路/容量）和设计问题（功能/死锁），前者 FPGA 团队闭环，后者生成可在仿真复现的最小序列回到 ASIC 侧。

协作机制建议：共享一个构建数据库（构建 ID 关联 RTL commit、Compiler 版本、网表、info_table、比特流、板级结果），任何人拿到波形都能一键查到它对应的全部版本；联合 triage 会议处理跨域故障，按 03 原型平台 bring-up 多片点亮/trace 的证据链裁决；观测信号清单和固件接口在项目早期冻结，后期新增要评估重新综合成本；Compiler 升级当作平台变更，旧构建可复现。把这些接口文档化、工具化之后，三方的边界就从“互相等”变成“各自并行、按契约集成”，这是大型原型项目吞吐率的真正决定因素。

十二、日常构建节奏：从 RTL 提交到上板结果 ​

大型 SoC 原型验证不是一次性构建，而是与 RTL 开发并行数月到一年以上的持续流水线，其节奏需要像软件 CI 一样管理。典型节奏分三档：每日构建（nightly）——从主干拉取通过仿真冒烟的 RTL，自动完成 Elab、适配、综合、分区、多 FPGA 实现并生成全套比特流和 info_table；由于一次全量构建可能耗时数小时到十几小时，通常夜间调度，早晨产出构建 ID、资源/TDM/频率报告和失败点。每周稳定构建（weekly candidate）——通过平台基线（链路、DDR、存储）和系统冒烟（启动、最小固件、接口环回）的每日构建才提升为候选，交给软件和验证团队做长场景。里程碑构建——配合软件版本和验证计划冻结，支持回归测试集和长时间 soak。

让流水线健康运转需要几个关键机制。第一，失败快速归因：构建失败按阶段分类（Elab 语法/不可综合、适配缺模型、分区容量/割集溢出、实现时序、烧录），自动抄送对应团队，避免所有问题都堆给原型团队；分区容量和割集要画趋势曲线（02 多 FPGA 原型系统 ASIC 分区/TDM 的容量看板），提前两周预警而不是在冻结点爆炸。第二，结果可复现：Compiler、Vivado、平台固件、适配脚本和约束全部版本锁定并写入构建清单（manifest），同一个构建 ID 在任何机器上能复现同一批比特流。第三，比特流分发与烧录自动化：构建产物推送到平台调度系统，多块板卡按队列下载、跑冒烟、回报结果（03 原型平台 bring-up 多片点亮/trace 的平台运营），软件团队早上拿到的是“可登录的系统”而不是一堆 bit 文件。第四，观测配置随版本管理：信号探针清单、trace 深度、触发条件挂在构建 ID 上，旧波形能用旧配置复现。把构建当软件产品运营，原型平台对项目的实际吞吐才能接近其硬件能力。

十三、常见问题速查与一页纸总结 ​

把跨团队最常问的问题收成速查表。问：改了一行 RTL，波形怎么对不上了？答：RTL 改动会重新展开和综合，RTL ID/GateID/info_table 都可能漂移，必须用新构建 ID 的比特流和映射表重新采集，不能沿用旧 trace 配置。问：为什么这个信号在探针列表里找不到？答：它可能被常量传播消除、与其它信号合并或复制，需在 RTL/适配层加观测保持属性，并在 info_table 里确认物理可观测性。问：比特流里能不能直接查到模块名？答：不能，比特流只有配置位，所有层次信息留在服务器的映射表。问：板上跑的是哪个版本？答：读管理控制器维护的构建 ID/版本寄存器，并与发布清单核对，bring-up 第一步永远是版本握手。问：功耗/翻转率数据给后端为什么还要换算？答：FPGA 采集的是 Gate 域活动，先映射回 RTL，再结合 ASIC 网表和工艺库计算，FPGA 器件功耗数字本身不进入 ASIC 签核。问：综合后资源够但分区失败？答：瓶颈多半是割集（片间信号/收发器预算）或某类资源（BRAM/DSP）局部耗尽，看分区报告的逐片多维权重，而不是总门数。

一页纸总结：链路的本质是三次身份转换——源码实例树（Hierarchy）经展开获得稳定的 RTL ID，经原型综合产生 GateID 和 info_table，经厂商工具物理实现成比特流；ID 和映射只活在工程服务器，板上只有门级物理行为，观测数据必须回查同一构建 ID 的映射表才能回到 RTL 世界。组织上，ASIC 团队负责设计源头与最终签核、Compiler 团队负责等价转换和可观测性、FPGA 原型团队负责物理落地和平台运营，三方以构建 ID 为共同主键、以阶段化交付物为契约。把“ID 何时产生、什么不下板、数据为何回查、版本如何对齐”四件事讲清楚，新人就能在这条跨越软件、工具链和硬件的长链路里快速定位自己的问题。

总结 ​

ASIC RTL 自带层次，Compiler 展开时发 RTL ID、综合时发 GateID 并用 info_table 把两者绑死；Vivado 只负责把网表装进 FPGA 出比特流，ID 与映射表一律不下板；上板采到的是 Gate 域数据，靠查表映射回 RTL 层次，最后交回 ASIC 侧用真实工艺库做签核分析。看懂“ID 在什么时候产生、哪些东西不下板、数据要怎么映射回去”，就看懂了整条原型验证链路。