针对 AMD Versal™ 自适应 SoC 设计，采用渐进式方法加速系统级验证

AMD Versal™ 自适应 SoC 为开发者提供异构计算架构，将可编程逻辑 (PL)、AI 引擎与高性能处理系统集成到单个器件内。这些计算元件通过可编程片上网络 (NoC) 相互连接，并协同工作以实现复杂、高性能的系统。

虽然这种架构灵活性能够显著提升性能和效率，但也增加了验证复杂性。Versal 器件设计涵盖多个组件，包括 AI 引擎图、基于 HLS 或 RTL 的可编程逻辑设计，以及运行于处理系统上的软件。每个组件都采用不同的工具和抽象方法进行开发，而且通常由不同的团队负责。

验证这些组件能否作为一个集成系统正常运行，是 Versal 器件开发中最具挑战性的一个环节。系统级验证必须确保算法正确无误、子系统之间可正常集成，以及部署到硬件后可正常运行。过去，系统级验证一直依赖于硬件仿真，

这种做法虽能确保结果准确无误，但由于流程复杂和性能限制而难以在设计周期早期充分发挥实用价值。

AMD Vitis™ 统一软件平台推出一套全新仿真流程，可克服这些局限性。功能仿真、基于 XSIM 的子系统仿真以及硬件在环验证，这三项流程构成一种渐进式验证方法，支持提前开展验证、提升执行速度，并能降低项目整体风险。这三项流程相辅相成，可有效应用于 Versal 自适应 SoC 系统开发。

硬件仿真作为传统基准

在更先进的系统仿真流程问世之前，针对 Versal 器件设计的主流验证方式是在 Vitis 软件中进行硬件仿真。此流程需要同时使用多个独立的仿真器，对 Versal 器件的主要子系统进行建模。

在典型的硬件仿真验证流程中，处理系统采用 QEMU 进行仿真，PL 则使用 XSIM 配合 HDL 测试激励文件进行仿真，而 AI 引擎阵列则借助基于 System-C 的 AI 引擎 (AIE) 仿真器进行仿真。这些仿真器共同作用，可确保全系统范围内的功能准确性，并支持运行与 PL 和 AI 引擎交互的软件应用。

这种方法虽然能产生可靠实用的结果，但却非常复杂。每个仿真器的运行速度都远低于真实芯片运行速度，而且定时器精度往往不统一。因此，需要投入大量精力来配置并维持仿真器之间的同步。

为保持系统正常运行，必须在 QEMU、XSIM 和 AIE 仿真器之间持续协调

时钟、事件、内存事务和中断。这种跨仿真器同步会产生大量通信开销和频繁的上下文切换，从而显著降低整体仿真吞吐量。此外，调试可见性和事务级建模等其他因素也会进一步导致执行速度变慢。

随着 Versal 自适应 SoC 设计复杂度不断提升，包括更深层的流水线、更宽的数据路径以及更复杂的互连结构，硬件仿真所存在的局限性也日益凸显。尽管硬件仿真对于某些应用场景仍具有重要价值，但它不太适合快速迭代场景或早期阶段的系统验证场景。

渐进式系统仿真策略

Versal 器件开发无需完全依赖硬件仿真，而是可以采用一种渐进式系统仿真策略，在设计流程的不同阶段采用不同的验证技术。

这一策略涵盖三大互补流程：

1. 功能仿真：侧重于验证高层级的算法正确性
2. 基于 XSIM 的子系统仿真：验证 AI 引擎与 PL 之间的集成
3. 硬件在环验证：在软件控制下，在实际的 Versal 器件上执行设计

每个流程对应于特定的验证目标，可避免在非必要的情况下进行完整硬件仿真，从而节省开销。这三项流程共同作用，提供了一条以算法为起点的结构化验证路径。

流程 1：Versal 自适应 SoC 系统功能仿真

功能仿真侧重于验证设计的功能，而非其在时钟周期级别的行为。对于 Versal 器件，这通常涉及在将 AI 引擎图和 HLS 生成的内核集成到更大系统之前对它们进行验证。

Vitis 功能仿真支持开发者使用 Python、MATLAB 或 C++（抢先体验版）对 AI 引擎和 HLS 设计进行仿真。这使得能够在常用于算法开发的环境中进行验证，从而减少软件建模与硬件实现之间的阻碍。

功能仿真的抽象层级更高，因此仿真性能远优于硬件仿真。这意味着，可在设计流程的早期阶段处理大型数据集、探索架构参数以及评估性能数值指标。

为在软件框架与 Versal 器件设计之间实现无缝交互，功能仿真采用一种统一的数组类型，支持 AI 引擎和 HLS 内核常用的定点和浮点数据格式。这使得能够在无需手动转换或损失保真度的情况下进行数据交换。

