AIE Feature Tutorials: Runtime and Platform 深度解析

一句话概括

本模块是 AMD Versal AI Engine 的系统级操作手册——它不仅教你如何编写 AIE 内核，更重要的是教会你如何将这些内核与可编程逻辑 (PL)、外部存储器以及主机软件整合成一个可运行、可调试、可量产的完整系统。如果说 AIE 设计图是建筑的蓝图，那么本模块就是教你在工地上如何浇筑混凝土、铺设管道并进行竣工验收。

为什么需要这个模块？——问题空间的本质

在 Versal 架构上进行异构计算开发时，开发者面临的不是单一编程模型，而是三层异构的复杂性爆炸：

1. AIE 层：基于数据流的矢量处理器阵列，使用专门的 AIE API 和图 (graph) 语义，有自己的运行时 (LibAIEGraph)。

2. PL (Programmable Logic) 层：传统的 FPGA 逻辑，使用 HLS (Vitis HLS) 或 RTL 开发，负责数据搬移 (DMA)、预处理/后处理以及与外部接口 (DDR、Ethernet 等) 对接。

3. Host 层：运行在 ARM A72 或 x86 上的软件，使用 XRT (Xilinx Runtime) 对 AI Engine 进行图配置、运行时参数 (RTP) 更新以及 PL 内核控制。

没有系统级知识的三重困境：

• AIE 开发者写出了完美的矢量代码，但不知道如何将数据从 DDR 灌入 AIE 阵列，性能卡在存储墙。
• PL 开发者写好了 DMA 搬移核，但 AIE 图编译报错连接不匹配，因为不知道 PLIO 的宽度与 AIE 端口的契约。
• 系统集成者面对硬件仿真 (HW Emulation) 挂死，无从下手，因为不理解 AIE 仿真器的时钟域与 PL 的协同机制。

本模块的解决思路：提供渐进式、可运行的示例，从最简单的 AIE+PL 数据搬移 (Versal Integration) 开始，逐步加入运行时参数重配置 (RTP Reconfiguration)、数据包交换 (Packet Switching)、多时钟域设计 (Clocking Tutorial)，直到复杂的系统调试 (Debug Walkthrough) 和性能分析 (Performance Analysis)。每个教程都是端到端可运行的——包含 AIE 图、PL HLS 核、主机代码以及配置文件 (system.cfg)。

核心心智模型： Versal 系统作为"数据流剧场"

要理解本模块中的各种技术，建议采用数据流剧场的类比：

1. 演员 (AIE Kernels) 与 舞台 (AIE Array)

• AIE 内核是矢量计算专家，专注于 SIMD 运算。它们有严格的"社交规则"——只通过 FIFO 接口与邻居交谈，不能直接访问 DDR。
• AIE 阵列是舞台，数据在图中流动，触发计算。图 (Graph) 定义了演员之间的互动关系。

2. 道具与场景搬运工 (PL Kernels / Data Movers)

• PL 内核是数据搬运工和转换器：
  • MM2S (Memory-to-Stream)：从 DDR 读取数据，打包成 AXI Stream 注入 AIE。
  • S2MM (Stream-to-Memory)：从 AIE 接收流数据，写回 DDR。
  • 处理型 PL 核 (如 polar_clip)：在 PL 中完成不适合 AIE 的计算（如需要复杂控制流的 CORDIC 算法）。

3. 导演与剧本 (Host Software / XRT)

• Host 程序是导演，它：
  • 加载 AIE 图 (.xsa 或 .xclbin)
  • 配置运行时参数 (RTP - Run-Time Parameters)，动态调整 AIE 行为
  • 同步数据 (等待图完成，查询状态)
  • 管理 PL 内核的 DMA 缓冲区

4. 舞台机械与管线 (Connectivity / system.cfg)

• system.cfg 是舞台机械设计图，定义了：
  • 哪些 PL 核存在 (nk=kernel_name:count:instance_names)
  • 数据流连接 (sc=source:destination)
  • 时钟域 (freqHz, defaultFreqHz)

这个心智模型帮助你定位问题：是"演员不会演" (AIE kernel 算法错误)？"道具没到位" (PL DMA 配置错误)？还是"导演指挥混乱" (Host 程序时序错误)？

架构全景：数据与控制的双轨网络

Versal AIE 系统不是简单的"主从"结构，而是数据流与控制流正交的混合架构。

控制流路径 (Control Path)

