什么是 FPGA Prototyping？

从芯片验证到系统 Bring-up 的桥梁

在 SoC 和 AI 芯片项目中，很多问题并不会在单个 IP 仿真阶段暴露出来。CPU 可以正常取指，DMA 可以通过单元测试，DDR Controller 也通过了基础用例，但当 Bootloader、Linux Kernel、Device Driver、AI Runtime、PCIe、DDR 和外设一起工作时，系统仍然可能卡在启动流程、数据搬运、中断响应或长时间稳定性上。

这类问题的共同特点是：它们不是某一个模块孤立的问题，而是软硬件协同、接口时序、系统负载和真实数据流叠加之后才出现的问题。

FPGA Prototyping 的价值，正是在芯片真正 Tapeout 或 First Silicon 回来之前，让一个尚未流片的设计尽可能早地在硬件环境中跑起来。它不是为了取代 RTL simulation，也不是简单追求“跑得更快”，而是为系统级验证、软件提前开发和 Bring-up 演练提供一个可运行的平台。

FPGA Prototyping 是什么？

FPGA Prototyping 通常指把 ASIC 或 SoC 的 RTL 设计映射到 FPGA 或 FPGA Prototype Platform 上运行，使芯片设计在流片之前就能以硬件形式执行。

简单理解，它做的是一件事：把“还没有做成硅片的芯片”先放到 FPGA 上跑起来。

这里的“跑起来”并不只是让某个模块通过测试，而是让系统具备更接近真实硬件的运行条件。例如，处理器可以启动 Bootloader，操作系统可以加载驱动，软件可以访问寄存器，DMA 可以搬运数据，PCIe 或 Ethernet 可以连接外部设备，AI inference workload 可以在接近真实数据流的环境下执行。

因此，FPGA Prototyping 更像是一个 pre-silicon system platform。它关注的问题通常不是“某个 RTL 信号在某一拍是否正确”，而是“这个系统能不能在更接近真实应用的条件下持续工作”。

它主要解决哪些问题？

传统 RTL simulation 非常重要，但它的运行速度通常很慢。对于单个 IP、协议边界、状态机和局部功能验证来说，仿真是不可替代的；但如果要启动完整 Linux、跑复杂 driver、验证长时间数据流或执行真实 AI workload，纯 RTL 仿真的效率往往不够。

FPGA Prototyping 主要帮助团队解决以下几类问题。

第一，软件团队不必等到芯片回来之后才开始深入开发。Bootloader、Kernel、Device Driver、Runtime、SDK 和应用层程序，都可以在 FPGA Prototype 上提前运行和调试。

第二，系统集成问题可以更早暴露。很多问题只有在 CPU、NoC、DDR、DMA、interrupt controller、外设接口和软件栈同时工作时才会出现。原型平台可以把这些路径连接起来，让系统问题提前浮出水面。

第三，真实 IO 和外部设备可以参与验证。PCIe、DDR、Ethernet、SerDes、camera、display 等接口，很难完全依赖抽象模型覆盖所有系统行为。FPGA Prototyping 能把设计接入更真实的板级和外设环境。

第四，Bring-up 风险可以被前移。First Silicon 回来之后，团队最怕的是启动流程、寄存器配置、驱动加载、内存访问和外设初始化同时出问题。通过 FPGA Prototype，团队可以提前演练启动流程、日志采集、异常定位和软件修复路径。

典型应用场景

FPGA Prototyping 在不同项目中的使用方式不完全相同，但常见场景有几类。

在 SoC 原型验证中，团队会把处理器子系统、片上总线、DDR 访问、外设控制器和关键加速模块放到 FPGA 平台上运行，用来验证系统启动、寄存器访问、中断、DMA 和内存一致性等关键路径。

在 AI SoC 或 AI accelerator 项目中，原型平台可以帮助软件团队提前适配 AI Runtime、compiler backend、driver、SDK 和推理框架。对于 Edge AI 系统来说，真实数据流很重要，例如 camera input、图像预处理、NPU inference、DDR 数据搬运和 display output，这些链路很适合在 FPGA Prototype 上做端到端验证。

在 Embedded Linux 或 RTOS Bring-up 场景中，FPGA Prototyping 可以用于验证 BootROM 替代流程、Bootloader、Kernel 启动、设备树、驱动 probe、中断处理和文件系统挂载等过程。相比只在仿真中观察局部行为，原型平台更容易暴露软件栈和硬件接口之间的配合问题。

在高速接口验证中，PCIe、DDR、Ethernet、SerDes 等接口往往涉及真实板级连接、外部设备行为和较长时间压力测试。FPGA Prototyping 可以帮助团队更早观察吞吐、链路稳定性、错误恢复和系统资源竞争。

FPGA Prototyping、Simulation 和 Emulation 的区别

FPGA Prototyping 经常和 Simulation、Emulation 放在一起讨论。它们都属于 pre-silicon 阶段的重要手段，但定位不同。

可以粗略理解为：Simulation 更适合“看清每一个细节”，Emulation 更适合“在较大规模上看清系统问题”，FPGA Prototyping 更适合“让系统尽早在接近真实硬件的环境中跑起来”。

这三者不是替代关系。成熟项目通常会组合使用它们：仿真负责精确性和局部覆盖，Emulation 负责大规模可观测 debug，FPGA Prototyping 负责高速运行、真实 IO 和软件栈前移。

一个典型 FPGA Prototyping 流程

FPGA Prototyping 并不是简单把 RTL 丢进 FPGA 工具就结束。真正可用的原型平台通常需要经历一系列工程适配。

