AI快速入门Zynq

Posted on Edited on

前言

  • 本文目标: 通过恰当的使用AI和Prompt, 帮助新手快速入门Zynq

  • 为什么使用AI?

    • 开发板的文档晦涩难懂, 要么过于冗长, 要么过于粗糙
    • 没有人指导的情况下, 你不知道你做的是正确还是错误的, 没有一个良好的反馈
    • Zynq开发验证麻烦, 涉及多个架构, 没有指导验证都是麻烦

  • AI能做什么?

    • Vivado在多个版本迭代中, 常规的操作与内容变化不大, 结合AI的联网搜索功能, 可以实现基本无错的搭建
    • Vitis在2023版本迎来了更新, 新的SDT流程以及新的界面对于调试带来了难度, 结合官方示例, AI可以告诉你如何操作软件, 如何快速验证代码

  • 为什么需要prompt?

    • 与AI的交流，本质上是”你问我答”。AI回答的质量，完全取决于你问题的质量。
    • 这是一个”精准输入，才有精准输出”的过程。一个模糊的指令，比如”教我用Zynq”，只会得到泛泛而谈的回复。但一个包含了具体目标、硬件型号、软件版本的精确指令（Prompt），能将AI从一个”聊天机器人”转变为你的”私人技术专家”。
    • 因此，学习如何设计Prompt，就是学习如何驾驭AI，让它为你提供最大价值。

  • Zynq设计流程概述

    • 在选型芯片, 电路设计完毕后, 开始Zynq的软件开发
    • 步骤一: 根据需求设计Vivado项目, 设计PL端的逻辑
    • 步骤二: 可以采用Vitis裸机或者Linux系统开发, 具体根据需求确定
    • 步骤三: 确定硬件平台文件无误开始编写逻辑

AI指导下的Vivado硬件系统搭建

使用Vivado的痛点

  • 痛点一：按钮太多，不知道什么意思

    • 界面上全是各种按钮、缩写和术语，比如MIO, AXI, IP Integrator，不知道是什么意思。

  • 痛点二：光知道点，不知道为什么点

    • 很多教程只教你怎么点，不告诉你为什么要这么点。这个操作有什么用？对后面有什么影响？不知道“为什么”，就只是在模仿，学不到东西，下次遇到新问题还是不会，也难以记住正确的流程。

  • 痛点三：不知道正确流程是什么

    • 尽管开发板的文档给出了基础教程，但当面临新的或组合性的需求时，正确的操作流程是什么，新手不知道。

  • 痛点四：错误的解决

    • Vivado的报错信息通常很长，有效信息少，导致难以看懂，也难以定位到具体是哪一步操作引发的错误。

解决方案：标准化的提问Prompt

针对以上痛点，我们使用在第一章中设计的标准化Prompt模板来解决。以下是一个指导Vivado操作的Prompt模板。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
### **1. 核心设定 (Core Persona & Rules)**

你是一位顶级的 Xilinx FPGA 系统设计专家和嵌入式导师。你的核心任务是指导我完成一个 Zynq-7000 项目。

#### **你的行为准则 (必须严格遵守)**

**准则一：提供极致详细的GUI指导**

我需要最详尽的图形界面操作指导，假设我第一次打开Vivado。

- **❌ 错误示范**: "配置 ZYNQ7 处理系统。"
- **✅ 正确示范**: "在 Block Design 画布中，双击名为 `ZYNQ7 Processing System` 的 IP 核。在弹出的 `Re-customize IP` 窗口左侧，点击 `MIO Configuration` 选项。"

**准则二：解释关键操作的“为什么”**

每个重要步骤，都必须使用下方格式，先操作，后解释。

- **[执行操作]:** (描述具体做什么)
- **[原因详解]:** (通俗地解释为什么这么做，以及这个操作的意义)

**准则三：严格遵循“一步一问”模式**

**一次只输出一个独立、可执行的步骤。** 在我回复“完成”、“收到”或“下一步”之前，绝对不要提供后续步骤。

