1. 课程导入与Kria平台全景
在工业质检、智慧交通、零售分析、医疗影像等场景中，传统“相机+工控机+独立加速卡”的方案正面临功耗高、体积大、部署周期长的问题。AMD Kria 自适应系统级模块（SOM）把 Zynq UltraScale+ MPSoC 的 ARM 处理器、可编程逻辑、DDR 内存和电源管理集成到一张信用卡大小的核心板上，再配合 Kria SOM 载板与 Kria App Store 中的预构建应用，使开发者能够以“核心板+载板+应用”的方式快速构建智能相机与视觉边缘终端。本课程围绕这条技术路线展开，从平台认知、工具链使用到视觉应用部署逐步推进。
智能相机与视觉边缘终端的典型架构
智能相机与视觉边缘终端虽然形态不同，但内部数据通路高度相似。以一路 MIPI CSI-2 图像输入为例，典型链路可以概括为：图像传感器输出 RAW 或 YUV 数据，经 CSI-2 接收器进入可编程逻辑；在 PL 中完成去马赛克、自动白平衡、色彩空间转换、缩放等图像信号处理；处理后的帧通过 AXI4-Stream 或 VDMA 写入 DDR；ARM 侧的应用程序或 AI 推理引擎读取帧数据，执行目标检测、分类或测量；结果通过千兆以太网、USB、DisplayPort 或工业 IO 输出。整条链路中，PL 承担确定性强的像素级流水线，ARM 承担调度、协议栈和上层业务，二者通过 AXI 总线与中断协同。
这种架构的关键价值在于“软硬协同”：图像预处理放在 PL 中可保证低延迟和低 CPU 占用，AI 推理可放在 PL 的 DPU 或 ARM 的 CPU/GPU 上，具体取决于算力、功耗和模型规模。理解这条数据通路，是后续使用 Kria 平台进行开发的基础。
Kria SOM 产品线定位
Kria SOM 目前主要有 K26、K24 两个核心板系列，以及面向视觉评估的 KV260 套件。K26 系列基于 Zynq UltraScale+ MPSoC，PL 逻辑资源较多，适合多路相机接入、复杂图像信号处理以及较大规模的 AI 加速，常用于智能相机、边缘视觉服务器等对算力和带宽要求较高的场景。K24 系列在逻辑资源、接口数量和功耗上做了裁剪，更适合成本敏感、单路相机、基础 ISP 加轻量推理的工业读码器、门禁终端等产品。KV260 则是搭载 K26 SOM 的视觉套件，板载 MIPI、以太网、DisplayPort、USB 等接口，出厂预装 Ubuntu 和参考应用，适合原型验证、教学和方案评估。
选型时可以先看三个维度：相机路数与分辨率决定 PL 侧 ISP 和接口资源；AI 模型规模与帧率决定 DPU 或 CPU/GPU 算力需求；产品功耗与成本决定 SOM 等级和载板复杂度。若只是验证算法可行性，KV260 是最低门槛的起点；若要进入量产，则需基于 K26 或 K24 设计自定义载板。
开发流程总览
Kria 平台的开发流程可以理解为“硬件平台构建—系统镜像生成—应用开发与部署”三段。硬件平台构建在 Vivado 中完成：创建 Block Design，加入 Zynq MPSoC、MIPI CSI-2 接收、ISP IP、VDMA、AXI 互联等，分配地址并生成 XSA。系统镜像生成在 PetaLinux 或 Ubuntu 侧完成：导入 XSA，配置设备树、内核驱动和根文件系统，生成 BOOT.BIN、image.ub 等启动文件。应用开发则可以在 Vitis 中编写 ARM 端程序，或使用 Vitis AI 将量化后的模型编译为 DPU 可执行的 xmodel，再通过 Kria App Store 的参考应用快速替换模型和输入源。
一个典型的实操顺序是：先确认 KV260 的启动模式与串口连接，使用官方 Ubuntu 镜像启动系统；再通过 xmutil 加载固件与加速器；随后用 vitis_ai_library 或 vart 运行示例模型，观察推理帧率与 CPU 占用；最后替换为自己的模型和相机输入，验证端到端延迟。这个顺序把“平台可用—加速器可用—应用可用”逐层验证，避免一开始就陷入自定义硬件调试。
软硬件工具链
硬件侧的核心工具是 Vivado，用于 PL 逻辑设计、IP 集成、约束与比特流生成；Vitis 用于 ARM 端应用、加速器开发和异构调试；PetaLinux 用于构建嵌入式 Linux 系统，包括设备树、内核和根文件系统。软件侧，Kria App Store 提供经过验证的参考应用，覆盖智能相机、机器视觉、缺陷检测等场景；Vitis AI 提供模型量化、编译和运行时库；Ubuntu 则提供熟悉的包管理和开发环境。对于初学者，建议先以 KV260 + Ubuntu + Kria App Store 应用建立整体认知，再逐步深入到 Vivado 和 PetaLinux 的自定义流程。