• XRT (Xilinx Runtime) 是主控程序，运行在 ARM A72 或 x86 主机上。
• 通过 xrt::graph API 加载和配置 AIE 图。
• 通过 graph.update() 修改 RTP (Run-Time Parameters)，动态调整 AIE 内核行为（如滤波器系数、算法阈值）。
• 控制 PL 内核的 DMA 启动/停止（通过 XRT 的 kernel 对象）。

数据流路径 (Data Path)

• MM2S (Memory-to-Stream)：从 DDR 读取数据，通过 AXI4-Stream 协议注入 AIE 或 PL。
• AIE Graph：数据在 AIE 内核间的 FIFO 中流动，触发计算。
• PL Processing Kernels (如 polar_clip)：在 PL 中执行不适合 AIE 的复杂控制流算法（如 CORDIC 极坐标裁剪）。
• S2MM (Stream-to-Memory)：将 AIE/PL 的输出流写回 DDR。

关键设计洞察：为何分离控制与数据？

• 确定性与实时性：数据路径需要确定的吞吐和延迟，而控制路径通常是事件驱动的（如用户调整参数）。分离避免控制流量的突发影响数据流水线的稳定性。
• 异构优化：数据路径针对吞吐量优化（宽总线、流协议），控制路径针对灵活性优化（AXI-Lite 寄存器访问）。
• 安全性与隔离：控制路径的崩溃（如非法 RTP 更新）不应破坏正在运行的数据流水线（尽管需要正确设计来确保这一点）。

核心技术概览：本模块涵盖的关键机制

1. Run-Time Parameter (RTP) 重配置 —— 动态调整算法的"旋钮"

问题：AIE 阵列一旦启动，内部内核以确定性数据流方式运行。如果需要在运行时调整滤波器系数、改变阈值或切换工作模式，如何在不停止整个图的情况下实现？

解决方案：Xilinx 提供了 RTP (Run-Time Parameters) 机制：

• 同步 RTP (Sync RTP)：通过 graph.update(port, value) 更新。该调用会阻塞直到 AIE 内核安全地读取该值（通常是在特定的 readincr 或 writeincr 边界）。
• 异步 RTP (Async RTP)：通过 graph.update(port, value, offset) 更新数组类型的参数，允许主机批量写入，AIE 内核异步读取。
• 数组 RTP (Array RTP)：支持向 AIE 阵列广播相同的参数到多个内核，或从多个内核收集状态。

设计权衡：

• 同步 vs 异步：同步 RTP 提供严格的时序保证（适合实时控制环路），但有阻塞开销；异步 RTP 吞吐更高，但需要应用层处理时序同步。
• 更新频率：RTP 不是为高带宽数据设计的，而是为控制参数（几百 Hz 到几 kHz 的更新率）。如果需要高带宽，应该使用额外的 AXI-Stream 端口。

2. 包交换 (Packet Switching) —— 时分复用 AIE 互连

问题：AIE 阵列的芯片级互连资源是有限的。当多个数据流需要共享同一条物理通道（例如从多个 PL 源到多个 AIE 目的），但每条流独立且不需要同时传输时，如何高效利用物理资源？

解决方案：包交换 (Packet Switching) 机制允许在共享的 AXI-Stream 物理通道上时分复用多个逻辑流：

• 包格式：数据被封装为带包 ID (Packet ID) 的 AXI-Stream 包。包头包含目标标识，允许多个流在物理上共享同一条线路但在逻辑上隔离。
• Buffer AIE vs PktStream AIE：
  • Buffer AIE：AIE 内核通过缓冲接口 (buffer interface) 与包交换网络交互，适合突发式 (burst) 数据传输。
  • PktStream AIE：AIE 内核直接以包流 (packet stream) 方式处理数据，支持更细粒度的流水线和更低的延迟。
• 混合数据类型：包交换支持在同一物理通道上混合传输不同数据类型（如 int32、float、cint16），只要包格式正确解析。

设计权衡：

• 电路交换 vs 包交换：电路交换（专用 AXI-Stream 连接）提供确定性的低延迟，但消耗更多物理路由资源；包交换提高资源利用率，但引入了包解析/重组的开销和潜在的队头阻塞 (head-of-line blocking)。
• 复杂度：包交换需要精确的时序规划，确保发送端和接收端的包速率匹配，否则会导致包缓冲溢出或下溢。

3. 多时钟域与跨域同步 —— 异构时序的舞蹈

问题：Versal 是高度异构的芯片。AIE 阵列通常运行在 1 GHz 以上，PL 可以运行在不同频率（如 200 MHz、400 MHz），DDR 控制器又有自己的时钟。如何安全地在这些时钟域之间传输数据？

