1. 产品化部署总览
Kria SOM（System-on-Module）与纯 FPGA 芯片最大的区别在于：它把 Zynq UltraScale+ MPSoC、DDR、eMMC、电源管理、时钟等做成了一块可直接贴装的模块，开发者拿到手时，硬件已经"半成品化"。因此 Kria 的产品化部署不是从画原理图开始，而是从"选型—载板设计—固件与 OS 定制—应用加速—量产烧录—认证交付"这条链路上推进。理解这条链路的全貌，是后续每一章具体操作的前提。
一、产品化交付的四条主线
Kria 项目通常并行推进四条主线，它们相互依赖但节奏不同：
- 硬件主线：SOM 选型 → 载板（Carrier Card）原理图与 PCB → 电源/时钟/接口验证 → 结构散热。
- 软件主线：PetaLinux/Yocto 构建 → 设备树定制 → 驱动适配 → 根文件系统裁剪 → OTA 升级机制。
- 加速主线：PL 逻辑设计 → Vitis 加速内核 → 与 PS 端的数据通路（AXI/DMA）→ 性能与功耗评估。
- 交付主线：Boot 镜像与量产烧录 → 功能/环境测试 → 认证（CE/FCC/CCC 等）→ 文档与版本冻结。
四条主线在"系统联调"和"量产冻结"两个节点强耦合。硬件未定型时软件只能跑在官方 KV260/KR260 评估板上；加速逻辑未收敛时，功耗与散热评估无法定稿。因此项目管理上必须明确每个里程碑的"冻结对象"。
二、关键里程碑与冻结对象
下面这张图给出从立项到量产的里程碑链路，以及每个节点必须冻结的交付物。图中横向为时间推进，纵向区分硬件、软件、加速与交付四条泳道，菱形节点表示评审/冻结点。
三个里程碑的含义需要明确：M1（EVT 冻结）要求载板原理图与 SOM 引脚映射确认，PetaLinux 能在自研载板上启动到串口控制台；M2（DVT 冻结）要求硬件信号完整性通过、加速内核功能正确、根文件系统可 OTA；M3（PVT 冻结）要求量产烧录脚本验证通过、认证样机送检、交付文档版本锁定。每个里程碑未通过时，不应把下游工作当作已完成。
三、角色分工
Kria 项目团队通常不大，但角色边界必须清晰，否则容易出现"硬件等软件、软件等硬件"的僵局。典型分工如下：
| 角色 | 核心职责 | 关键交付物 |
|---|---|---|
| 硬件工程师 | 载板原理图/PCB、电源树、接口电平、散热结构 | 原理图、PCB、BOM、硬件测试报告 |
| 嵌入式软件工程师 | PetaLinux 构建、设备树、驱动、根文件系统、OTA | BOOT.BIN、image.ub、rootfs、设备树源文件 |
| FPGA/加速工程师 | PL 逻辑、Vitis 加速内核、AXI/DMA 数据通路 | Bitstream、.xclbin、Overlay、时序报告 |
| 系统/测试工程师 | 软硬联调、功能测试、环境测试、认证支持 | 测试用例、测试报告、认证样机 |
| 项目/交付负责人 | 里程碑管理、版本冻结、文档归档、量产导入 | 交付包、版本清单、量产烧录 SOP |
需要强调的是，Kria 的软件与加速工作高度依赖硬件定型。在载板未回板前，软件团队应先在官方评估板（如 KV260）上完成 PetaLinux 构建与驱动验证，把设备树中与载板相关的部分参数化，回板后只需替换引脚映射与电源域配置，而不是从零重做。
四、交付物清单与版本冻结
产品化交付的最终形态是一个可复现的交付包。以下清单可作为项目收尾时的核对依据（示例字段，实际项目按需增删）：
交付包目录结构（示例）
├── hardware/
│ ├── schematic_rev1.2.pdf
│ ├── pcb_gerber_rev1.2.zip
│ └── bom_rev1.2.xlsx
├── firmware/
│ ├── BOOT.BIN
│ ├── image.ub
│ ├── rootfs.ext4
│ └── system.dtb
├── acceleration/
│ ├── design_1.bit
│ ├── kr260_overlay.xclbin
│ └── timing_summary.rpt
├── production/
│ ├── flash_qspi.tcl
│ ├── flash_emmc.sh
│ └── mac_address_pool.csv
├── test/
│ ├── functional_test_report.pdf
│ ├── thermal_test_report.pdf
│ └── emc_pre_scan.pdf
└── docs/
├── release_notes_v1.0.md
├── bringup_guide.pdf
└── version_manifest.json
版本冻结的核心原则是"可追溯"：每一个二进制文件都应能对应到具体的源码提交、构建脚本和工具版本。例如 BOOT.BIN 应记录其 FSBL、PMUFW、ATF、U-Boot、PL bitstream 各自的版本；image.ub 应记录内核版本、设备树哈希与根文件系统构建时间。缺少这层追溯，量产阶段出现问题时将无法定位是硬件批次、固件版本还是加速逻辑引入的差异。
version_manifest.json，把每个交付物的版本、构建时间、对应 Git commit 和工具链版本写入其中。这个习惯在 M2 之后会显著降低联调与认证阶段的沟通成本。
五、从评估板到自研载板的迁移要点
多数 Kria 项目会先在 KV260 或 KR260 上做原型，再迁移到自研载板。迁移时最容易出问题的三个点是：引脚映射（SOM 连接器上的 PL 引脚在自研载板上用途不同，设备树与约束文件需同步修改）、电源域（自研载板可能关闭某些 SOM 电源轨，导致外设不工作）、启动介质（评估板默认从 QSPI/SD 启动，自研载板可能改为 eMMC，需调整 boot mode 与 FSBL 配置）。建议在迁移前先做一张"评估板—自研载板差异对照表"，逐项确认后再改设备树与约束，避免反复回板调试。
总体而言，Kria 产品化部署的难点不在单点技术，而在于四条主线的节奏对齐与交付物的版本一致性。把里程碑冻结对象、角色职责和交付包结构在项目启动时就定义清楚，后续每一章的构建、烧录、测试与认证工作才能落在确定的基线上。