1. 课程导入与平台总览

本课程围绕 AMD Kria 系列系统级模块（SOM，System-on-Module）展开，目标是把“实时视频分析”从概念落到可运行、可复现的工程实现。Kria SOM 的定位介于传统 FPGA 开发板与嵌入式 SoC 板卡之间：它把 Zynq UltraScale+ MPSoC、DDR 内存、eMMC、电源管理、时钟与启动配置集成到一个小型模块上，开发者只需设计载板（Carrier Card）并完成软件与加速器部署，即可快速构建边缘视觉产品。理解这一点，是后续所有硬件接口、视频流水线和加速器设计的前提。

Kria SOM 产品线：K26 与 K24 的差异与选型

Kria 家族中与实时视频分析最相关的是 K26 与 K24 两个系列。二者都基于 Zynq UltraScale+ MPSoC，但可编程逻辑（PL）规模、DSP 资源、视频编解码单元（VCU）以及高速接口能力不同，直接决定了能承载多少路视频、能跑多复杂的神经网络。

K26 面向高性能视觉与 AI 推理，典型器件包含较大规模的 PL 逻辑、较多 DSP 与 Block RAM，并集成 H.264/H.265 视频编解码单元，适合多路 1080p 输入、实时目标检测与视频转码并存的场景。K24 则更强调成本与功耗，PL 规模较小，通常不带 VCU，适合单路或少量视频输入、以轻量级推理和图像预处理为主的应用。选型时不能只看“算力”，而应同时评估视频输入路数、分辨率、帧率、推理模型规模、编解码需求与整板功耗预算。

下表给出两个系列在课程语境下的典型对比，数值为教学示例，实际设计须以官方数据手册为准。

实时视频分析的典型场景与关键指标

“实时”在视频分析中不是模糊描述，而是可量化的约束。常见指标包括：端到端延迟（从摄像头曝光到结果输出）、吞吐（每秒处理帧数 FPS）、分辨率与帧率、以及推理精度（mAP、Top-1 等）。例如，智能交通中的车牌识别通常要求 1080p、25~30 FPS、端到端延迟低于 100 ms；工业质检中的缺陷检测可能要求更高分辨率但帧率较低；安防周界入侵检测则强调多路并发与低误报。

这些场景在 Kria 上的实现路径高度相似：摄像头或视频源输入 → 图像预处理（去噪、缩放、色彩空间转换）→ 推理加速器（DPU 或自定义 PL 加速器）→ 后处理（NMS、跟踪、告警）→ 输出（显示、网络、存储）。区别在于每一级的参数与资源分配。课程后续会围绕这条链路逐级展开，而本节先建立整体认知。

软硬件协同设计流程

Kria 项目的核心方法论是软硬件协同设计：不是先写完软件再考虑硬件，也不是先搭好 PL 再补软件，而是从系统指标出发，把任务划分到 PS（处理系统）、PL（可编程逻辑）和 AI 加速器上，并让三者并行推进。一个可操作的流程如下。

1. 需求与指标定义：明确视频路数、分辨率、帧率、延迟上限、模型类型与功耗预算，形成可验证的验收条件。
2. 任务划分：把预处理、推理、后处理、编解码分别映射到 PS、PL、DPU 或 VCU，评估带宽与延迟是否满足。
3. 硬件平台构建：在 Vivado 中配置 PS、PL 接口、视频输入输出 IP、时钟与中断，生成 XSA。
4. 软件与加速器开发：在 Vitis/PetaLinux 中构建系统镜像，使用 Vitis AI 编译量化模型，生成 DPU 指令。
5. 联调与验证：用真实视频流或录制文件跑通链路，测量 FPS、延迟与资源占用，迭代优化。

这个流程的关键在于“可测量”。每一步都应留下可观察的数据：PL 资源利用率、DDR 带宽、DPU 占用率、端到端延迟。没有测量，协同设计就会退化为反复试错。

课程项目目标与交付物定义

本课程以一个完整的“实时视频分析平台”为主线项目，最终交付物包括：

• 一份可综合的 Vivado 硬件工程，包含 PS 配置、视频输入输出通路与必要的 PL 加速模块；
• 一套可启动的 PetaLinux 系统镜像，包含驱动、运行时与应用程序；
• 一个量化并编译后的 AI 模型，能够在 DPU 或 PL 加速器上运行；
• 一份端到端测试报告，记录分辨率、帧率、延迟、资源占用与准确率等关键指标；
• 一套可复现的构建脚本与配置说明，使他人能够按步骤重建整个系统。

项目不追求“一次成功”，而追求“每一步可解释、可复现、可改进”。这也是工程实现与课堂演示的根本区别。

上图把本课程的三条主线放在同一视图中：左侧是 Kria SOM 与载板构成的硬件平台，中间是实时视频分析的数据流，右侧是支撑实现的软件与工具链。三者不是串行关系，而是相互约束：硬件资源决定数据流能跑多快，数据流指标反过来决定软件如何划分任务，软件工具链又决定硬件配置能否被正确加载和验证。