FPGA 原型验证专题 41：原型在 SoC 验证矩阵中的定位——仿真、Emulation、形式、原型的分工、用例分配与证据移交
更新时间：2026-09-13。本文是模块 E（验证方法学、性能与可信度）第一篇。06 原型验证系统全景与文档地图给三手段能力光谱，37 原型/Emulation/仿真选引擎 决策树/多引擎排班给单任务选引擎的决策树；本篇站在验证经理/验证计划的视角，回答"整个项目的验证需求如何在引擎间分配、原型到底对哪些结论负责、各引擎结果如何对账"。43 原型结果可信度分级 可签核/可决策/仅参考与报告规范进一步给结论的可信度分级。
一、核心立场：原型负责"仿真够不着的真实"，不负责"仿真做得更好的正确"
一个反复出现的管理误区是把原型当"更快的仿真器"，要求它承担功能正确性签核。这是错配：
- 原型可见性受限（39 商用原型调试 IP 深跟踪/动态探针/可见性预算）、编译慢、抽象层不完整（模拟/PHY 被替换，11 ASIC→FPGA 等价单元替换 SRAM/时钟/IO/PHY）、时序是 FPGA 的不是 ASIC 的——用它做功能完备性验证，既低效又无法给出覆盖率证明。
- 原型不可替代的价值是规模 × 真实度：能在接近真实的速度上跑完整软件栈、真实接口流量、超长时长，暴露出"模块都对、拼起来才错"的系统级问题——死锁、竞态、软件假设、协议互通、资源泄漏、长稳退化。这些在仿真里要么跑不到、要么要数年机时。
所以在验证矩阵里，仿真/形式负责"证明正确"，原型负责"证明它在真实规模和真实负载下真的能跑、且没暴露出系统级问题"，Emulation 居中补"规模大但还要高可见性"的空档（37 原型/Emulation/仿真选引擎 决策树/多引擎排班）。
二、验证目标 × 引擎 分配矩阵
| 验证目标 | 仿真 | 形式验证 | Emulation | FPGA 原型 | 说明 |
|---|---|---|---|---|---|
| 模块功能正确性/UVM 回归 | ●主力 | ○定点 | ○ | — | 随机约束+覆盖率（24 活动覆盖率与性能调试闭环 热点/瓶颈/回放） |
| 控制/协议死锁、缓存一致性 | ○ | ○定点证明 | ●大规模 | ●长时暴露 | 形式证明有界，原型暴露真实负载竞态 |
| 全芯片启动链/裸机 | — | — | ●早期 | ●后期 | 30 Linux/RTOS 在原型上启动 启动链/降频补偿/时间换算 |
| 软件/驱动/OS 兼容（29 固件 shift-left RTL 冻结前 bring-up/驱动开发） | — | — | ○早期 | ●主力 | 软件用例覆盖是原型核心产出 |
| 真实接口互通（PCIe/网/MIPI） | — | — | ○虚拟 | ●ICE 主力 | 33 PCIe/SerDes 上原型 硬核/降速子卡/LTSSM |
| 长稳 soak / 压力 / 资源泄漏 | — | — | ○ | ●主力 | 只有原型机时撑得住 7×24 |
| 架构性能相对评估（A/B） | — | — | ○ | ●主力 | cycle 口径，42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除 |
| 功耗活动向量（25 真实激励驱动 ASIC 签核 SAIF 反标/边界） | ○ | — | ●早期向量 | ●真实场景 | 原型供真实活动，签核仍在 STA/功耗流 |
| 模拟/混合信号、真实时序 | ×替换/×非ASIC时序 | — | × | × | 四引擎都不签，靠仿真+硅前专项（43 原型结果可信度分级 可签核/可决策/仅参考与报告规范） |
"×"尤其重要：明确写出原型不验证什么，比列它验证什么更能防止结论被过度采信。
三、从验证需求到用例分配：可追溯表与 RACI
工程上把上面的矩阵落成一张需求—用例—引擎—签核人的可追溯表：
- 需求分解：每条架构/微架构/软件/接口需求派生可度量的验证场景（不只是"测一下 PCIe"，而是"枚举 5 类主机、完成 10 Gbps 链路训练、4 KB 混合读写 1 小时无错"）；
- 指派主引擎与辅助引擎：按矩阵定每个用例的"主跑引擎"，其他引擎是否需复现；
- 定通过标准与证据形式：仿真用断言+功能覆盖，原型用软件日志/性能计数/soak 无错时长/抓帧正确率等；
- RACI：谁负责执行（原型/仿真/软件团队）、谁批准（验证经理）、咨询谁（RTL 设计）、知会谁（架构/项目）；
- 双向追溯：每条需求至少一个用例、每个用例对应已执行的 run（关联 20 比特流烧录与四方版本一致 manifest/门禁），杜绝"需求无人认领"和"跑了但没人要求"的孤儿 run。
四、同一 bug 在引擎间移交需要什么证据
多引擎协作的高频动作是"原型上发现 bug → 交给仿真/形式定位修复 → 修复后回原型确认"。移交若只发一句"Linux 跑着跑着挂了"，会浪费数周。合格的移交证据包（与 03 原型平台 bring-up 多片点亮/trace一致）：
- 环境指纹：RTL commit、综合网表/比特流 ID、软件镜像与配置、TDM 时隙表版本（20 比特流烧录与四方版本一致 manifest/门禁、40 多板多 FPGA 全局触发与时间对齐 跨片 trace 同步）；
- 最小化复现步骤：启动方式、用的命令/流量、复现概率（必现/10 次出 3 次/跑 N 小时）；
- 观测证据：原型 trace（已对齐重组，81 篇）、软件日志、串口/bootlog、性能计数；
- 收敛线索：已排除的假设、与正常 run 的差异（diff 配置/波形）；
- 回传要求：修复在仿真证明后，回原型用同一用例、相近版本关闭，并在追溯表登记。
反向（仿真修了、上原型验证）同样要指定用例和验收口径，避免"仿真过了就算完"而系统级问题未复测。
五、原型覆盖率：另一套口径，且不能冒认功能覆盖率
原型不回收 UVM 意义上的功能覆盖率（它不跑随机约束 testbench，24 活动覆盖率与性能调试闭环 热点/瓶颈/回放讲的是活动/剖面数据回收，不要混淆）。原型自己的"覆盖"是另外四类：
- 软件用例覆盖：真实软件栈实际执行了哪些驱动路径、系统调用、异常处理——用代码覆盖/执行轨迹度量（哪些驱动代码从没被跑到）；
- 场景矩阵覆盖：把"外设组合 × 流量模式 × 电源状态 × 启动方式"列成矩阵，逐格执行打勾；
- 时长/压力覆盖：soak 累计小时数、峰值带宽/并发连接/满载内存压力下的表现；
- 边界与异常场景：热插拔、掉电、链路降级、FIFO 满反压、错误注入（D4 主题）。
合流方式：原型覆盖率回答"真实世界的大场景都跑过且没出错"，仿真功能覆盖率回答"设计的功能点被定向/随机激励覆盖且断言通过"。两者在验证汇总表里并列呈现、各自统计、互不替代，共同支撑流片决策。最危险的反模式是用"原型连续跑了一周没挂"去顶替缺失的功能覆盖率——没挂可能只是没跑到。
六、把"跑了很久"变成"验证了什么"
原型机时便宜，很容易积累大量"看起来很努力"的 run，但 run 数不等于验证度。每个原型 run 入库时强制填写：对应哪条需求/用例、跑了什么版本、通过标准、结果、日志/trace 存档位置（20 比特流烧录与四方版本一致 manifest/门禁）。周期性产出三张视图供评审：
- 覆盖视图：场景矩阵/软件用例的完成与缺口；
- 问题视图：原型发现的系统级 bug 清单、状态、在仿真/形式的关闭情况；
- 风险视图：哪些需求只有原型证据、哪些原型不覆盖（如模拟/时序，84 篇）需要别的手段兜底。
流片评审看的是这三张表，而不是"板卡跑了多少小时"。
七、RACI 与团队接口（简版）
| 活动 | RTL/设计 | 原型平台 | 验证 | 软件/固件 |
|---|---|---|---|---|
| 平台准备/替换库/harness | C | R/A | I | I |
| 原型用例计划 | C | C | R/A | C |
| 软件/OS 用例执行 | I | C（保平台） | A | R |
| 原型发现 bug 的仿真关闭 | R | I | A | C |
| 真实接口/soak/性能 | C | R（平台/子卡） | A | R（流量） |
| 流片证据汇总签核 | C | C | R/A | C |
（R 执行 / A 批准 / C 咨询 / I 知会，按项目实际调整。）
八、实例：PCIe 子系统的一行需求如何落到各引擎
把抽象矩阵走一遍具体的。需求："PCIe 控制器在 Gen4 x4 下完成链路训练、支持 4 KB/2 MB 混合 DMA、24 小时混合流量无数据错误、AER 错误可上报恢复"。分解后不是一个用例而是一组，各归其主：
| 子用例 | 主引擎 | 通过证据 | 不覆盖什么 |
|---|---|---|---|
| LTSSM 全状态/迁移 | 仿真+形式 | 功能覆盖 100%、断言无违例 | 真实信号眼图（33 PCIe/SerDes 上原型 硬核/降速子卡/LTSSM） |
| 枚举/配置空间 | Emulation→原型 | 真实主机 lspci 正常、BAR 分配正确 | — |
| 混合 DMA 数据正确性 | 仿真定向 + 原型 soak | 校验和比对、24h 零错 | 原型不签绝对带宽（42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除） |
| AER 错误上报恢复 | 仿真注入 + 原型真实触发 | 日志与恢复后继续收发 | 电气级误码机理不覆盖 |
| 长稳/热复位/flap | 原型 7×24 | 累计时长、故障次数、恢复率 | 不替代协议覆盖率 |
评审时这张表的价值在于：每一行都能回答"谁做的、证据是什么、没证明什么"，而不是笼统说"PCIe 测过了"。流片后若硅上出问题，也能立刻回到这张表查当初哪个引擎、哪类场景没有覆盖（与 05 原型到硅后衔接 pre/post-silicon 协同/errata对接）。
九、一周节奏：多引擎协作在日常是怎么运转的
矩阵和 RACI 在评审会上好看，真正决定成败的是每周的协作节奏。成熟团队的一个典型周循环：
- 周一 镜像日：发布与本周仿真基线一致的 RTL 冻结快照，原型平台产出新比特流并跑冒烟（点灯→启动到固定里程碑，03 原型平台 bring-up 多片点亮/trace）；冒烟不过，本周软件团队继续用上周镜像并立即回退，不让坏镜像占用板卡。
- 周二至周四 各引擎并行：仿真团队跑 UVM 回归和新启用例；原型上软件团队执行场景矩阵和驱动用例、平台团队保障板卡与 trace；疑难 bug 按证据包（第四节）回流，仿真复现定位。
- 每日 15 分钟跨团队站会：只对三件事——哪个 bug 需要换引擎复现、谁被坏镜像/板卡故障阻塞、今晚夜间回归跑什么（原型农场夜间跑长 soak，白天留给交互式调试，F2 主题）。
- 周五 证据合流：把本周各引擎新覆盖的点、发现/关闭的 bug、性能/活动数据更新进三张视图（覆盖/问题/风险）；新增原型结论按 43 原型结果可信度分级 可签核/可决策/仅参考与报告规范标 L1/L2/L3；任何"只有原型证据"的需求被显式标黄并指定兜底手段。
这个节奏里有两个反模式值得点名：一是镜像日不固定，软件团队拿到的比特流和仿真对不上，三引擎各说各话；二是周五不合流，问题散落在邮件和聊天记录里，流片评审时无法重建证据链。把"版本对齐"和"证据每周合流"变成纪律，多引擎的价值才兑现得了。
十、需求评审时如何给原型"要任务"
矩阵不是验证团队单方面的产出，需求评审阶段就应把原型任务要清楚，否则后期发现"这条需求只能在真实规模下暴露"时已经没有板位和排期。评审每条需求时多问四个问题：
- **这条需求的违约后果在小规模可见吗？**涉及全局资源（死锁、QoS 饿死、地址映射、缓存一致性、时钟域、复位释放顺序）的问题，模块仿真常常暴露不了，应在早期就排原型用例和对应触发条件（40 多板多 FPGA 全局触发与时间对齐 跨片 trace 同步）。
- **需要真实软件/真实对端才能触发吗？**依赖完整 OS 调度、真实驱动状态机、真实协议对端行为的需求，标原型 ICE 为主引擎，并把软件就绪时间写进依赖计划（29 固件 shift-left RTL 冻结前 bring-up/驱动开发）。
- **需要多长的时间尺度才有统计意义？**可靠性类需求（无泄漏、无死锁、长稳）必须带 soak 时长目标进计划（如累计 N 板·小时零故障），而不是"跑一下看看"；时长目标进一步决定 trace 深度和农场板位（45 Trace 带宽与深度工程 采样/缓冲/压缩/回传管线、F2 主题）。
- **原型不签的部分谁签？**凡是依赖模拟/PHY/绝对时序的需求，当场指定仿真分析、混合信号验证、STA 或硅后专项的负责人，矩阵里不允许出现"大家都以为有人测"的空格。
这四问的产出直接进入验证计划的可追溯表（第三节），让原型用例与需求同源产生，而不是验证后期临时补跑。经验上，项目中价值最高的原型用例往往不是计划里的正向功能，而是评审时被这四问逼出来的"系统级相互作用"场景。
十一、矩阵裁剪：小项目也别省的最小集合
这套矩阵看起来重，资源有限的小项目可以裁剪但不应取消。最小可用集合建议保留四样：一张哪怕只有二十行的需求—用例—引擎映射表（杜绝"没人测"的空格）；每个引擎各自的通过标准（仿真断言/覆盖率、原型场景通过与 soak 时长）；bug 跨引擎移交的最小证据包（版本、复现、日志/trace，缺一会多花数倍沟通时间）；一份明确写"原型不覆盖什么"的清单。即便只有一块板、两个人，这四样的成本以小时计，却能避免最致命的两类事故——把原型没跑到的功能当成验证过、以及流片后才发现某个系统级场景从来没有任何引擎覆盖。
十二、用例在引擎间迁移的工程成本
矩阵分工听起来顺，实践中迁移本身有成本，应在计划中显式排期而非默认"随便一挪"：一个用例从仿真迁到 Emulator/原型通常要替换 testbench 驱动器为 transactor（26 事务处理器 SCE-MI 三类通道/transactor 实现）、把文件激励改成主机侧 C/脚本驱动、补内存镜像加载和启动参数、适配真实接口的速率适配（31 速率适配器 Speed Adapter 弹性FIFO/两种范式）；反向迁移（回仿真定位）则要把长流量缩成最小确定性场景并补断言。正因如此，用例设计时就应分层写：与引擎无关的场景层一次写成，各引擎只补薄驱动层——迁移工作量从"重写用例"降到"接线"，这是多引擎矩阵真正跑得起来的工程前提。
十三、常见坑速查
- 把原型当更快仿真器要功能签核 → 错配，原型签的是真实规模下的系统级无错；
- 用"跑了一周没挂"顶替功能覆盖率 → 没跑到不等于没问题；
- 矩阵不写"×"，结论被过度采信 → 明确原型不验证模拟/真实时序（84 篇）；
- bug 移交只发现象 → 证据包四件套缺一不可；
- run 不可追溯 → 每 run 关联需求/版本/通过标准；
- 原型覆盖和仿真覆盖混成一笔账 → 并列、分算、互补。
与系列及现有篇目的链接
- 引擎决策与可信度：37 原型/Emulation/仿真选引擎 决策树/多引擎排班、43 原型结果可信度分级 可签核/可决策/仅参考与报告规范
- 性能/覆盖/功耗：42 降频原型架构性能评估 cycle 计数/A-B/伪延迟扣除、24 活动覆盖率与性能调试闭环 热点/瓶颈/回放、25 真实激励驱动 ASIC 签核 SAIF 反标/边界
- 机制与协作：06 原型验证系统全景与文档地图、03 原型平台 bring-up 多片点亮/trace、20 比特流烧录与四方版本一致 manifest/门禁、40 多板多 FPGA 全局触发与时间对齐 跨片 trace 同步
总结
一句话总结：原型在 SoC 验证矩阵里的定位不是"更快的仿真器"而是"仿真够不着的真实"——仿真和形式负责证明功能正确（随机约束、断言、功能覆盖率、有界死锁证明），Emulation 居中补规模大但仍要高可见性的全芯片早期联调，原型因为可见性受限、编译慢、模拟/PHY 被替换、时序是 FPGA 的而非 ASIC 的，所以不承担也无法承担功能完备性签核，它不可替代的职责是在接近真实速度下跑完整软件栈、真实接口流量和超长时长，暴露"模块都对、拼起来才错"的系统级问题（跨模块死锁竞态、软件对硬件的错误假设、真实协议互通、资源泄漏、长稳退化），这些在仿真里跑不到或要数年机时；落地要建一张需求—用例—主/辅引擎—通过标准—签核人的可追溯分配矩阵并配 RACI，明确主力归属（功能回归归仿真、软件兼容和真实接口 ICE 和 7×24 soak 和架构性能 A/B 归原型、启动链和早期活动 Emulation 先行、模拟与真实时序四引擎都不签靠专项），尤其要显式写出原型"不验证什么"以防结论被过度采信（详见 84 篇可信度分级）；原型不回收 UVM 功能覆盖率，它自己的覆盖是软件用例/驱动路径覆盖、外设×流量×电源×启动的场景矩阵、soak 时长与压力、热插拔掉电链路降级等边界异常四类，要和仿真功能覆盖率并列呈现、各自统计、互不替代，绝不能用"连续跑一周没挂"顶替缺失的功能覆盖（没挂可能只是没跑到）；跨引擎协作中，原型发现的 bug 移交仿真/形式定位必须带环境指纹（RTL commit、比特流 ID、软件镜像、TDM 时隙表版本）、最小复现步骤与复现概率、已对齐重组的 trace 和 bootlog、已排除假设与正常 run 差异，修复在仿真证明后回原型用同一用例相近版本关闭并登记追溯；最后每个原型 run 都要关联需求/版本/通过标准/存档，评审看的是覆盖视图、问题视图（系统级 bug 及关闭状态）、风险视图（只有原型证据的需求和原型不覆盖需别的手段兜底的项）三张表，而不是板卡跑了多少小时。