解决方案：

• 时钟约束：在 system.cfg 中通过 freqHz 或 defaultFreqHz 指定各组件的时钟频率。
• 跨时钟域 FIFO：Vitis 工具链会自动在 AIE-PL 接口处插入适当的 CDC (Clock Domain Crossing) 同步器。对于 PL 内部，开发者需要确保 AXI-Stream 握手机制正确处理跨时钟。
• 时钟分频与倍频：Versal 的时钟向导 (Clocking Wizard) 提供从单一参考时钟生成多路相位对齐时钟的能力。

设计权衡：

• 性能 vs 功耗：更高的时钟频率带来更高吞吐，但功耗呈超线性增长 (P ~ f*V^2)。AIE 的高频是为了满足矢量运算的算力需求，而 PL 的数据搬移核不需要那么高的频率。
• 时序收敛难度：跨时钟域路径是时序分析的重点和难点。工具可以自动处理简单的 AIE-PL 边界，但复杂的 PL 内部跨时钟需要手动约束和验证。

子模块概览与导航

本模块按照学习路径和功能域划分为以下子模块，每个子模块都包含可运行的完整示例：

RTP 重配置流程 —— 动态控制 AIE 行为

涵盖同步/异步 RTP、标量与数组 RTP 的更新机制。教你在不停止 AIE 图的情况下，动态调整滤波器系数、算法阈值等运行时常数。

关键概念：同步 RTP（阻塞式安全更新） vs 异步 RTP（高吞吐批量更新） vs 数组 RTP（多内核广播）。

包交换与流式传输 —— 高效共享互连资源

展示如何在单一物理 AXI-Stream 通道上通过包交换 (packet switching) 时分复用多个逻辑数据流。包含 Buffer AIE、PktStream AIE 以及混合数据类型传输。

关键概念：电路交换（专用通道） vs 包交换（统计复用）；Buffer 接口 vs PktStream 接口；包头解析与路由。

Versal 集成、时钟与 RTL IP —— 异构集成基础

从最简单的 Versal AIE+PL 集成开始，逐步引入多时钟域设计（时钟分频、倍频、跨时钟域同步），以及如何集成 RTL IP（非 HLS 的 Verilog/VHDL 模块）与 AIE。

关键概念：AIE-PL 基本连接；时钟域交叉 (CDC)；同步器 (FIFO、Handshake)；RTL IP 打包与接口适配。

调试、仿真与性能分析 —— 问题定位与优化

教授如何使用 Vitis 仿真器 (HW Emulation) 和 Vivado 波形分析器调试 AIE+PL 系统。深入分析性能瓶颈：DMA FIFO 配置不当导致的挂起、吞吐限制、缓冲区大小选择。

关键概念：硬件仿真 (HW Emulation) vs 硬件运行；波形分析 (ILA)；死锁检测；FIFO 深度与性能。

后链路重编译与外部流量生成器 —— 高级系统集成技术

涵盖 Post-Link Recompile（在不重新综合整个设计的情况下修改 PL 逻辑）和 External Traffic Generator (ETG)（使用外部 Python 脚本生成测试激励，替代 PL 数据搬移核）。

关键概念：增量式重编译；快速迭代调试；Python 驱动的硬件仿真；仿真与硬件的协同验证。

独立图组合 —— 模块化 AIE 设计

展示如何将多个独立的 AIE 图（可能来自不同团队、不同 IP 库）在同一个 Versal 芯片上组合运行，管理它们之间的资源共享和通信。

关键概念：AIE 图的分区；GMIO (Global Memory I/O) 分配；独立图的初始化与同步。

关键设计决策与权衡

本模块中的技术选择反映了 Versal 架构设计中的深层权衡。理解这些权衡有助于你在实际项目中做出正确决策：

1. 数据搬移：PL DMA vs AIE GMIO

决策：何时使用 PL 侧的 HLS DMA 核（如 MM2S/S2MM），何时使用 AIE 的 GMIO 直接访问 DDR？

权衡分析：

• PL DMA (MM2S/S2MM)：

  • 优点：灵活性高，可进行数据重排 (reordering)、填充/裁剪 (padding/stripping)、格式转换；适合不规则访问模式。
  • 缺点：消耗 PL 资源（LUT、FF、BRAM）；增加设计复杂度；延迟较高（需要经过 PL 逻辑）。

