AMD Versal 自适应 SoC 为开发者提供了一种异构计算架构，将可编程逻辑（ PL ）、AI 引擎以及高性能处理系统集成于单一器件之中。这些计算单元通过可编程片上网络（ NoC ）互联，并协同用于实现复杂、高性能的系统。
这种架构的灵活性带来了显著的性能和效率提升，但也增加了验证的复杂性。Versal 器件的设计跨越多个领域，包括 AI 引擎图、基于 HLS 或 RTL 的可编程逻辑设计，以及运行在处理系统上的软件。每个领域都使用不同的工具和抽象层，通常由不同团队开发。
验证这些组件作为一个集成系统能否正确运行，是 Versal 器件开发中最具挑战性的环节之一。系统级验证必须确保算法正确、子系统间集成无误，并且部署到硬件后行为正确。传统上，这一层级的验证依赖于硬件仿真，尽管硬件仿真很准确，但其带来了复杂性和性能限制，限制了其在设计早期阶段的实用性。
AMD Vitis 统一软件平台引入了一系列替代仿真流程，克服了这些限制。功能仿真、基于 XSIM 的子系统仿真以及硬件在环验证实现了一种渐进式的验证方法，可以更早启动、执行更快，并降低整体项目风险。这些流程相互补充，可有效应用于 Versal 自适应 SoC 系统开发。
传统基线：硬件仿真
在新系统仿真流程出现之前，Versal 器件设计的主要验证方式是在 Vitis 软件中进行硬件仿真。这一流程结合了多个独立仿真器来模拟 Versal 器件的主要子系统。
在典型的硬件仿真验证中，处理系统使用 QEMU 进行仿真，可编程逻辑使用带有 HDL 测试平台的 XSIM 进行仿真，AI 引擎阵列使用基于 System-C 的 AI 引擎（ AIE ）仿真器进行仿真。这些仿真器协同提供全系统的功能准确性，并支持与可编程逻辑和 AI 引擎交互的软件应用的执行。
尽管这种方法能产生有效且信息丰富的结果，但它较为复杂性。每个仿真器的运行速度远低于实际硅片，而且时间分辨率通常也各不相同。因此，需要投入大量努力来配置和维护仿真器间的同步。
为了保证系统行为的正确性，QEMU、XSIM 和 AIE 仿真器之间的时钟、事件、内存事务和中断必须持续协调。这种跨仿真器同步会带来通信开销和频繁的上下文切换，进而显著降低整体仿真吞吐量。诸如调试可见性和事务级建模等额外因素则会进一步导致执行缓慢。
随着 Versal 自适应 SoC 设计复杂度的提升，流水线更深、数据通路更宽、互连更复杂，硬件仿真的局限性愈发明显。虽然硬件仿真在某些应用场景下仍然很有价值，但其并不总是适用于快速迭代或早期系统验证。
渐进式系统仿真策略
Versal 器件开发并非完全依赖硬件仿真，而是受益于渐进式系统仿真策略，在设计流程的不同阶段应用不同的验证技术。
该策略包含三种互补流程：
1. 功能仿真聚焦高层次算法正确性
2. 基于 XSIM 的子系统仿真可验证 AI 引擎与可编程逻辑间的集成
3. 硬件在环验证是在软件控制下，在真实 Versal 器件上执行设计
每个流程都针对特定的验证目标，避免了在不需要时进行全硬件仿真的开销。这些共同提供了一条从算法到硬件的结构化路径。
流程 1：Versal 自适应 SoC 系统的功能仿真
功能仿真侧重于验证设计“做什么”，而非其在周期层面的行为。对于 Versal 器件而言，这通常涉及在将 AI 引擎图和 HLS 生成的内核集成到更大的系统之前对其进行验证。
Vitis 功能仿真（ Vitis Functional Simulation ）使开发人员能够使用 Python、MATLAB 或 C++（早期访问）对 AI 引擎和 HLS 设计进行仿真。这使得验证可以在与算法开发相同的环境中进行，从而减少了软件建模与硬件实现之间的摩擦。
由于功能仿真运行于更高的抽象层，其仿真性能远高于硬件仿真。这使得在设计流程早期处理大规模数据集、探索架构参数、评估数值性能指标变得切实可行。
为了实现软件框架与 Versal 器件设计之间的无缝交互，功能仿真采用统一数组类型，支持 AI 引擎和 HLS 内核常用的定点和浮点数据格式。这就使得数据交换无需手动转换，也不会面临精度损失。
功能仿真对于早期验证尤其有效，因为在早期验证中，快速迭代和算法洞察比周期准确性更重要。
从算法到子系统的过渡
一旦功能正确性得到验证，下一步挑战就是确保 AI 引擎设计能够与可编程逻辑和系统级基础设施正确集成。在这一阶段，仅靠功能仿真已不够，因为它无法捕捉数据流动、接口行为或子系统交互。
这一转变标志着子系统级仿真变得至关重要。
流程 2：基于 XSIM 的子系统仿真
基于 XSIM 的仿真使 Vitis 子系统可以直接在 AMD Vivado 设计套件环境中进行仿真。在此流程中，在 Vitis 中定义的设计（包含 AI 引擎、HLS 和 PL 内核）被打包为一个 Vitis 子系统，并导入到 Vivado 设计套件项目中，与周围的可编程逻辑进行集成。
Vitis 子系统利用 AI 引擎测试平台进行测试，取代了处理系统。在此情况下，测试平台应采用 System Verilog 编写，从而无需再使用 QEMU。与硬件仿真相比，这能显著降低仿真开销。该方法让可编程逻辑设计师不仅能验证 AI 引擎功能，还能检查数据传输、接口正确性、与自定义 RTL 模型的集成行为，同时保持对 RTL 和 AI 引擎活动的可见性。
由于该流程避免了完整的处理器仿真及相关开销，因此其执行速度远超硬件仿真，同时仍能提供有意义的系统上下文信息。它是功能仿真与硬件执行之间的重要中间步骤。至关重要的是，基于 XSIM 的验证是周期准确的（ AI 引擎仿真为周期近似），这使得开发人员可以验证性能和接口，还可以验证吞吐量和时延。
借助 Vitis 工具实现分析和可见性
在基于 XSIM 的仿真过程中，可以利用 Vitis Analyzer 对 AI 引擎的执行情况进行分析。这样能够深入了解图结构、tile 利用率和执行行为，进而补充 Vivado 工具所提供的 RTL 级可见性。
通过将 XSIM 中观察到的子系统行为与 AI 引擎执行数据进行关联，开发人员可以在进行硬件实现前发现性能瓶颈和集成问题。
在此阶段，团队可以确信算法是正确的，并且 AI 引擎与可编程逻辑子系统能够按预期协同工作。
流程 3：硬件在环验证
硬件在环验证是渐进式仿真策略的最后阶段。在此流程中，设计部署到真实 Versal 器件上，但仍由基于主机的软件环境控制。
借助 Vitis 硬件在环功能，Vitis 子系统与运行在目标 Versal 器件上的轻量级服务器集成在一起。主机系统通过以太网与该服务器通信，发送测试向量并接收结果进行分析。来自主机的数据可通过 MATLAB 或 Python 传递，两种语言均为算法开发的常用编程语言。
与硬件仿真不同，计算在真实硅片上完成。这便消除了跨仿真器同步的需求，并允许精准测量性能、时序和数值行为。同时，该流程的软件驱动特性保证了可重复性和可观测性。
硬件在环测试使开发人员能够在将设计集成到完整系统前验证子系统的行为和性能，从而在开发的关键阶段降低风险。
通过渐进式验证降低风险
通过围绕功能仿真、基于 XSIM 的子系统仿真和硬件在环执行构建验证流程，Versal 器件开发人员可以在不需要硬件仿真时，避免硬件仿真带来的成本和复杂性。
每个阶段都针对特定的风险类别，并逐步增强验证信心。功能仿真可以验证算法，子系统仿真可以验证集成，硬件在环可以验证实际执行情况。
这种方法能够实现更快迭代、更早洞察、更可预测的系统级结果。
总结
随着 Versal 自适应 SoC 设计复杂性的不断提升，验证策略必须超越单纯依赖硬件仿真。尽管硬件仿真仍然具有价值，但其复杂性和性能限制使其不尽然适合早期和迭代验证。
Vitis 统一软件平台提供了一套互补的仿真与验证流程，解决了这些挑战。功能仿真、基于 XSIM 的子系统仿真以及硬件在环验证，共同构成了一种适用于 Versal 设计的可扩展且高效的系统级验证策略。
通过逐步应用这些流程，您可降低风险、提升信心，并加快从算法开发到硬件部署的进程。
资源 如果您希望了解本文中提及技术的更多信息，以下资源将对您有所帮助：
文章来源：Xilinx 赛灵思官微