1. Versal架构全景与协同设计思维

AMD Versal 自适应 SoC（Adaptive SoC）不是传统意义上“FPGA 加一个硬核处理器”的简单叠加，而是一套把标量处理、可编程逻辑、矢量/AI 计算、片上网络与高速接口统一编排的异构计算平台。理解 Versal 的第一步，是把它看成一个“按数据形态分工”的系统：控制流、顺序逻辑交给处理系统（PS），位级并行与定制时序交给可编程逻辑（PL），矩阵乘加与高吞吐矢量运算交给 AI 引擎（AIE），而各计算域之间的大流量搬运则交给 NoC。协同设计思维的核心，就是让每一类计算落到最合适的引擎上，并让数据以最低代价在它们之间流动。

一、自适应 SoC 的组成与分工

从顶层看，Versal 器件由若干可独立配置又彼此耦合的域构成。处理系统通常包含 Arm Cortex-A72 应用核与 Cortex-R5F 实时核，前者运行 Linux 等富操作系统，负责调度、网络协议栈、文件系统与人机交互；后者承担确定性实时任务、安全监控与启动管理。可编程逻辑提供细粒度并行、自定义数据通路、硬核存储与 DSP 资源，适合协议转换、流水线加速、时序敏感接口。AI 引擎阵列由大量 VLIW 矢量核与专用乘累加单元组成，配合本地存储器与 AXI 流接口，擅长 8/16/32 位定点的卷积、矩阵乘、FFT 等运算。NoC 是片上可编程的数据高速公路，把 PS、PL、AIE、DDR 控制器、PCIe、以太网等硬核 IP 连接起来，用 AXI 主从端口和网络包交换替代传统点对点布线。

这些域并非孤立。PS 可以通过 AXI 互连访问 PL 中的寄存器与 BRAM，也可以经 NoC 直接访问 AIE 的共享存储；PL 可以产生流数据送入 AIE 做推理，再把结果写回 DDR 供 PS 读取。正是这种“可组合性”，使 Versal 能同时满足硬实时、高吞吐与灵活可重构三类需求。

Versal 自适应 SoC 计算域与数据通路 处理系统 PS Cortex-A72 应用核 Cortex-R5F 实时核 DDR / 外设 / 启动 控制流 · 调度 · 协议栈 可编程逻辑 PL LUT / FF / BRAM / DSP 自定义流水线 协议转换 · 时序接口 位级并行 · 定制时序 AI 引擎 AIE VLIW 矢量核阵列 MAC / 本地存储 / 流接口 矩阵乘 · 卷积 · FFT 片上网络 NoC 可编程 AXI 主/从端口 包交换 · 多路径 · QoS DDR 控制器 PCIe / 以太网 / HBM PL ↔ AIE 流通道 PS ↔ PL 寄存器访问 统一搬运 · 降低布线拥塞 协同设计关注点 计算落位：谁算最合适 数据搬运：路径与带宽 存储层级：DDR/BRAM/本地 同步机制：中断/轮询/流控 实时性：延迟与抖动 功耗与资源预算 可重构与升级余量 优化目标 吞吐 ↑ 延迟 ↓ 功耗 ↓ 资源占用可控 · 可验证

二、NoC：被低估的性能枢纽

很多初学者把 NoC 当成“自动连线工具”，这是误解。NoC 是可编程的片上网络，其端口数量、位宽、时钟域、QoS 等级和路由路径都会直接影响系统吞吐与延迟。举例来说，若 AIE 推理结果需要写回 DDR 再由 PS 读取，数据要经过 AIE 流接口→NoC→DDR 控制器→DDR→PS 缓存，这条链路上任何一段带宽不足都会成为瓶颈。合理做法是让 PL 或 AIE 通过 NoC 直接访问 DDR，减少 PS 参与；对延迟敏感的少量控制信息则走 AXI-Lite 寄存器通路，避免占用大带宽通道。

在 Vivado 与 Vitis 流程中，NoC 通过 NoC Compiler 或 IP integrator 配置，需要为每个连接指定主从端口、位宽转换、时钟域 crossing 与 QoS。一个常见的教学示例是：AIE 阵列以 4 路 128 位 AXI-Stream 输出，经 NoC 汇聚为 512 位写入 DDR，理论峰值带宽为 512 bit × 频率。若 DDR 实际可用带宽只有理论值的 60%～70%，就需要重新评估是否把中间结果留在 AIE 本地存储或 PL BRAM 中，而不是反复落 DDR。

三、软硬件协同设计原则

协同设计不是“先写软件再想硬件”，也不是“先搭硬件再补软件”，而是在系统级同时约束三件事：计算分工、数据流与接口契约。可遵循以下原则：

  • 按数据形态分工：标量控制、分支密集、协议栈放 PS；位操作、定制时序、低延迟接口放 PL；规则的大规模乘加与矢量运算放 AIE。
  • 让数据靠近计算：能留在 AIE 本地存储或 PL BRAM 的中间结果，不要频繁写回 DDR；必须共享的大块数据用 NoC 高带宽通道搬运。
  • 接口先定契约：在写 RTL 和内核之前，先确定 AXI-Stream 位宽、时钟频率、握手协议、缓冲深度与背压策略，避免后期返工。
  • 为实时性留余量：R5F 侧任务要评估最坏执行时间与中断延迟，A72 侧 Linux 调度抖动不能作为硬实时依据。
  • 可观测性内建：在 PL 中预留性能计数器、在 AIE 图中保留事件 trace、在 PS 侧使用 perf 或自定义日志，使瓶颈可定位。

四、性能优化目标与判断依据

Versal 系统的优化目标通常不是单一指标，而是吞吐、延迟、功耗、资源与可维护性的折中。实际工程中可用一组可量化指标来驱动决策：端到端吞吐（帧/秒或 GB/s）、单次推理延迟（μs）、DDR 带宽占用率、PL 资源利用率（LUT/FF/BRAM/DSP）、AIE 核占用率、系统功耗与结温。判断是否达成目标，不能只看“跑通了”，而要看瓶颈是否从计算转移到了搬运，或从搬运转移到了同步。

一个实用的判断顺序是：先看数据是否走了最远路径（例如 AIE→DDR→PS→PL），再看 NoC 与 DDR 带宽是否饱和，最后看计算单元利用率是否偏低。若计算单元利用率低而带宽饱和，说明问题在数据供给；若带宽有余而计算单元空闲，说明并行度或流水线设计不足。

以视频推理为例：假设 1080p@30fps 输入，每帧需做预处理、CNN 推理与后处理。若把预处理放在 PS 上做，CPU 可能被像素级操作占满；把预处理放到 PL 做色彩空间转换与缩放，AIE 做卷积，PS 只做调度与结果封装，则三段可以流水并行。此时端到端延迟约等于最慢一级的延迟加上少量同步开销，而不是三级延迟之和。这正是协同设计带来的收益：不是让某一部分更快，而是让系统整体不再互相等待。

← 上一章 📖 返回目录 下一章 →