功能仿真尤其适用于早期验证，在这一阶段，快速迭代和算法分析比周期精度更为重要。

从算法过渡到子系统

在功能正确性得到验证后，下一个挑战便是确认 AI 引擎设计能否成功与 PL 及系统级基础设施集成。在此阶段，仅靠功能仿真无法再满足要求，因为它无法捕捉数据传输、接口行为或子系统间的交互。

这一过渡标志着子系统级仿真变得至关重要。

流程 2：基于 XSIM 的子系统仿真

基于 XSIM 的仿真支持直接在 AMD Vivado™ Design Suite 环境中对 Vitis 子系统进行仿真。在此流程中，包含 AI 引擎、HLS 和 PL 内核组合的 Vitis 设计被封装为一个 Vitis 子系统，

并被导入到 Vivado Design Suite 项目中，与周围的 PL 集成。

然后，通过使用 AI 引擎测试激励文件来替代处理系统，对 Vitis 子系统进行验证。在这种情况下，测试激励文件应采用 SystemVerilog，因此无需使用 QEMU。与硬件仿真相比，这显著降低了仿真开销。采用这种方法，PL 设计人员不仅能够验证 AI 引擎功能，还能验证数据传输、接口正确性以及与自定义 RTL 模型的集成行为，同时保持对 RTL 和 AI 引擎活动的全面可见性。

此流程避免了完整处理器仿真及其相关开销，因此执行速度明显快于硬件仿真，同时仍能提供有意义的系统上下文。它是功能仿真与硬件执行之间的一个重要中间步骤。至关重要的是，基于 XSIM 的验证具有时钟周期精确性（而 AI 引擎仿真为时钟周期近似），使开发者不仅能够验证性能和接口，还能验证吞吐量和延迟。

借助 Vitis 工具开展分析并获得洞察

在基于 XSIM 的仿真流程中，可使用 Vitis 分析器分析 AI 引擎的执行情况。这能够直观展示图谱结构、阵列资源利用率与执行行为，与 Vivado 工具提供的 RTL 级可见性形成互补。

通过将 XSIM 中观察到的子系统行为与 AI 引擎执行数据关联起来，开发者可以在进入硬件实施之前识别性能瓶颈和集成问题。

在此阶段，各团队可以确信算法是正确的，并且 AI 引擎与 PL 子系统能够按预期协同工作。

流程 3：硬件在环验证

硬件在环验证是渐进式仿真策略的最后阶段。在此流程中，设计被部署到实际的 Versal 器件上，但仍由基于主机的软件环境进行控制。

利用 Vitis 硬件在环功能，将一个 Vitis 子系统与一个轻量级服务器打包，该服务器在目标 Versal 器件上运行。主机系统通过以太网与该服务器通信，发送测试向量并接收结果以供分析。来自主机的数据可使用 MATLAB 或 Python 进行传递，这两种语言都常用于算法开发。

不同于硬件仿真，计算会在真实芯片上进行。这意味着，无需进行跨仿真器同步，并可准确测量性能、时序和数值表现。与此同时，此流程软件驱动的特性确保了可重复性和可观测性。

硬件在环测试使开发者能够在将设计集成到完整系统之前验证子系统的行为和性能，从而在开发的关键阶段降低风险。

通过渐进式验证降低风险

通过以功能仿真、基于 XSIM 的子系统仿真以及硬件在环验证为核心构建验证流程，Versal 器件开发者可避免在非必要情况下进行硬件仿真，从而节省成本并降低复杂性。

每个阶段都针对一类特定风险，并逐步增强设计可靠性。功能仿真侧重于验证算法，子系统仿真负责验证集成情况，而硬件在环验证实际执行情况。

这种渐进式方法能够实现更快的迭代、更早的洞察，以及更可预测的系统级成果。

总结

随着 Versal 自适应 SoC 设计的复杂性不断攀升，验证策略必须摆脱单纯依赖硬件仿真的模式。硬件仿真虽然仍具有重要价值，但由于流程复杂和性能局限，它不太适合早期阶段验证和迭代验证。

Vitis 统一软件平台提供了一套互补的仿真与验证流程，以解决硬件仿真存在的局限性。功能仿真、基于 XSIM 的子系统仿真以及硬件在环验证，共同构成了一种可扩展且高效的 Versal 设计系统级验证策略。

通过逐步应用这三项流程，可有效降低风险、增强设计可靠性，并加速从算法开发到硬件部署的进程。

资源

如需详细了解本文中提及的各项技术，请参考以下资源。

• UG1701 VFS 文档
• Vitis-Tutorials VFS 示例
• Vitis 功能仿真抢先体验专区（针对全新 C++ 流程；AMD 计划在 2026.1 版本中正式发布）
• 硬件在环验证抢先体验专区