• AIE GMIO (Global Memory I/O)：

  • 优点：低延迟、高带宽的直接 AIE-DDR 路径（绕过 PL）；不消耗 PL 资源；配置简单（在 graph 中声明 GMIO 端口）。
  • 缺点：功能有限（只能进行连续的块传输，不支持复杂的数据重排）；需要确保 DDR 访问的对齐和连续性。

选择指南：

• 如果只需要简单的连续数据块搬移 → 使用 GMIO（性能更好，资源更少）。
• 如果需要数据重排、数据包解析、条件搬移或复杂地址模式 → 使用 PL DMA（灵活性优先）。
• 在某些设计中，两者结合：GMIO 用于高速数据通路，PL DMA 用于控制参数和元数据。

2. 控制接口：同步 RTP vs 异步更新 vs 流式控制

决策：如何选择控制参数的动态更新机制？

权衡分析：

• 同步 RTP (Run-Time Parameter)：

  • 机制：graph.update(port, value) 阻塞直到 AIE 内核安全读取。
  • 优点：时序确定性强，适合实时反馈控制环路；实现简单（无需额外的应用层同步）。
  • 缺点：阻塞调用可能增加主机软件复杂度（需要异步线程或回调）；更新频率受限（几十 kHz 级别）。

• 异步 RTP (Async RTP)：

  • 机制：主机批量写入参数内存，AIE 内核异步读取。
  • 优点：更新吞吐率高（MHz 级别）；主机非阻塞，可继续执行其他任务。
  • 缺点：需要应用层处理读写同步（如使用标志位、中断或轮询）；时序不确定性较高。

• 专用 AXI-Stream 控制通道：

  • 机制：将控制参数作为正常数据流的一部分，通过额外的 AXI-Stream 端口发送。
  • 优点：带宽不受 RTP 限制；可以精确控制参数生效的时刻（与数据流对齐）。
  • 缺点：消耗额外的 AIE 端口和 PL 资源；需要设计自定义的包格式和协议。

选择指南：

• 低频、关键控制（如切换工作模式、更新校准系数）→ 同步 RTP（简单、可靠）。
• 高频、批量配置（如每帧都更新的自适应滤波器系数）→ 异步 RTP（性能优先）。
• 控制必须与数据精确对齐（如每个样本的增益控制）→ 专用 AXI-Stream 通道（精确控制）。

3. 互连策略：电路交换 vs 包交换

决策：何时使用专用的 AXI-Stream 连接（电路交换），何时使用包交换 (Packet Switching)？

权衡分析：

• 电路交换 (Circuit Switching / Direct Connection)：

  • 机制：每条数据流独占一条物理 AXI-Stream 通道，从源到目的直接连接。
  • 优点：
    • 确定性延迟：没有排队、仲裁或包解析开销，延迟可预测且最小。
    • 简单性：无需包头、包解析状态机，PL 和 AIE 逻辑更简单。
    • 无队头阻塞：每个流独立，不会因其他流的拥塞而阻塞。
  • 缺点：
    • 资源浪费：当多个流不需要同时传输时，物理通道空闲，无法被其他流复用。
    • 可扩展性差：流数量增加时，物理连接数线性增长，最终受限于芯片引脚或互连资源。

• 包交换 (Packet Switching)：

  • 机制：多个逻辑流共享物理 AXI-Stream 通道，数据被封装为带目标标识的包，通过路由节点转发。
  • 优点：
    • 统计复用：提高物理资源利用率，适合"突发式"、非连续的流量模式。
    • 可扩展性：新增流只需分配新的包 ID，无需新增物理连线。
    • 灵活性：支持多播 (multicast) 和复杂的拓扑（如树、网格）。
  • 缺点：
    • 非确定性延迟：包需要经过解析、仲裁、排队，延迟可变且难以预测（取决于网络拥塞）。
    • 复杂度：需要设计包头格式、包解析状态机、路由表、流控机制。
    • 队头阻塞 (Head-of-Line Blocking)：如果一个包被阻塞，它后面同一队列的所有包都被阻塞，即使它们的目的地不同。
    • 开销：包头消耗带宽，包解析和重组增加延迟。

选择指南：

• 实时、确定性要求（如实时控制、闭环反馈）→ 电路交换（延迟可预测）。
• 高带宽、非实时、突发流量（如批处理视频流、数据中心网络）→ 包交换（资源效率高）。
• 混合架构：系统中关键路径使用电路交换保证实时性，非关键路径使用包交换提高资源利用率。

新贡献者必读：常见陷阱与避坑指南