第一步是 RTL 准备。团队需要确认哪些模块适合进入原型平台，哪些验证辅助逻辑、断言、不可综合代码或仿真专用模型需要移除或替换。对于还不稳定的模块，有时也会使用简化模型或 FPGA-friendly IP 进行替代。

第二步是接口适配。ASIC 中的 SRAM、PLL、clock gating、power management、DFT 逻辑或专用硬核，在 FPGA 上不一定能原样实现。工程上通常需要用 FPGA block RAM、MMCM/PLL、约束逻辑或平台桥接逻辑进行替换。

第三步是 partition。如果设计规模超过单颗 FPGA 容量，就需要拆分到多颗 FPGA。这个过程不仅要考虑逻辑容量，还要考虑跨 FPGA 信号数量、时钟域、延迟、互连带宽和调试便利性。

第四步是综合、布局布线和时序收敛。FPGA Prototype 通常不会达到最终 ASIC 的目标频率，但仍然需要满足平台自身的时序要求。为了让系统稳定运行，团队可能需要降低时钟频率、增加 pipeline、调整跨 FPGA 通信方式或优化约束。

第五步是下载运行和调试。平台跑起来之后，软件团队会开始启动 Bootloader、加载 Kernel、访问寄存器、跑 driver 和应用。硬件团队则需要通过 ILA、trace buffer、UART log、JTAG、软件日志等方式观察问题。

最后是持续迭代。FPGA Prototype 一旦稳定下来，往往会成为多个团队共享的实验平台，用于软件开发、系统验证、性能观察、长时间压力测试和 Bring-up 演练。

工程实践中的挑战

FPGA Prototyping 很有价值，但它并不轻松。

首先是容量问题。现代 SoC 设计可能远远超过单颗 FPGA 的容量，尤其是包含多核处理器、大规模 NoC、AI accelerator、视频处理模块和复杂外设时。多 FPGA partition 会带来额外互连延迟和实现复杂度。

其次是时序收敛。ASIC RTL 的写法、时钟结构和时序假设不一定适合 FPGA。某些在 ASIC 中合理的路径，映射到 FPGA 后可能难以收敛。为了让平台可运行，团队需要接受原型平台频率低于最终芯片频率这一现实。

第三是调试可观测性不足。FPGA Prototype 通常运行速度高于仿真，但内部信号观察能力有限。想观察更多信号，就需要插入 ILA 或 trace 逻辑；但插桩过多又会占用资源、影响时序，甚至改变问题表现。

第四是原型平台和真实芯片存在差异。FPGA 上的 SRAM、时钟、复位、IO、互连延迟和部分 IP 行为，可能与 ASIC 最终实现不同。因此，FPGA Prototyping 发现的问题要认真分析，没发现的问题也不能直接代表硅片一定没有风险。

第五是团队协作成本。原型平台横跨 RTL、验证、FPGA 实现、板级调试、嵌入式软件和应用软件。没有清晰的版本管理、构建流程、日志规范和问题追踪机制，平台很容易变成“能跑但不好用”的临时环境。

什么项目适合做 FPGA Prototyping？

并不是所有项目都必须上 FPGA Prototyping。判断是否需要，可以从几个问题入手。

如果软件栈很复杂，例如需要运行 Linux、RTOS、driver、AI Runtime、SDK 或完整应用，那么 FPGA Prototyping 的价值通常比较明显。软件越早接触接近真实的硬件平台，First Silicon 阶段的不确定性就越少。

如果系统依赖真实外设或高速接口，例如 PCIe、DDR、Ethernet、SerDes、camera、display、sensor input，那么原型平台可以帮助团队提前验证数据链路和外部设备交互。

如果项目的系统集成风险较高，例如 CPU、DMA、NoC、accelerator、memory subsystem 和 interrupt controller 之间有复杂协同关系，那么仅靠局部仿真往往不足以覆盖真实问题。

如果项目周期对 Bring-up 时间非常敏感，希望硅片回来后尽快完成启动、驱动和基础软件验证，那么 FPGA Prototype 可以作为提前演练的平台。

反过来，如果设计规模较小、软件很简单、外设接口少、系统集成风险低，或者当前 RTL 仍在频繁变化且主要问题是内部 debug，那么 Simulation 和 Emulation 可能更适合作为当前阶段的重点。

一个实用理解

可以把 FPGA Prototyping 看成芯片项目中的一座桥。

桥的一端是 RTL、仿真、验证计划和设计规格；另一端是软件、外设、系统场景和最终 Bring-up。它的意义不是把所有验证工作都搬到 FPGA 上，而是在合适的阶段让系统从“纸面和波形中的设计”变成“可以被软件访问、可以连接外设、可以长时间运行的硬件平台”。

对于高校实验室，它可以支撑 SoC 原型验证、异构计算实验、嵌入式 AI 系统研究和学生工程训练。对于芯片和嵌入式团队，它可以帮助软件开发、接口验证和系统问题更早发生、更早定位。

总结

FPGA Prototyping 是一种把 pre-silicon RTL 设计映射到 FPGA 平台上运行的方法。它的核心价值不是替代仿真，也不是单纯追求速度，而是让复杂系统尽早具备可运行、可连接、可调试的软件和硬件环境。

在 SoC、AI SoC、Edge AI 和嵌入式系统项目中，它常用于系统级验证、软件提前开发、真实 IO 验证、长时间 workload 测试和 First Silicon Bring-up 演练。

真正需要关注的问题不是“是否一定要做 FPGA Prototyping”，而是当前项目是否已经进入一个阶段：仅靠局部仿真已经不足以回答系统能否稳定运行，软件团队又需要一个更接近真实硬件的平台来推进开发和验证。

如果答案是肯定的，FPGA Prototyping 就不只是一个验证工具，而是一个连接设计、软件和系统场景的工程平台。