作者：Michael Yang
过去几年，AMD 一直在推动Versal™ 自适应 SoC 进入更复杂的计算场景。从 AI推理、机器视觉，到无线通信、边缘计算，Versal 已经不再只是传统意义上的 FPGA。它更像一个把 AI Engine、可编程逻辑、处理器系统和片上网络深度融合后的异构计算平台。
图源：ChatGPT AI生图
但行业真正开始大规模落地后，一个问题也越来越突出：系统越来越强，验证越来越难。很多团队发现，项目后期最大的时间黑洞，已经不是写 RTL，也不是调算法，而是系统验证。尤其当 AI Engine、PL 和软件系统开始同时协同工作后，传统 FPGA 那套验证方式，开始明显跟不上了。
过去的验证逻辑，正在被异构SoC改写
传统 FPGA 开发有一个典型特点：模块边界相对清晰。RTL 做完，接口对齐，时序收敛，项目基本就进入尾声。
但 Versal 的复杂度完全不同，一个完整系统里，往往同时存在：
AI Engine Graph
HLS Kernel
RTL 模块
Linux 软件
NoC 数据流
DMA 调度
高速接口
而这些部分，通常来自不同团队，算法团队跑 Python 和MATLAB；PL 团队做RTL；软件团队维护 Linux 和驱动；系统团队负责整体集成。
问题恰恰出在这里，因为很多错误，并不会出现在单个模块内部，而是出现在系统协同这一层。比如AI Engine 吞吐跟不上 PL 数据节奏；DMA 调度导致 Graph 阻塞；NoC带宽分配不合理；软件中断与硬件事件不同步；HLS Kernel 与 RTL 接口行为不一致。这些问题，传统模块级验证很难覆盖，于是行业开始越来越依赖系统级验证。
但新的问题又随之而来。
为什么越来越多团队开始“害怕”硬件仿真？
过去，Versal 项目做系统验证，最常见的方法是 Hardware Emulation。理论上，它能模拟整个系统。QEMU 模拟处理器；XSIM 负责 RTL；AI Engine Simulator 模拟 AIE 阵列，整个系统几乎都能被虚拟跑起来。但问题在于它太重了，尤其是设计规模上来之后，很多工程师对 Hardware Emulation 的感受都很一致：不是不能跑，而是跑一次太久。
原因并不复杂，因为这实际上是三个大型仿真环境同时运行：
软件系统在跑
RTL 在跑
AI Engine 也在跑
更麻烦的是，它们之间还必须持续同步，时钟、事件、中断、数据流、存储事务，都需要不断协调。系统越复杂，同步负担越重。很多时候，真正拖慢速度的，并不是设计本身，而是：仿真器之间的协同成本。尤其到了 AI Engine + 软件 + PL 深度耦合阶段后，验证开始成为整个开发流程里最慢的一环。行业也逐渐意识到继续堆更大的硬件仿真系统，并不能真正解决问题。验证方法本身，需要变化。
AMD 开始重新拆解“系统验证”
AMD 现在给出的思路，其实非常明确：不要一开始就进入最重的全系统仿真。而是把验证过程拆成不同层级，不同阶段，解决不同问题。于是，Vitis Unified Software Platform 开始引入一种新的渐进式验证路径。整个流程可以概括成三步：
先验证算法；再验证子系统协同；最后才进入真实硬件。
看起来只是流程调整，但背后其实是系统验证逻辑的变化。
过去行业总希望一次验证整个系统，现在 AMD 更强调不同问题，在不同抽象层解决。这也是整篇方法论里最核心的变化。
第一步：先把算法验证提前
AMD 现在首先强调的，是Functional Simulation。本质上，它是在把很多原本放到硬件仿真里的工作，提前到算法阶段完成。
开发者可以直接使用：
Python
MATLAB
C++
去验证 AI Engine 与 HLS Kernel。
这件事的重要性，其实被很多人低估了，因为过去 FPGA 开发里，一个典型问题是：
算法团队和硬件团队之间长期割裂。
算法先做模型；
硬件后面再“翻译”成 RTL。
中间经常出现：
数据格式变化
定点精度误差
Graph 调度问题
Kernel 参数偏差
最后只能等到系统联调阶段才暴露，而现在，AMD 的思路是把验证尽量前移，在高抽象层，就先验证算法行为。由于 Functional Simulation 不需要完整系统同步，其运行速度远高于传统硬件仿真。
开发者可以更早：
跑大规模数据
调算法参数
分析数值精度
验证 AI Engine Graph 行为
整个验证节奏会明显提前。
第二步：开始验证 AI Engine 与 PL 的协同
但算法正确，并不意味着系统正确。真正复杂的问题，往往发生在 AI Engine 与 PL 开始协同之后。
这也是 AMD 推出第二层验证的原因：基于 XSIM 的子系统验证。这里最关键的变化是：它不再模拟完整处理器系统，而是直接让 AI Engine Testbench 驱动子系统。换句话说：QEMU 被拿掉了，整个仿真负担一下轻了很多，但与此同时开发者依旧可以看到：
RTL 行为
AI Engine 活动
数据流路径
接口时序
吞吐与延迟
这一步其实非常关键。
因为它等于在系统完整性和仿真效率之间，找到了一个新的平衡点，相比完整硬件仿真，它执行速度更快；相比纯算法仿真，它又保留了真实系统上下文。这也是为什么越来越多 Versal 团队，开始把子系统验证当作主力验证阶段。
第三步：真正上板，但保留软件化验证体验
到了最后阶段，AMD 才引入Hardware-in-the-loop（HIL）。也就是真正把设计部署到 Versal 硅片上。但 AMD 并没有回到传统 FPGA 那种“纯硬件调试”模式。相反，它依旧保留了软件驱动特征。
主机通过 Ethernet 与目标板通信：
发送测试向量
获取结果
分析系统行为
MATLAB 与 Python 依然可以继续参与。这意味着：开发者第一次能够在真实硬件阶段，依旧维持算法开发时期的工作流。而这背后，其实反映的是一个更大的趋势：Versal 时代，FPGA 开发正在越来越“软件化”。
AMD 真正想解决的，其实不是仿真速度
表面上看，AMD 这套渐进式验证路径是在解决：硬件仿真太慢。但本质上，它真正想解决的是：异构计算时代的系统协同问题。因为今天的 Versal 项目，难点已经不只是 RTL，真正困难的是：
AI Engine 与PL 的协同
软件与硬件的同步
数据流调度
系统吞吐
NoC 资源分配
子系统延迟控制
换句话说：FPGA 行业正在从“逻辑设计时代”，逐渐进入“系统验证时代”。未来真正决定开发效率的，也不再只是综合速度或者 P&R 时间，而是整个系统，能否被快速验证。AMD 现在做的，其实是在提前重构这套方法论。
长按下方二维码关注我们，
获取更多有趣demo及最新资讯。
瑞苏盈科官方微信公众号
来源：Enclustra