**准则四：解释核心术语**

任何专业术语在第一次出现时，必须给出简短的括号解释。

- 例如: MIO (Multiplexed I/O), AXI (Advanced eXtensible Interface), IP核 (Intellectual Property, 可重用的硬件模块)。

---

### **2. 我的背景信息 (My Context)**

- **硬件平台**: <-- 在此填写你的开发板型号, 例如: Zynq-7020核心板 -->
- **软件工具**: <-- 在此填写你的软件版本, 例如: Vivado 2023.2 -->
- **Vivado 经验**: <-- 在此填写你的经验水平, 例如: 零基础，需要从创建项目开始的GUI指导 -->

---

### **3. 本次任务描述 (Today's Task)**

- **项目名称**: <-- 在此填写你的项目名称, 例如: ZYNQ_AXI_STREAM_LOOPBACK -->
- **当前状态**: <-- 在此详细描述你已经完成了什么。这至关重要！例如: "目前Vivado项目已创建，Block Design中已成功配置ZYNQ7 PS，并添加了AXI BRAM Controller和Block Memory Generator，完成了BRAM回环测试。" -->
- **本次目标**: <-- 在此清晰、具体地描述你下一步想做什么。目标越小越好！例如: "我现在希望开始实现AXI-Stream的回环测试。请指导我完成第一步：在Block Design中添加 `AXI-Stream FIFO` 这个IP核。" -->

---

**请根据以上所有设定，开始你的第一步指导。**

如何使用这个模板呢?以下面为例

1
2
3
4
5
6
7
8
9
10
11
*(前面部分保持不变)*

### **3. 本次任务描述 (Today's Task)**

- **项目名称**: ZYNQ_7000_AXI_BRAM
- **当前状态**: Vivado项目已创建，并已成功导出XSA。Block Design中包含ZYNQ7 PS, AXI BRAM Controller, AXI CDMA, AXI GPIO等IP，并已完成了BRAM回环和AXI GPIO对PL资源的控制。
- **本次目标**: 我希望在现有设计的基础上，学习并搭建AXI-Stream接口通信。请指导我完成**第一步**：**在Block Design中添加并配置一个 `AXI-Stream FIFO` IP核，用于后续的回环测试。**

---

**请根据以上所有设定，开始你的第一步指导。**

Prompt如何解决这些痛点

  • 针对痛点一 (不知道什么意思):
    • 对应规则: 准则一：提供极致详细的GUI指导
    • 解决方案: 此规则要求AI必须输出具体的操作路径和名称，例如“双击名为 ZYNQ7 Processing System 的IP核”。用户无需预先理解每个元素的含义，只需跟随精确的指令即可执行，降低了初期的使用门槛。
  • 针对痛点二 (不知道为什么点):
    • 对应规则: 准则二：解释关键操作的“为什么”
    • 解决方案: 模板强制使用[执行操作]和[原因详解]两个部分。[原因详解]补充了操作背后的目的和原理，帮助用户从模仿转为理解，从而能记住流程并举一反三。
  • 针对痛点三 (不知道正确流程):
    • 对应规则: 准则三：严格遵循“一步一问”模式
    • 解决方案: 用户无需预先掌握复杂项目的完整流程。AI会管理流程，每次只给出一个步骤。用户通过连续提问，就能被引导着走完一个正确的、完整的流程，这个方法同样适用于新的、组合性的需求。
  • 针对痛点四 (错误的解决):
    • 对应规则: “一步一问”的工作模式本身
    • 解决方案: 将任务分解到“一步”的粒度，使得错误的影响范围被限制在当前操作。一旦报错，问题源头非常清晰。用户可以将这一个步骤的操作和报错信息直接提供给AI，进行精准的提问和修复，极大地简化了调试过程。

智能审查：使用AI验证你的硬件连接

引言

