FPGA 原型验证专题 37：原型、Emulation 还是仿真——按验证目标选引擎的决策树与多引擎排班
更新时间：2026-09-13。本文是模块 A 第二篇。06 原型验证系统全景与文档地图给了三手段的速度/成本/可见性光谱表，27 在电路仿真 ICE 与协同加速模式 接线/时钟纪律讲原型内部 ICE 与协同加速两种模式怎么接线；本篇往上走一层，回答项目调度层面最常争论的问题：这个用例到底该放仿真器、Emulator 还是 FPGA 原型？一个项目里这些引擎怎么排班才不浪费钱？41 原型在 SoC 验证矩阵中的定位 用例分配/RACI/证据移交会把它落到验证计划级的用例分配矩阵。
一、先消除一个常见误解：不是三选一，而是接力
很多立项讨论把"买不买原型/Emulator"当成互斥决策，这是错的。对一个有完整验证预算的 SoC 项目，三类引擎在时间轴上接力、在同一时间点上分工（47 篇第八节的接力曲线）：
- 逻辑仿真器（simulation）：kHz~MHz 等效、编译以分钟计、任意信号全可见、断言精确定位、随机约束和功能覆盖率最强，是 RTL 大改期唯一现实的引擎，承担模块/子系统级功能回归。
- 硬件仿真器（Emulation，处理器阵列式专用硬件，如 Palladium/ZeBu）：0.5~5 MHz、容量巨大（可装整颗芯片含 DFT 结构）、可见性接近仿真器（全信号可回溯）、支持多人分时和事务级加速，按机时收费极贵，承担子系统刚稳定后的跨模块联调、完整芯片上的长软件早期执行、功耗早期活动分析。
- FPGA 原型：1~30 MHz（甚至更高）、一次性平台投入后机时极便宜、可见性受插桩预算限制、编译一轮数小时到一天，承担 RTL 接近冻结后的真实软件/OS、真实接口流量、长稳 soak、架构性能相对评估。
关键认知：**越靠左速度越慢但可见性越强、编译越快、单位使用越便宜（仿真 license 摊到每次回归）；越靠右速度越快、越接近真实世界，但可见性越差、编译越慢、单次硬件准备成本越高。**决策树的本质是给每个验证任务找"速度够用且可见性/周转可接受"的最便宜引擎。
二、四种工作模式先对齐口径
决策前先把容易混淆的四种"跑法"分清（26 事务处理器 SCE-MI 三类通道/transactor 实现、27 在电路仿真 ICE 与协同加速模式 接线/时钟纪律有工程实现）：
| 模式 | 拓扑一句话 | 速度/真实度 | 典型用途 |
|---|---|---|---|
| 纯逻辑仿真 | testbench+RTL 全在主机 CPU 事件驱动 | 最慢，全可见 | 模块回归、UVM、随机验证 |
| 事务级加速 | DUT 在加速硬件，激励以事务经 transactor 注入，主机侧只发高层事务 | 中快，可见性好 | 早期全芯片、长软件、无需真接口 |
| 协同加速（co-sim） | 硬件跑 DUT，主机跑行为模型/测试，按同步点交换信号/事务 | 中等，混合精度 | RTL 未冻结期、部分 IP 还在主机建模 |
| ICE 在电路仿真 | 加速硬件/原型经速率适配直连真实器件和接口 | 最快、最真实 | 真软件、真流量、协议互通、soak |
注意 Emulator 和 FPGA 原型都能跑后三种模式，差别在 Emulator 的事务级/协同加速成熟度和可见性远高、且无需为真实接口做物理引脚上的速率适配设计（它有专门的速率适配机箱/虚拟接口），而 FPGA 原型的 ICE 速度更高、机时更便宜但要自建子卡体系（31 速率适配器 Speed Adapter 弹性FIFO/两种范式）。
三、选型决策树（五个判据逐步分流）
给验证 lead 一个可直接照着走的决策流程：
逐条展开判据：
- 变更率判据（最先看）。RTL 还在频繁结构性变化时，硬件引擎一轮构建数小时~一天，调试一个改动等一周，团队实际吞吐远低于仿真。只有当跨子系统接口开始收敛、模块级功能基本稳定，才上加速硬件。47 篇的经验信号：模块级变更频繁留仿真，跨子系统接口变更收敛后上 Emulation，接口冻结、版本节奏变周级再大规模铺 FPGA 原型。
- **周期数判据。**估用例所需时钟周期：模块功能测试几万~几百万周期，仿真轻松且定位最强；启动 OS、跑网络协议栈、视频通路、长稳测试是几十亿~万亿周期，仿真跑到天荒地老（1 MHz 跑 10 亿条指令要 1000 秒，仿真实际只有 kHz 级即需数天到数周），必须上加速硬件。
- **真实世界判据。**任务是否依赖真实 PHY 电气行为、真实主机/设备枚举、真实 OS 的时序预期？不需要→事务级加速最划算（不必配物理接口，Emulator 上虚拟模型即可，26 事务处理器 SCE-MI 三类通道/transactor 实现）；需要→ICE，且若追求高速度/低成本长稳选 FPGA 原型，若 RTL 尚在动或要极高可见性选 Emulator 的 ICE 模式。
- **可见性判据。**是否需要观测任意内部信号、从崩溃点回溯任意长时间波形、密集断言？Emulator 基于处理器阵列天然保留全信号可见性（类似仿真器的全信号 dump），FPGA 原型只看得见插桩的信号且深度受 trace 预算限制（39 商用原型调试 IP 深跟踪/动态探针/可见性预算、45 Trace 带宽与深度工程 采样/缓冲/压缩/回传管线）。bring-up 早期根因未明、需要反复看内部信号时，Emulator 的可见性价值远超其机时费。
- **成本/并发判据。**Emulator 按分钟计费、适合精选的长用例（跑过的场景沉淀为回归资产反复用）；FPGA 原型一次性投入后可以开多板并行、7×24 小时 soak 和性能基准。要大规模并行、长时间占用、多软件团队同时开发时，FPGA 原型的边际成本碾压。
四、典型任务的引擎归属速查
| 验证任务 | 首选引擎 | 理由 |
|---|---|---|
| 模块级 UVM 回归、随机约束、覆盖率收敛 | 逻辑仿真 | 全可见、编译快、随机/功能覆盖生态最强 |
| 新 RTL 的跨模块接口 bug 狩猎 | 仿真→Emulator | 先仿真定位快；周期长的跨子系统场景上 Emulator |
| 全芯片第一次跑通启动 ROM/裸机 | Emulator（事务/加速） | 周期长、要全可见、RTL 还在动，不必上真接口 |
| 固件/驱动早期开发（29 固件 shift-left RTL 冻结前 bring-up/驱动开发） | Emulator→原型 | 早期要可见性用 Emulator，冻结后迁原型多板并行 |
| 完整 Linux/Android 启动、长稳 soak（30 Linux/RTOS 在原型上启动 启动链/降频补偿/时间换算） | FPGA 原型 ICE | 周期万亿级、要真接口、机时便宜可长开 |
| 真实 PCIe/网络/MIPI 互通（74/75 篇） | FPGA 原型 ICE | 依赖真实 PHY/对端设备 |
| 功耗早期活动分析/SAIF（25 真实激励驱动 ASIC 签核 SAIF 反标/边界） | Emulator 早期 + 原型后期 | 早期向量快、更真实场景后期补 |
| 架构性能 A/B（42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除） | FPGA 原型 | 用 cycle 计数做相对比较，需较高速度跑真实负载 |
| 海量并发回归/多软件团队日常 | FPGA 原型农场 | 边际成本低、可并行（农场运营见 F2 主题） |
五、多引擎排班：一条项目时间线
把决策树放到时间轴上，成熟团队的典型排班：
- 需求/架构冻结~RTL 大改期（T0 起数月）：仿真独占。Emulator/原型团队不闲着——按 06 原型验证系统全景与文档地图提前做平台准备：选板（77 篇）、容量规划（F1 主题）、替换库、时钟复位 harness（27 在电路仿真 ICE 与协同加速模式 接线/时钟纪律）、transactor 与环境移植。
- 子系统接口收敛期：Emulator 进场接第二棒。第一次在完整芯片上联调中断、缓存一致性、启动序列；软件团队开始早期固件（70 篇）；用例从仿真精选有代表性的长场景迁上来，跑通的 Emulator 用例沉淀为资产。
- RTL 接近冻结、版本节奏周级：FPGA 原型大规模进场接第三棒，多板并行，OS、真实接口、soak、性能基准、活动采集（24 活动覆盖率与性能调试闭环 热点/瓶颈/回放）铺开；Emulator 不退役，继续承担"内部信号深度可见的疑难 bug 复测"和早期功耗活动。
- 流片后：原型保留做硅前用例的硅后对照、errata 复现（05 原型到硅后衔接 pre/post-silicon 协同/errata）。
反向流动也常见且必要：原型上发现的偶现 bug，若需要任意信号深度回溯，把同一用例和镜像拿回 Emulator 甚至仿真复现（缩小场景、加断言）——这正是 41 原型在 SoC 验证矩阵中的定位 用例分配/RACI/证据移交讲的多引擎证据移交。不要因为"原型快"就坚持在可见性最差的引擎里啃硬骨头。
六、让多引擎不浪费钱的三个工程支点
多引擎最大的隐性成本是"每个引擎重搭一套环境"。把成本压下来靠三件事：
- **testbench/transactor 分层复用。**激励分成"高层事务场景"（引擎无关）和"底层驱动器/接口适配"（引擎相关）。同一套高层场景接仿真 BFM、Emulator transactor、原型的事务处理器（21 激励注入与软硬协同 co-model/transactor、67 篇）。垂直整合平台（77 篇第一类）的主要价值就在这一层的可移植性。
- **软件镜像单一事实源。**固件/OS 镜像、寄存器头文件/SVD、内存映射一份代码，按引擎差异做最小的板级支持层（29 固件 shift-left RTL 冻结前 bring-up/驱动开发），避免为三个引擎维护三套软件。
- **统一的结果回收与可信度口径。**覆盖率、活动数据、性能数字在不同引擎采，用各自的可信度边界标注后合流（41 原型在 SoC 验证矩阵中的定位 用例分配/RACI/证据移交、43 原型结果可信度分级 可签核/可决策/仅参考与报告规范），否则"三个引擎三个说法"会让管理层无法决策。
七、实例：一颗网络 SoC 的引擎排班怎么走一遍
把决策树和排班落到一个具体项目，避免停留在抽象表格。假设一颗多核 + 硬件包处理 + 多口以太网的网络 SoC，关键里程碑和引擎动作：
| 项目阶段 | 引擎上实际在跑什么 | 这个阶段最容易犯的错 |
|---|---|---|
| 架构评审后 | 仿真跑各引擎模块 UVM；平台团队用规模估算定 4~6 片、定接口子卡清单（36 商用原型平台版图 HAPS/Protium/第三方能力边界） | 等 RTL 写完才启动平台，白白丢两三个月 |
| 包处理引擎初版 | 仿真定向+随机验证解析/调度/改写；不上原型 | RTL 每周重构期硬上板，分区反复返工 |
| 子系统接口收敛 | Emulator 事务级加速跑"收包→查流表→改写→发包"整链；软件团队在此写第一个寄存器读写裸程序 | 一上来追求真网络口，事务级阶段不必配 PHY |
| 全芯片第一次启动 | Emulator 上跑 FSBL→SMP 唤醒→中断分发，全信号可见定位启动死锁 | 用原型啃启动早期 bug，跨片看不见只能猜 |
| RTL 冻结候选 | 构建原型比特流，ICE 模式接真实测试仪/主机，Linux 驱动上线（30 Linux/RTOS 在原型上启动 启动链/降频补偿/时间换算） | 冻结当天才第一次构建，时序/割边问题全挤到最后 |
| 冻结后稳态 | 原型农场多板并行：线速混合流量 soak、路由表百万表项压力、热插拔/链路 flap、驱动 LTP/回归 7×24 | 把这类长占用任务留 Emulator，机时费失控 |
| 疑难复测 | 原型发现"跑 20 小时偶发乱序"→导出镜像和流量脚本，回 Emulator 加断言缩场景复现 | 坚持在原型上死啃、看不到内部仲裁时序 |
| 架构微调 | 改流表缓存路数做 A/B（42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除），两版同分区、数 cycle 比吞吐/失序率 | 用墙钟 iperf 数字下结论，跨片伪延迟污染 |
这个例子里有个成本直觉值得建立：Emulator 机时以分钟计费，适合"跑几分钟到几小时、要反复看内部"的联调和难 bug；原型一次性买定后边际近乎零，适合"跑几天、多块板、多软件组并行"的 soak 和软件日常。把前者控制在精选场景、把后者的利用率拉满（农场调度 F2 主题），多引擎总花费往往比"只用一个引擎硬扛"低。
八、给不同角色的选引擎速答
同一张决策树，不同岗位关心的入口不同，按角色给一份速答：
- RTL 设计工程师：你在改的模块还在每周动 → 仿真；接口冻结后要验证"我这块在整芯片里的行为" → 上 Emulator 做第一次系统联调；只有当你要确认真实软件/真实流量下的行为时才需要原型，且你的交付物必须先满足 07 面向原型的 RTL 交付规范 层次/黑盒/电源域（可综合、时钟复位干净、黑盒声明完整），否则平台团队会把网表打回来。
- 验证工程师：功能覆盖率和断言回归永远在仿真；周期数过长的跨子系统场景迁 Emulator 并保留可回溯可见性；需要真实软件栈/真实接口/长稳背书的场景才上原型，且原型结果按 43 原型结果可信度分级 可签核/可决策/仅参考与报告规范分级，不与功能覆盖率混算。
- 软件/固件工程师：RTL 冻结前用 Emulator 事务级模式先做裸机和驱动（29 固件 shift-left RTL 冻结前 bring-up/驱动开发），不必等真接口；冻结后日常开发和 OS 调试在原型，多板并行时找农场预约机时；遇到需要看芯片内部信号的硬 bug，主动要求把用例退回 Emulator，而不是在原型上猜。
- 架构师：微架构 A/B 在原型上用 cycle 口径做（42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除），但绝对指标和物理相关结论去仿真分析/STA；早期方案空间大、迭代频繁时仿真+分析比任何硬件都快。
- 项目经理：记住排期上的两个不可逆窗口——平台准备必须在 T0 启动（等 RTL 写完再买板必丢两三个月），软件大规模上板必须等接口冻结（提前上只会让平台团队变成慢速综合器）；Emulator 机时费要按"精选场景资产"批预算，原型投入按"避免一次 respin"算回报（44 自建/购买/租云原型 TCO 模型 盈亏平衡/机会成本）。
九、常见坑速查
- RTL 还在每周大改就上多板原型 → 原型团队沦为慢速综合器，改一轮等一周；
- 把 Emulator 当原型跑 7×24 soak → 机时费爆炸，长稳该用原型；
- 把原型当仿真器找内部根因 → 可见性不够，难 bug 回 Emulator/仿真；
- 三引擎各搭一套 testbench 和软件 → 环境成本超过硬件成本；
- 只按速度选引擎，忽视编译周转和可见性 → 决策树要五判据全过；
- 用例迁引擎不沉淀、不标注证据等级 → 无法在引擎间移交和对账。
与系列及现有篇目的链接
- 平台选型与成本：36 商用原型平台版图 HAPS/Protium/第三方能力边界、44 自建/购买/租云原型 TCO 模型 盈亏平衡/机会成本
- 模式与事务处理器：27 在电路仿真 ICE 与协同加速模式 接线/时钟纪律、26 事务处理器 SCE-MI 三类通道/transactor 实现
- 验证计划与可信度：41 原型在 SoC 验证矩阵中的定位 用例分配/RACI/证据移交、43 原型结果可信度分级 可签核/可决策/仅参考与报告规范、42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除
- 机制与背景：06 原型验证系统全景与文档地图、34 与仿真器互联、21 激励注入与软硬协同 co-model/transactor
总结
一句话总结：仿真、Emulation、FPGA 原型不是抢预算的三选一，而是按 RTL 成熟度接力、按验证任务分工的三档引擎——仿真 kHz~MHz、分钟级编译、任意信号全可见、随机约束和覆盖率最强，独占 RTL 大改期的模块回归；Emulator（处理器阵列专用硬件）0.5~5 MHz、容量大、接近仿真器的全信号可回溯、支持事务级加速和多人分时但按分钟极贵，承接子系统接口收敛后的全芯片首次联调、早期固件、需深度可见性的疑难复测和早期功耗活动；FPGA 原型 1~30 MHz、一次性投入后机时极便宜可多板并行 7×24，但只看得见插桩信号、编译一轮数小时到一天，承接接口冻结后的真实 OS、真实接口 ICE、长稳 soak 和架构性能；选型走五判据决策树——先看 RTL 变更率（每周大改一律留仿真）、再算所需周期数（万级仿真、亿到万亿级上加速硬件）、再问是否必须真实器件/PHY/软件时序（否则事务级加速最划算，不必配物理接口）、再看任意信号深度可见与断言回溯要求（高且预算够选 Emulator）、最后看并发与机时成本（大规模并行长占用选原型农场）；排班上平台团队在 T0 就提前做选型/容量/替换库/harness/transactor 移植，仿真独占大改期、Emulator 接子系统收敛期、原型接冻结期且 Emulator 不退役用于难 bug 复测，用例在引擎间正向迁移、难 bug 反向回退到高可见性引擎；要让多引擎不浪费钱，靠高层事务场景引擎无关、底层驱动按引擎适配的 testbench 分层复用（垂直整合平台的核心价值），软件镜像/寄存器描述/内存映射单一事实源，以及覆盖率/活动/性能结果按各自可信度边界标注后合流，绝不能在还在每周大改时把原型当慢速综合器、把 Emulator 当 7×24 soak 机、或在可见性最差的原型里死啃需要全信号回溯的内部根因。