作为刚加入团队的开发者，以下是你最可能踩到的坑以及如何避免它们：

1. 时钟域不一致导致的仿真挂起

症状：硬件仿真 (HW Emulation) 启动后，在某个 AIE-PL 接口处挂死，没有错误消息，只是超时。

根本原因：AIE 默认时钟（如 1 GHz）与 PL 核的时钟（如 200 MHz）没有正确的同步机制。AIE 侧的数据发送速度超过 PL 侧的处理速度，导致 FIFO 溢出（或相反，PL 侧等待 AIE 数据导致死锁）。

避免方法：

• 确保在 system.cfg 中为所有 PL 核显式指定时钟频率 (freqHz=... 或 [clock] defaultFreqHz=...)。
• 对于 AIE-PL 边界，确保使用 hls::stream 并启用正确的握手 (TVALID/TREADY)。Vitis HLS 会自动插入必要的同步逻辑，但你需要确保 FIFO 深度 (STREAM_DEPTH) 足够吸收瞬时速率不匹配。
• 在硬件仿真中启用详细的 AIE 日志 (aiesimulator --dump-vcd) 检查 AIE 核的 TREADY 信号是否被拉低（表明下游阻塞）。

2. PL HLS 核的 hls::stream 深度配置不足

症状：设计在高带宽场景下间歇性挂起，或在 HW Emulation 中报 "Deadlock detected" 错误。

根本原因：HLS 综合工具默认的 hls::stream 深度可能不足以吸收生产者和消费者之间的速率波动 (jitter)。当生产者突发产生数据快于消费者时，FIFO 满导致生产者阻塞；如果消费者同时也在等待另一个 FIFO 的数据（典型的循环依赖），就会发生死锁。

避免方法：

• 显式指定 STREAM 深度：在 HLS 代码中，总是为 hls::stream 显式指定深度，如 hls::stream<ap_axis<32>, 16> my_stream;。深度应基于你的速率波动分析：深度 = 突发长度 × (生产者速率 / 消费者速率 - 1)。
• 使用 DATAFLOW 优化：在 HLS 中启用 #pragma HLS DATAFLOW，工具会自动分析生产者-消费者关系并尝试平衡流水线。但注意 DATAFLOW 要求特定的代码结构（单生产者单消费者）。
• ** deadlock 分析**：如果设计挂起，首先检查所有的 hls::stream 读写配对是否平衡（每个写必须有对应的读，且不能有条件地跳过）。使用 Vitis HLS 的 "Dataflow Viewer" 可视化流水线结构。
• 参考本模块的 "Performance Analysis" 教程：特别是 testcase_dmafifo_opt vs testcase_nofifo_hang vs testcase_ssfifo，它们专门对比了不同 FIFO 深度配置的影响。

3. system.cfg 中的连接 (sc) 与内核实例 (nk) 不匹配

症状：Vitis 链接阶段报错：ERROR: [CFGEN 83-2287] stream connection sc=... has no source/destination，或运行时 XRT 报错 Connection not found。

根本原因：system.cfg 中 [connectivity] 节的 sc= (stream_connect) 声明引用了不存在的内核实例，或 nk= (num_kernels) 定义的内核实例名与 sc= 中使用的不一致。

避免方法：

• 严格匹配命名：如果 nk=mm2s:1:mm2s_1，那么在 sc= 中必须使用 mm2s_1.s（实例名是 mm2s_1，不是 mm2s）。
• 检查 AIE 图端口名：连接到 AIE 的 sc= 必须使用 graph 中定义的 PLIO 端口名，通常是 ai_engine_0.PortName（ai_engine_0 是默认实例名，可以在 Vitis 中修改）。
• 使用 Vitis IDE 的可视化连接工具：手动编辑 system.cfg 容易出错。Vitis IDE 提供图形化的连接编辑器，可以自动生成正确的 nk= 和 sc= 语法。
• 模块化测试：在集成完整系统之前，先单独测试每个 sc= 连接。例如，先用一个简单的 loopback（MM2S 直接连 S2MM，不经过 AIE）验证数据搬移通路，再逐步加入 AIE 处理。

4. RTP 更新的时序竞争 (Race Condition)

症状：RTP 更新似乎"随机"失效——有时 AIE 内核读取到新值，有时还是旧值，即使主机代码确认 graph.update() 已返回。

根本原因：AIE 图的数据流执行是确定性的，但 RTP 更新的时机与 AIE 内核的执行可能存在竞争。特别是使用异步 RTP 时，主机写入参数内存后，如果 AIE 内核在下一个 readincr 之前就读取了该值（或相反，AIE 还没读完，主机又写入了新值），就会导致数据竞争。