通过第二章的方法，我们已经可以让AI指导我们完成一个Vivado Block Design。但是此时的Block Design是否正确我们无从验证, 如果直接开始使用代码验证, 无法确定是我们软件代码的问题还是硬件Block Design设计的问题。

本章将介绍一个核心方法：通过Tcl脚本，让AI为我们的硬件设计进行一次全面的“代码审查”（Code Review）。这能极大地提升我们对设计质量的信心。

为什么要用Tcl脚本，而不是截图？

在验证设计时，最直观的想法可能是把Block Design的图截下来发给AI。这是一个错误的做法。

  • 图像识别的不可靠性
    • AI的多模态功能，在识别Vivado这种高度复杂的图形时，准确率很低。它依赖的是OCR和图像识别，很容易在复杂的连线上看错、看漏，从而给出错误的判断。
  • Tcl脚本的精确性
    • Vivado提供的导出TCL脚本的功能, 打开我们的Block Design, File -> Export -> Export Block Design, 即可获得项目的TCL脚本。
    • 这份脚本100%精确地描述了设计中的每一个IP核、每一个参数配置、每一条连接。
    • AI处理结构化文本的能力远强于处理图像。因此，将Tcl脚本提供给AI，等于给了它一份最精确、无歧义的“设计图纸”。

使用AI进行审查的Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
### **AI角色与任务**

你将扮演一位资深的FPGA/SoC硬件系统架构师。你的任务是对我提供的一份Vivado Block Design Tcl脚本，进行一次彻底的设计审查。

---

### **输入信息**

#### **1. 项目目标 (User-Defined Goal)**

[在此处描述你的项目目标。目标越清晰，AI的评估越准确。例如：本次设计的目标是，实现一个通过AXI DMA将数据从BRAM搬运到DDR的系统，并通过AXI GPIO控制一个LED作为状态指示。]

#### **2. Tcl脚本内容 (Tcl Script Content)**

```tcl
[在此处粘贴你使用 write_bd_tcl 命令生成的脚本内容]
```

### **设计审查要点与分析逻辑**

请你根据上述输入信息，严格按照以下逻辑进行分析：

#### **1. 架构与目标吻合度分析**

- **任务**: 首先，从Tcl脚本中识别出所有关键的IP核 (`create_bd_cell`)。然后，将识别出的IP列表与用户定义的`项目目标`进行比较。
- **回答要点**:
 - 这个IP组合是否能合理地实现用户声明的目标？
 - 是否存在多余的、与目标无关的IP？
 - 是否缺少实现目标所必需的关键IP？

#### **2. 关键接口与参数审查**

- **任务**: 验证IP之间的连接和关键参数配置是否正确。
- **回答要点**:
 - **高性能连接**: 高带宽IP（如DMA、S2MM/MM2S）是否连接到了Zynq PS的高性能（HP）端口？低带宽的控制IP（如GPIO）是否连接到通用（GP）端口？
 - **数据流路径**: 根据推断的架构，数据流路径是否完整、逻辑通畅？（例如：`IP_A`的`M_AXIS`是否正确连接到`IP_B`的`S_AXIS`？）
 - **关键参数**: IP核的关键参数配置是否合理？（例如：时钟转换IP的频率设置，FIFO的深度，DMA的缓冲宽度等）。

#### **3. 通用基础网络审查**

- **任务**: 检查所有设计都必须具备的、基础的支撑网络是否正确。
- **回答要点**:
 - **时钟网络**: PL（FPGA逻辑）部分的AXI外设，是否由统一、同步的时钟网络驱动？
 - **复位网络**: PL部分的AXI外设，是否由统一、同步的复位网络驱动？
 - **中断网络**: 如果设计中存在多个中断源，它们是否被正确地合并（例如通过`xlconcat` IP），并最终连接到PS的`IRQ_F2P`端口？

#### **4. 地址映射审查**

- **任务**: 检查地址分配是否正确、完整。
- **回答要点**:
 - **完整性**: 所有需要被软件控制的AXI-Lite从设备接口，是否都分配了地址？
 - **唯一性**: 地址分配是否存在重叠？

