1. 课程导入与Versal产品化全景
欢迎进入《AMD Versal产品化验证与工程交付指南》。在开始讨论验证方法、交付流程和工程细节之前，我们需要先建立一张"全景地图"：Versal ACAP 到底是什么、它和传统 FPGA 有什么本质区别、所谓"产品化验证"与"工程交付"究竟在做什么、整个项目要经过哪些阶段、最终要交出哪些东西。只有把这些问题想清楚，后续每一章的验证手段、脚本、报告才有明确的归属和目的。
一、学习目标
本课程面向已经具备一定 FPGA 或嵌入式开发基础、需要把 Versal 设计真正做成可交付产品的工程师。学完本课程，你应当能够：
- 说清 Versal ACAP 的异构架构组成，以及 PS、PL、AI Engine、NoC、DDR 控制器等关键模块在系统中的角色；
- 区分"功能验证"与"产品化验证"，理解后者为什么必须覆盖上电时序、启动链路、电源、时钟、温度、接口一致性等系统级问题；
- 按阶段组织一个 Versal 项目，从架构规划、RTL/内核开发、系统集成、板级调试到量产交付；
- 独立编写并执行关键验证项，读懂 Vivado/Vitis 报告、ILA 波形、启动日志与电源测量数据；
- 产出一套结构完整、可被下游团队或客户接收的工程交付物。
二、Versal ACAP 架构概览
Versal 是 AMD 的 Adaptive Compute Acceleration Platform（自适应计算加速平台）。它不再是"FPGA 加一个硬核处理器"的简单叠加，而是把多种计算引擎通过片上网络（NoC）连接成一个异构系统。理解这一点，是理解后续所有验证工作的前提。
从产品化视角看，Versal 器件内部可以划分为几个必须分别验证、又必须联合验证的域：
- PS（Processing System）：包含 Arm Cortex-A72 应用核、Cortex-R5F 实时核、平台管理单元（PMU）、DDR 控制器、外设接口等。它是启动链的起点，也是系统控制中心。
- PL（Programmable Logic）：可编程逻辑阵列，承载用户自定义逻辑、接口协议实现和部分加速功能。
- AI Engine（AIE）：面向向量与矩阵运算的阵列，常用于信号处理与 AI 推理，需要独立编译、独立加载、独立验证。
- NoC 与 DDR：NoC 负责各域之间的高带宽数据搬运，DDR 控制器提供外部存储访问。二者是系统性能与稳定性的关键，也是最容易出现"功能对但性能不达标"的地方。
- 启动与配置通路：包括 BootROM、PLM（Platform Loader and Manager）、启动介质（QSPI、eMMC、SD 等）以及 PDI 镜像。产品化验证中，启动链路往往是最先暴露问题、也最影响交付的一环。
下图给出 Versal ACAP 的简化架构与主要数据/控制通路关系，可作为后续章节的参照。
三、什么是产品化验证与工程交付
很多团队在 Versal 上跑通了第一个"点灯"或"回环"程序，就认为项目接近完成。实际上，从"功能能跑"到"产品能交付"，中间隔着一整套系统级工作，这正是本课程的核心。
产品化验证，指的是围绕"这块板子/这个系统能否在真实环境中稳定、可重复、可量产地工作"而展开的验证活动。它至少覆盖以下层面：
- 启动验证：冷启动、热复位、不同启动模式（QSPI、SD、JTAG）下能否可靠进入系统；PDI 加载是否完整；PLM 日志是否正常。
- 电源与时钟验证：各供电轨的上电顺序、电压精度、纹波、上电斜率是否满足器件要求；参考时钟频率与抖动是否达标。
- 接口一致性验证：DDR 训练与眼图、PCIe 链路训练、以太网误码率、GT 收发器误码率等。
- 功能与性能验证：在真实数据流下，AIE、PL、PS 协同工作是否满足吞吐与延迟指标。
- 环境与可靠性验证：高低温、长时间运行、反复上下电、异常注入下的行为。
工程交付，指的是把上述验证过程中形成的设计、脚本、报告、文档、镜像和测试记录，整理成一套可被下游（生产、测试、客户、维护团队）直接使用的成果。交付不是"把文件拷过去"，而是要让接收方能够独立复现、独立判断、独立维护。
四、流程阶段划分
一个典型的 Versal 产品化项目，可以划分为五个阶段。它们并非严格串行，但每个阶段都有明确的输入、输出和退出条件。
| 阶段 | 主要工作 | 关键输出 | 退出条件 |
|---|---|---|---|
| 1. 架构规划 | 划分 PS/PL/AIE 职责，确定接口、存储、启动方案 | 架构框图、资源预算、启动方案 | 架构评审通过 |
| 2. 设计与开发 | RTL、AIE 内核、PS 软件、约束与管脚 | 可综合工程、初版 PDI | 时序收敛、功能仿真通过 |
| 3. 系统集成 | 板级上电、启动链路打通、接口训练 | 可启动系统、接口训练报告 | 系统能稳定启动并通信 |
| 4. 产品化验证 | 电源/时钟/接口/功能/环境验证 | 验证报告、问题清单 | 所有验证项通过或风险受控 |
| 5. 交付与量产 | 镜像固化、测试脚本、文档整理 | 交付包、量产测试方案 | 交付评审通过 |
需要强调的是，阶段 3 和阶段 4 是问题最集中、也最容易被低估的部分。很多在仿真中"完全正确"的设计，会在真实板卡上因为电源斜率、时钟抖动、DDR 训练余量不足而暴露问题。因此，产品化验证必须建立在真实硬件和真实条件下，而不是仅依赖仿真。
五、交付物清单
为了让"交付"有明确边界，下面给出一份 Versal 项目常见的交付物清单。它既是最终交付的检查依据，也可以作为项目早期规划时的任务分解参考。
- 设计源与工程：Vivado 工程、Vitis 工程、AIE 工程、约束文件（XDC）、管脚分配、版本说明。
- 镜像与启动文件：PDI、BOOT.BIN、PLM 配置、启动介质烧录镜像及烧录说明。
- 验证脚本与自动化：上电测试脚本、接口训练脚本、误码率测试脚本、长时间运行脚本。
- 验证报告：电源时序测量报告、时钟测量报告、DDR/PCIe/以太网测试报告、功能与性能测试报告、环境测试报告。
- 问题与风险记录：问题清单、根因分析、解决措施、遗留风险及影响评估。
- 文档：系统架构说明、启动流程说明、测试操作手册、维护与故障排查指南。
- 量产相关：量产测试方案、测试限值、烧录流程、批次追溯信息。
六、本章小结与学习建议
本章建立了 Versal 产品化验证与工程交付的整体框架：Versal 是异构计算平台，PS、PL、AIE、NoC、DDR、启动链路和电源时钟共同构成一个必须整体验证的系统；产品化验证关注的是真实环境下的稳定性、可重复性和可量产性；工程交付则要求把验证过程和结果整理成可复现、可继承的成果。后续章节将围绕启动链路、电源时钟、DDR、高速接口、AIE 协同、环境可靠性、交付打包等主题逐一展开。
建议你在阅读后续内容时，始终带着三个问题：这一节验证的对象是什么？需要什么输入和条件？结果如何判断通过与否？把这三个问题回答清楚，产品化验证就不再是零散的操作，而是一条有逻辑、可复现的工程链路。