避免方法：

• 优先使用同步 RTP：除非性能分析证明同步 RTP 的阻塞开销不可接受，否则使用同步 RTP（graph.update(port, value) 不带 async 标志）。同步 RTP 由运行时保证在 AIE 内核安全读取后才返回，消除了竞争。
• 异步 RTP 的显式同步：如果必须使用异步 RTP（如批量更新数组），应用层需要实现同步机制：
  • 使用一个"标志位 RTP"：主机先更新数据 RTP，然后设置一个标志位 RTP 通知 AIE 新数据已就绪；AIE 读取数据后清除标志位，通知主机可以写入下一批。
  • 或使用 graph.wait() / graph.end() 确保 AIE 到达特定状态后再更新 RTP。
• 理解 AIE 内核的执行模型：AIE 内核通常运行在无限循环中 (for(;;))，每个循环迭代处理一个或多个样本。RTP 的读取通常放在循环的开始。确保 RTP 读取在数据依赖的关键路径之前，避免部分更新被使用。
• 调试技巧：在 HW Emulation 中启用详细的 RTP 日志（设置 XRT_HPI_VERBOSITY=3），观察 RTP 的写入和 AIE 的读取时序。如果看到 RTP 值在 AIE 还没读完时就被覆盖，那就是竞争。

跨模块依赖与关联

本模块（AIE Feature Tutorials: Runtime and Platform）不是孤立存在的，它与整个 Versal/Vitis 生态系统有紧密的联系：

前置知识与依赖模块

1. AIE_ML_Feature_Tutorials：提供 AIE 内核编程的基础（矢量 intrinsic、数据流图语法）。本模块的 Runtime and Platform 教程假设你已理解 AIE 内核本身如何编写。

2. AIE_Design_Graphs_and_Algorithms：展示复杂的 AIE 图设计（如 FFT、FIR、Matrix Multiply）。本模块的教程多使用简化图，专注于运行时机制；实际产品级设计通常需要结合该模块的算法实现。

3. AIE_Design_System_Integration：提供更大规模系统级设计的参考（如多通道 channelizer、完整 LeNet 系统集成）。本模块的 tutorials 是单一功能点的示例；该模块展示如何组合多个功能点。

4. Vitis_Platform_Creation_Tutorials：教你如何创建自定义 Vitis 平台（Platform）。本模块的 tutorials 通常使用预定义平台（如 xilinx_vck190_base_202320_1）；如果你需要自定义硬件（添加自己的 IP、修改 DDR 配置），需要先学习该平台创建流程。

下游应用与相关模块

1. Hardware_Acceleration_Design_Tutorials：展示 Vitis 加速计算流 (XRT + HLS)，不涉及 AIE。如果你同时开发 AIE 加速器和传统 FPGA 加速器（如纯 HLS 的 CNN），需要理解两种开发模式的交互。

2. Developer_Contributed_Examples：社区贡献的示例，可能展示本模块未覆盖的高级技巧或特定应用场景。

工具链与运行时依赖

本模块的内容与以下工具版本强相关，请确保使用匹配的 Vitis / Vivado / XRT 版本：

• Vitis IDE / Vitis HLS：用于 AIE 图编译、PL HLS 核综合。
• Vivado：用于底层硬件集成、时序约束、比特流生成。
• XRT (Xilinx Runtime)：主机端运行时库，用于管理 AIE 图、PL 内核、内存缓冲区的交互。
• AIE Simulator (aiesimulator)：纯软件 AIE 功能仿真。
• HW Emulator (hw_emu)：硬件仿真，模拟完整的 AIE+PL+Host 系统行为。

版本一致性至关重要：AIE 工具链（aiecompiler）、XRT、Vivado 的 IP 库必须在同一版本（如 2023.2）下匹配。混合版本可能导致微妙的兼容性问题（如 RTP 更新失败、仿真挂起）。

本文档由 AIE Feature Tutorials: Runtime and Platform 模块的主文档和 6 个子模块文档组成：

• RTP 重配置流程 —— 动态控制 AIE 行为
• 包交换与流式传输 —— 高效共享互连资源
• Versal 集成、时钟与 RTL IP —— 异构集成基础
• 调试、仿真与性能分析 —— 问题定位与优化
• 后链路重编译与外部流量生成器 —— 高级系统集成技术
• 独立图组合 —— 模块化 AIE 设计