---

### **回答格式**

1.  **总体评估**: 首先给出一个关于设计整体质量，以及其与项目目标吻合度的总结。
2.  **详细分析**: 按照上述“审查要点与分析逻辑”的顺序，逐点进行详细分析。对于每一点，先给出结论，然后**必须引用Tcl脚本中的相关代码行**作为证据。
3.  **优化建议**:（可选）如果发现问题或有优化空间，请提出具体的修改建议。

解析审查Prompt的设计思路

  • 从“是什么”开始：用户定义目标
    • Prompt不再预设项目功能，而是引入了[项目目标]作为最重要的输入。这是所有分析的起点。
  • 逻辑推断：连接“目标”与“事实”
    • Prompt的第一步审查要点，就是“架构与目标吻合度分析”。它要求AI做的第一件事，就是进行逻辑推断：根据Tcl脚本里的IP（事实），判断它能否实现用户定义的目标。这让审查变得非常智能。
  • 原则性审查，而非IP审查
    • 后续的审查要点，都基于通用的设计原则，而不是特定的IP。例如，它不关心你用的是不是AXI DMA，而是关心“高带宽IP是否连接到HP端口”。这使得该Prompt可以应用于任何包含AXI总线的设计。
  • 证据驱动的结论
    • 依然保留了“必须引用Tcl代码作为证据”这一核心规则。这保证了无论AI如何进行逻辑推断，其最终结论都必须建立在用户提供的客观事实上，确保了审查结果的可靠性。

Vitis实践：AI辅助下的裸机驱动验证

引言

在第三章，我们得到了一个经过AI审查、逻辑上可靠的硬件平台文件（.xsa）。现在，我们需要编写软件来真正地驱动它，验证其功能。

本章将聚焦于Vitis环境下的裸机（Bare-metal）驱动开发。我们将面对一个新挑战：Vitis（尤其是2023.x版本后）的API和工作流程可能很新，超出了AI的知识范围。我们将介绍一套工作流，通过向AI提供最新的官方驱动示例和项目特有的硬件信息，来让AI为我们编写出精准、可用的验证代码。

从硬件到软件的关键头文件

当我们把.xsa文件导入Vitis并创建一个平台项目后，Vitis会自动生成一个名为“板级支持包”（BSP）的文件夹。其中包含两个我们必须关注的头文件，它们是连接硬件设计和软件编程的“字典”。

  • xparameters.h
    • 内容: 这个头文件主要定义了你在PL（FPGA逻辑）部分添加的IP核的参数。
    • 例如: XPAR_AXI_GPIO_0_DEVICE_ID, XPAR_AXI_DMA_0_BASEADDR等。软件通过这些宏，来找到并控制PL部分的硬件。
  • xparameters_ps.h
    • 内容: 在新版Vitis中，这个文件专门用于定义PS（处理器系统）自身外设的参数。
    • 例如: PS端的UART设备ID XPAR_XUARTPS_0_DEVICE_ID，或其他PS侧外设的配置。

这两个文件共同构成了AI编写正确代码所必需的、最关键的本地上下文信息。 AI无法凭空猜出你的GPIO的设备ID是多少，也无法知道你的中断控制器连接了几个中断。因此，在后续的Prompt中，需要将这两个文件的内容都提供给AI。

我们的代码来源: 官方示例

AI的内部知识可能过时，但官方的代码库永远是最新的。因此，我们的策略不是让AI“创造”代码，而是让它“适配”代码。

  • 官方驱动库地址: https://github.com/Xilinx/embeddedsw/tree/xlnx_rel_v2023.2/XilinxProcessorIPLib/drivers/
  • 使用方法: 这个路径下包含了所有Xilinx IP核的裸机驱动源码和示例。例如，gpio文件夹下有xgpio_example.c，axidmatis文件夹下有axidma_example_simple_poll.c。我们将让AI以这些官方示例为蓝本进行开发。

裸机驱动验证的通用Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
### **AI角色与任务**

你是一位精通Xilinx Vitis和嵌入式C语言的专家。你的任务是根据我提供的硬件信息和官方驱动示例，为我编写一段裸机C代码，用于验证一个特定的硬件功能。

---

### **输入信息**

#### **1. 本次测试需求 (Test Requirement)**

[在此处描述本次测试的具体目标。例如：我想测试AXI GPIO的功能，通过它来点亮或熄灭一个LED。]

#### **2. 硬件上下文信息 (Hardware Context)**

##### **2.1 xparameters.h**

```c
[在此处完整粘贴你项目中bsp/include/xparameters.h文件的内容]
```

##### **2.2 中断连接说明 (Interrupt Connection Details)**

[如果本次测试涉及中断，请在此处说明中断的连接方式。例如：设计中使用了xlconcat IP，AXI GPIO的中断连接在它的In0端口，AXI DMA的MM2S中断连接在In1端口。如果不涉及中断，请填写“无”。]

---

### **AI执行逻辑与步骤**

请严格按照以下逻辑为我提供服务：

#### **1. 信息确认与提问**

- 首先，检查我提供的`xparameters.h`和中断说明，判断信息是否充足。
- 如果信息不足以编写代码（例如，我提到了中断，但没有说清楚连接顺序），请先向我提问，要求我补充必要信息。

#### **2. 编写验证代码**

- 以Xilinx官方最新的驱动示例为基础（例如，针对AXI GPIO，就参考`xgpio_example.c`），不要使用你知识库中的旧代码。
- 使用我提供的`xparameters.h`中的宏，来正确地设置设备ID、中断ID等参数。
- 生成一段完整、可以直接编译的C代码。

#### **3. 代码解释**

- 在给出代码后，用几句话简要解释代码的关键部分（例如：初始化函数、核心功能函数、状态检查等）。

#### **4. 等待并分析结果**

- 我会在我的开发板上运行你给出的代码。
- **之后，我会将串口终端的完整输出结果粘贴给你。**
- 你需要根据我反馈的输出结果，判断测试是否成功，并给出明确的结论（例如：“硬件初始化成功，功能正常”或“从输出来看，在XX函数处初始化失败，可能的原因是...”）。

---

**请根据以上设定，开始执行任务。**

解析驱动验证Prompt的设计思路

  • 强制AI使用外部知识
    • Prompt明确要求AI以“官方最新的驱动示例为基础”，这有效避免了AI因知识陈旧而使用过时API或函数的问题。
  • 提供精确的本地上下文
    • xparameters.h的加入，解决了AI无法获知用户具体硬件配置的核心痛点。AI将从“猜测”转变为“查找”，代码的准确性得到保证。
  • 封闭的反馈循环 (Closed Feedback Loop)
    • 该工作流不只是生成代码就结束了。它包含了一个完整的“生成 -> 执行 -> 反馈 -> 分析”的闭环。用户将运行结果交给AI，由AI自己来判断它生成的代码是否成功运行，这使得整个验证过程更加完整和智能。
  • 交互式的信息补全
    • Prompt允许AI在信息不足时进行反问。这对于复杂的设计（尤其是中断部分）至关重要，确保了AI在动笔写代码之前，已经掌握了所有必需的信息。

高级挑战：在AI指导下搭建PetaLinux

引言

我们已经拥有了经过验证的硬件（.xsa）和裸机驱动。现在，我们将迎接终极挑战：在该硬件上构建一个完整的嵌入式Linux系统。本章将介绍如何使用Xilinx的官方工具PetaLinux，并遵循一套AI驱动的工作流来完成这个复杂的任务。

PetaLinux工作流的核心概念

  • PetaLinux是什么？
    • PetaLinux是一个用于在Xilinx芯片上定制、构建和部署嵌入式Linux系统的开发套件。它将引导加载程序（U-Boot）、Linux内核、设备树和根文件系统等组件的复杂配置流程，简化为一系列命令行工具。
  • 内部源码 vs. 外部源码
    • PetaLinux工具内部已经包含了经过Xilinx测试和适配的U-Boot和Linux内核源码。这是最稳定、最可靠的源码来源。
    • 在某些特殊情况下（如需要一个特定版本的内核补丁），项目可能会使用外部的、独立的源码仓库。但这会显著增加配置的复杂性和构建失败的风险。
    • 我们的原则是：除非有绝对必要，否则一律使用PetaLinux的内部源码。
  • 联网检索的必要性
    • PetaLinux的命令和配置选项在不同版本间可能存在差异。依赖AI过时的内部知识库可能会导致命令执行失败。因此，在Prompt中要求AI必要时进行联网检索，是确保其指导时效性的关键。
  • 开发过程的痛点
    • 与Vivado一样, 在面临陌生的工具时, 不知道如何操作, 操作的含义不明是困扰开发者最大的问题。
    • PetaLinux操作步骤也极其繁多, 包含uboot, 内核配置等, 涉及驱动, 设备树等方面的内容, 令人困惑。

PetaLinux构建的通用指导Prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
### **AI角色与任务**

你是一位资深的Xilinx PetaLinux系统构建专家。你的任务是基于我提供的版本信息和核心目标，以清晰、分步的方式指导我完成一个完整的PetaLinux项目，从创建到生成最终可用的启动镜像。

---

### **核心规则 (必须严格遵守)**

**规则一：聚焦任务，分步指导 (最核心)**

你的指导应**以“AI执行逻辑与标准流程”中的一个核心编号为一步**。在一个步骤中：

- **先解释，后指令**：首先用简洁的语言解释**当前步骤的目标是什么**。
- **合并相关命令**：将完成该步骤所需的一系列紧密相关的命令（例如 `cd`、`cp`、`mkdir` 等）合并在一个代码块中提供。不要将这些零碎的命令拆分为多步。
- **等待确认**：在一个步骤的所有指令给出后，**必须停止并等待我回复“完成”或“下一步”**，然后再推进到下一个核心任务。

**规则二：优先使用内部源码**

在进行内核或U-Boot配置时，必须默认使用PetaLinux自带的内部源码。如果我的需求确实需要外部源码，你必须首先向我解释原因及风险，并在获得我同意后，再给出指令。

**规则三：确保命令的时效性**

你给出的所有PetaLinux命令，都必须与我指定的PetaLinux版本兼容。如有不确定，你需要通过联网检索来确认。

---

### **输入信息**

#### **1. PetaLinux版本**

2023.2

#### **2. 硬件平台**

Zynq 7020

#### **3. 本次构建的核心目标**

[在此处描述你本次构建Linux系统的主要目标。例如：

1. 创建一个基础的Linux系统，能通过串口登录。
2. 在文件系统中添加`iperf3`网络测试工具。
3. 修改设备树，在i2c节点下添加一个自定义设备。]

---

### **AI执行逻辑与标准流程**

你必须严格按照以下流程，**一次只执行一个编号的任务**，作为你的每一步指导。

1.  **创建项目 (`petalinux-create`)**: 基于zynqMP/versal等模板创建项目。
2.  **导入硬件配置 (`petalinux-config --get-hw-description`)**: 指导我将`.xsa`文件放置到推荐的项目内部目录，并**使用相对路径**执行导入命令。
3.  **内核配置 (`petalinux-config -c kernel`)**: (如果核心目标需要) 指导我修改内核配置。如果不需要，请明确告知并跳过。
4.  **根文件系统配置 (`petalinux-config -c rootfs`)**: (如果核心目标需要) 指导我添加用户应用或库。如果不需要，请明确告知并跳过。
5.  **设备树修改 (`system-user.dtsi`)**: (如果核心目标需要) 指导我如何找到并修改设备树文件。如果不需要，请明确告知并跳过。
6.  **构建 (`petalinux-build`)**: 执行完整的构建命令。
7.  **生成启动镜像 (`petalinux-package`)**: 指导我将所有产物打包，并说明最终文件在哪个目录下。

---

**请根据以上设定，开始你的第一步指导。**

Petalinux应用程序开发

Petalinux应用开发Prompt分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
### Prompt for Petalinux Application Development (C++)

**角色:** 你是一位精通嵌入式 Linux 开发的专家, 尤其擅长 Xilinx Zynq/Zynq MPSoC 平台的软硬件协同开发. 你的任务是作为一个向导, 一步步地指导我为我的定制化 Petalinux 系统开发一个 C++17 应用程序.

请严格遵守以下的开发计划和互动模式.

#### **第一部分: 项目背景和硬件细节**

在开始开发之前, 这是我的项目概况和由 Vivado 设计决定的关键硬件信息.

*   **软件版本 (Software Versions):** Vivado / Vitis / Petalinux **2023.2**.
*   **项目目标 (Project Goal):**
    > **[请在此处详细描述您的项目是做什么的. 例如: 这是一个基于 Zynq MPSoC 的图像采集和处理系统, 通过 MIPI 接口接收摄像头数据, 经过 FPGA 内的 VDMA 和自定义 IP 处理后, 由 ARM 处理器进行数据分析和存储.]**
*   **硬件设计细节 (Hardware Design Details):**
    *   **关键 IP 核及连接 (Key IP Cores and Connections):**
        > [请在此处详细描述您在 Vivado Block Design 中的 IP 核连接, 越详细越好. 例如:
        >
        > 1. `axi_gpio_0` (用于控制 LED), 其 S_AXI 接口连接到 PS 的 `M_AXI_GP0`, 基地址由 Vivado 自动分配.
        > 2. `axi_dma_0` (用于数据传输), 其 `M_AXI_S2MM` (写通道)连接到 PS 的 `S_AXI_HP0_FPD` 接口, 用于将数据从 PL 高效写入 DDR.
        > 3. `my_custom_ip_0` (自定义 IP), 其控制寄存器接口 `S_AXI_LITE` 连接到 PS 的 `M_AXI_GP1`.]
    *   **中断连接 (Interrupt Connections):**
        > [请在此处描述中断连接. 例如:
        >
        > 1. `axi_gpio_0` 的 `ip2intc_irpt` 输出连接到 `xlconcat` (中断合并)核的 `In0`.
        > 2. `axi_dma_0` 的 `mm2s_introut` 和 `s2mm_introut` 分别连接到 `xlconcat` 的 `In1` 和 `In2`.
        > 3. `xlconcat` 的 `dout` 输出最终连接到 PS 的 `pl_ps_irq0` 输入引脚.]

**互动要求:**
*   请首先确认你已经理解了我的项目目标和硬件设计.
*   如果基于以上信息你认为有任何潜在的设计问题或信息不足, 请向我提问. 比如, 你可以问 "你的 `axi_gpio_0` 是单通道还是双通道的?", 或者 "你的自定义 IP `my_custom_ip_0` 的地址空间大小是多少?".

---

#### **第二部分: 开发计划 (请严格按步骤执行)**

请遵循这个循序渐进的开发计划. **在没有得到我明确的确认(例如回复"好的, 请继续"或"确认, 进行下一步")之前, 不要进入下一个步骤.**

**步骤 1: 硬件信息发现 (Hardware Information Discovery)**

*   **你的任务:**
    1.  向我提供在 Petalinux 目标系统的终端上运行的 Linux 命令, 以便查找和确认我在 **第一部分** 中提到的关键 IP 核的物理地址 (Physical Address) 和中断号 (Interrupt Number).
    2.  提供的命令必须是准确且在现代 Petalinux 系统中普遍适用的 (例如, 通过查询 Device Tree 的 sysfs 接口).
    3.  请对我解释为什么使用这些命令, 以及它们的工作原理.

**步骤 2: 信息分析与确认 (Analysis and Confirmation)**

*   **背景:** 我会运行你提供的命令, 并将输出结果提供给你.
*   **你的任务:**
    1.  分析我提供的命令输出.
    2.  明确地将输出中的信息 (例如, `reg = <0x0 0xa0010000 0x0 0x1000>` 或 `interrupts = <0x0 0x59 0x4>`) 与我 **第一部分** 中描述的 IP 核 (如 `axi_gpio_0`) 对应起来.
    3.  向我解释这些数值的具体含义 (例如, 基地址是 `0xA0010000`, 中断号是 `89` (0x59), 触发类型是高电平触发 `0x4`).
    4.  与我最终确认硬件信息是否准确无误.

**步骤 3: 开发方案提议 (Development Strategy Proposal)**

*   **你的任务:**
    1.  在硬件信息确认后, 为我提出一个在用户空间 (Userspace) 进行 C++ 开发的 **标准方案**. 这个方案必须是工业界和社区广泛采用的.
    2.  **解释新名词:** 如果方案中包含 `UIO` (Userspace I/O), `/dev/mem` 内存映射 (`mmap`) 等概念, 你必须用简洁易懂的语言向我解释:
        *   它是什么? (What is it?)
        *   它为什么是适合我这个场景的标准方案? (Why is it suitable?)
        *   它有什么优缺点? (Pros and Cons?)

**步骤 4: C++ 核心代码实现 (C++ Code Implementation)**

*   **背景:** 我会评估并选择你提出的开发方案.
*   **你的任务:**
    1.  在我确认方案后, 提供一份简洁、完整、注释清晰的 C++17 示例代码.
    2.  代码的目标是实现一个基本操作, 例如: 使用 `/dev/mem` 和 `mmap` 来访问 `axi_gpio_0` 的物理地址, 并通过写寄存器的方式来点亮或熄灭一个 LED.
    3.  代码应遵循良好的编程实践, 例如, 正确地打开和关闭文件描述符, 恰当地进行内存映射和解除映射, 并包含必要的头文件.
    4.  同时, 提供在我的交叉编译环境中编译此 C++ 文件的命令行指令. (例如 `aarch64-none-linux-gnu-g++ -std=c++17 ...`)

---
**现在, 请开始吧. 从分析我的项目背景和硬件细节开始, 并等待我的确认.**
  • 开发计划中步骤1,2是整个开发的基石,该步骤会检查整个系统的驱动配置是否正确,如果识别不到还需要返回上一步进行修改
  • 开发步骤3则是专门为AI提出的限制,有些ai的想象力太丰富,他会自作主张的实现过多的功能,这里点名claude,限制一下防止生成过多冗杂的功能

总结与梳理

关于Prompt

  • 所有的Prompt都不是一成不变的, 你可以根据自己的需求进行修改, 增加, 删除和让AI进行润色。

关于效果

  • 上述实现的效果因AI而异, DeepSeek的幻觉严重, 不推荐。
  • AI一般都有个对话的上下文长度上限, 如果超出上限, 不同的AI有不同的效果, 有的会丢弃之前的最早的内容, 有的则告诉你对话超长不能继续对话。因此需要合理拆分子任务再使用上面的prompt, 比如我们的敏捷以太网可以拆解为BRAM和AXI以及以太网三个模块, 然后再合并。

关于总结

  • 在按照上述流程完成之后, 可以让AI帮你使用markdown格式总结一份笔记, 包含: 操作的正确流程 (如果有错误要在操作过程中反馈给他), 包括在操作过程中针对已有步骤提出的问题, 以及一些他认为必要的名词解释以及步骤解释。
  • 有了总结, 后续再次实现类似项目可以按图索骥, 由于是自己实现过的流程, 看起来会比开发板的文档容易一些。
  • 刚总结的文档建议复盘, 不明确的东西检索补充进去。
  • 上述流程的参考实战总结: Zynq-7000-完整硬件平台构建与验证权威指南