Dense Classification Layer Graph 技术深度解析

一句话概括

dense_classification_layer_graph 是 MNIST 卷积神经网络中的全连接分类层的 AIE-ML 图实现。它接收展平后的特征向量，通过可学习的权重矩阵进行线性变换，输出 10 个类别的 logits，完成手写数字识别的最终分类决策。

1. 问题背景与设计动机

1.1 神经网络中的"分类决策层"

想象你正在看一幅手写数字图片。前面的卷积层和池化层就像是"视觉皮层"，负责提取边缘、曲线、纹理等特征。但这些特征本身还不能告诉我们"这是数字几"。

全连接层（Dense Layer） 就像是"决策中枢"——它将所有提取到的特征综合起来，学习它们与最终类别之间的复杂映射关系。对于 MNIST，它输出 10 个数值（logits），表示输入图像是每个数字的概率基础。

1.2 为什么需要专门的 AIE-ML 实现？

在 Versal AIE-ML 架构上，这个看似简单的矩阵-向量乘法面临独特挑战：

1.3 核心设计洞察：图封装与 PLIO 抽象

dense_classification_layer_graph 的核心设计思想是分层抽象：

┌─────────────────────────────────────────┐
│        dut_graph (顶层封装)              │  ← 负责系统级集成：PLIO、仿真数据文件
│  ┌─────────────────────────────────┐   │
│  │   dense_w7_graph (计算图核心)    │   │  ← 负责 AIE tile 编排、核间通信
│  │  ┌─────┐ ┌─────┐ ┌─────┐       │   │
│  │  │AIE 0│←→│AIE 1│←→│AIE 2│ ... │   │  ← 实际执行 MAC 计算的 AIE-ML 核
│  │  └─────┘ └─────┘ └─────┘       │   │
│  └─────────────────────────────────┘   │
└─────────────────────────────────────────┘

这种分层让计算逻辑（dense_w7_graph）与系统集成（dut_graph）解耦——前者专注于 AIE 核的并行算法设计，后者处理 PL/PS 接口、数据文件、仿真配置。

2. 架构与数据流详解

2.1 架构图

2.2 组件职责详解

2.2.1 dut_graph —— 系统集成层

class dut_graph : public graph {
public:
  dense_w7_graph dut;      // 计算核心：封装实际的 AIE 计算逻辑
  input_plio   ifm_i;      // 输入特征图端口：PL → AIE 数据通道
  input_plio   wts_i;      // 权重输入端口：PL → AIE 参数加载
  output_plio  ofm_o;      // 输出分类结果：AIE → PL 数据通道
  
  dut_graph(void) { ... } // 构造函数：完成所有连接配置
};

设计意图：dut_graph 是 AIE 设计中的顶层图（Top-Level Graph），它的唯一职责是将计算核心与系统接口粘合。它继承自 graph 基类，这是 Vitis AIE 运行时对所有图容器的统一抽象。

关键决策：为什么不把 PLIO 定义放在 dense_w7_graph 内部？因为 dense_w7_graph 可能被多个不同的系统集成方式复用（例如，一次是仿真环境用文件输入，另一次是真实系统用 DMA 引擎）。将 PLIO 提升到 dut_graph 层实现了计算与 I/O 的解耦。

2.2.2 PLIO 端口配置 —— 数据宽度与文件绑定

// PLIO 端口创建：64-bit 宽度，绑定仿真数据文件
ifm_i = input_plio::create("PLIO_i", plio_64_bits, "data/ifm_i.txt");
wts_i = input_plio::create("PLIO_w", plio_64_bits, "data/wts_i.txt");
ofm_o = output_plio::create("PLIO_o", plio_64_bits, "data/ofm_o.txt");

plio_64_bits 的选择依据：AIE-ML tile 的 AXI4-Stream 接口通常以 32-bit 或 64-bit 宽度运行。64-bit 选择意味着每个时钟周期可以传输 8 字节数据，这对于密集的 MAC 计算是必要的——如果数据供给带宽不足，AIE 核将处于饥饿状态（starvation），MAC 阵列利用率骤降。

文件路径的约定：data/ifm_i.txt 等路径是相对于仿真工作目录的相对路径。在 AIE 仿真器（aiesimulator 或 x86simulator）中，这些文件被读取/写入以模拟 PL 侧的 DMA 行为。格式通常是每行一个十六进制数值，表示一个 AXI 传输 beat。

2.2.3 图连接（Connectivity）—— 数据流编排

// 数据流连接：建立 PLIO 与计算核心之间的通路
connect<>(wts_i.out[0], dut.wts_i);   // 权重流：PL → AIE 计算图
connect<>(ifm_i.out[0], dut.ifm_i);   // 特征图流：PL → AIE 计算图  
connect<>(dut.ofm_o, ofm_o.in[0]);   // 结果流：AIE 计算图 → PL

connect<> 模板的工作机制：这是 Vitis AIE 库提供的编译期连接原语。它接受两个端口引用（out[0] 和 wts_i 等），在编译时生成底层的 AXI4-Stream 电路描述。这些连接最终映射到 AIE 阵列的级联流（Cascade Stream）或DMA 通道。

端口索引 [0] 的语义：AIE 核和 PLIO 都可以有多个输出/输入端口（例如，一个核可能同时输出结果和旁路数据）。[0] 表示选择主数据流端口。在 dense_w7_graph 内部，这些端口（wts_i, ifm_i, ofm_o）被定义为 input_port 和 output_port 类型。

数据流方向的可视化：

外部存储/PL                    AIE-ML 阵列
    │                              │
    ▼                              ▼
┌─────────┐     ┌──────────┐     ┌─────────┐
│ifm_i.txt│────▶│ input_plio│────▶│         │
│(特征图)  │     │ ifm_i    │     │ dense_  │
└─────────┘     └──────────┘     │ w7_graph│──▶ 分类结果
┌─────────┐     ┌──────────┐     │         │
│wts_i.txt│────▶│ input_plio│────▶│         │
│(权重)    │     │ wts_i    │     └─────────┘
└─────────┘     └──────────┘

2.3 运行时控制流 —— PS 侧的主程序

// 全局图实例化
dut_graph aie_dut;

int main(void) {
  aie_dut.init();        // 阶段 1: 初始化 AIE 阵列
  aie_dut.run(1);        // 阶段 2: 运行 1 次迭代 (处理 4 张图片)
  aie_dut.end();         // 阶段 3: 清理与结束
  return 0;
}

三阶段生命周期模型：

run(1) 的参数语义：参数 1 表示迭代次数。在 MNIST 设计中，一次迭代处理 4 张图片（这是由 dense_w7_graph 内部的数据并行度决定的）。因此 run(1) 实际上处理 4 张测试图片的分类。

全局实例化 dut_graph aie_dut：这是 Vitis AIE 运行时的必需模式——图实例必须在全局命名空间定义，以便链接器能正确生成 AIE 配置数据结构和 ELF 加载镜像。不能将图实例放在局部作用域。

3. 设计决策与权衡分析

3.1 为什么使用 PLIO 而非 GMIO？

Vitis AIE 提供两种主要的 PS ↔ AIE 数据通道：

本模块选择 PLIO 的原因：

1. 仿真友好：MNIST 教程的核心目的是演示 AIE 图设计和验证流程。PLIO 允许直接绑定文本文件（ifm_i.txt, wts_i.txt）作为数据源/接收器，无需编写复杂的 PS 主机代码来管理内存缓冲。

2. 延迟敏感：全连接层的计算量相对较小（矩阵-向量乘），如果数据通路延迟过高，DMA 开销将主导执行时间。PLIO 的直连特性最小化了这一开销。

3. 教学清晰：分离 dut_graph（PLIO 层）和 dense_w7_graph（计算核心）让学习者能清晰看到系统集成与算法实现的边界。

3.2 端口连接的"硬编码" vs 配置化

观察 dut_graph 的构造函数：

connect<>(wts_i.out[0],  dut.wts_i);
connect<>(ifm_i.out[0], dut.ifm_i);
connect<>(dut.ofm_o,    ofm_o.in[0]);

这些连接是编译期静态确定的。与之对比的替代方案是运行时配置：

// 假设的可配置版本（非实际代码）
dut_graph(const std::string& ifm_file, const std::string& wts_file) {
    ifm_i = input_plio::create("PLIO_i", plio_64_bits, ifm_file);
    // ...
}

选择静态连接的原因：

1. AIE 编译器约束：AIE 数据流图的路由需要在编译时完全解析，以生成正确的 AXI-Stream 开关配置和 DMA 描述符。动态端口连接在技术上无法实现——AIE 阵列的硬件路由是静态烧录的。

2. 性能确定性：静态连接允许编译器进行全程序优化（dead code elimination、流水线排布），确保每次运行的时序行为一致。这对于实时推理至关重要。

3. 复杂性管理：MNIST 教程的目标是展示可预测的设计模式。将文件路径等配置硬编码虽然牺牲了灵活性，但确保了学习者能直接运行而无需理解额外的配置机制。

权衡的代价：这种设计使得 dut_graph 难以在不重新编译的情况下适应不同场景（例如，不同的输入数据大小或不同的权重文件）。在实际生产代码中，你可能会引入一个配置头文件（config.h）来集中这些常量，而不是直接硬编码在构造函数中。

3.3 单图实例 vs 多图实例

代码中使用全局单例模式：

dut_graph aie_dut;  // 全局唯一实例

int main() {
    aie_dut.init();
    // ...
}

为什么不是局部实例或多实例？

1. 链接器契约：Vitis AIE 工具链在链接时需要识别所有图实例以生成统一的 AIE 配置数据库（.aieconfig）。全局实例确保了链接器能在 ELF 生成阶段正确解析图拓扑。

2. 资源独占性：AIE-ML 阵列的 tile 和互连资源是分区独占的。两个 dut_graph 实例会尝试映射到相同的 tile 坐标，导致资源冲突。多图设计需要显式的**图组合（Graph Composition）**机制，这是 Vitis AIE 的高级特性，超出本教程范围。

3. 生命周期管理：全局实例的生命周期跨越整个程序执行，与 AIE 阵列的硬件上电/下电周期对齐。局部实例的构造/析构时序会与 AIE 驱动初始化/清理产生竞态。

4. 关键实现细节分析

4.1 plio_64_bits 的带宽含义

ifm_i = input_plio::create("PLIO_i", plio_64_bits, "data/ifm_i.txt");

64-bit 宽度的物理意义：

• AIE-ML 阵列与 PL 的接口通过 AXI4-Stream 协议连接
• 64-bit 表示每个时钟周期传输 64 位（8 字节）数据
• 假设 AIE 时钟为 1 GHz，该接口的理论带宽为：

为什么不是 32-bit 或 128-bit？

• 32-bit：对于密集计算，带宽可能成为瓶颈。64-bit 提供了 2 倍带宽裕量。
• 128-bit：虽然带宽更高，但会增加 PL 侧的逻辑资源消耗（更宽的 FIFO、更大的跨时钟域同步器）。64-bit 是带宽与资源开销的平衡点。

4.2 文件 I/O 的仿真语义

"data/ifm_i.txt"  // 输入特征图数据文件
"data/wts_i.txt"  // 权重数据文件  
"data/ofm_o.txt"  // 输出结果数据文件

这些文件在仿真中的作用：

在 aiesimulator 或 x86simulator 中运行时：

1. 输入文件：仿真器逐行读取 .txt 文件中的十六进制数值，将其转换为 AXI4-Stream 事务，驱动 input_plio。

2. 输出文件：output_plio 接收的 AXI4-Stream 事务被转换为十六进制文本，写入 .txt 文件，供后续验证。

文件格式示例：

# ifm_i.txt - 每行一个 64-bit 十六进制值
0x0001020304050607
0x08090A0B0C0D0E0F
...

生产环境的不同：在真实硬件上，这些 PLIO 将连接到实际的 PL DMA 引擎，而不是文件。dense_w7_graph 内部的计算逻辑保持不变，只有 dut_graph 的连接目标会改变。

4.3 迭代次数与批处理语义

aie_dut.run(1);  // 运行 1 次迭代

"1 次迭代 = 4 张图片" 的含义：

这不是 AIE 运行时的通用语义，而是 dense_w7_graph 内部设计的数据并行度。具体来说：

• dense_w7_graph 将 AIE-ML tile 组织成长度为 4 的流水线或并行阵列
• 每个处理单元同时处理 1 张图片的特征向量
• 因此一个完整的"迭代"产生 4 张图片的分类结果

为什么这样设计？

AIE-ML tile 的 MAC 阵列需要持续的饱和数据流才能达到标称算力。单张图片的矩阵-向量乘法数据量太小，容易导致流水线气泡（pipeline bubble）。通过同时处理 4 张图片：

• 数据级并行度提升 4 倍
• 每个时钟周期有更多独立数据元素被处理
• MAC 阵列利用率接近理论峰值

5. 依赖关系与系统集成

5.1 上游依赖（本模块调用）

5.2 下游依赖（调用本模块）

5.3 数据流完整路径

┌─────────────────────────────────────────────────────────────────────────────┐
│                           阶段 1：数据准备 (PS/文件系统)                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  data/ifm_i.txt ──► 输入特征向量 (MNIST 图片经卷积层提取的 7×7×N 特征)      │
│  data/wts_i.txt ──► 全连接层权重矩阵 W[10×M] + 偏置向量 b[10]               │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                  阶段 2：PLIO 数据注入 (PL ↔ AIE 边界)                        │
├─────────────────────────────────────────────────────────────────────────────┤
│  input_plio "PLIO_i"  ──► 64-bit AXI4-Stream ► 特征向量流                   │
│  input_plio "PLIO_w"  ──► 64-bit AXI4-Stream ► 权重参数流                   │
│  output_plio "PLIO_o" ◄── 64-bit AXI4-Stream ◄ 分类 logits                   │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│               阶段 3：AIE 计算核心 (dense_w7_graph 内部)                      │
├─────────────────────────────────────────────────────────────────────────────┤
│  ┌─────────────────────────────────────────────────────────────────────┐     │
│  │ AIE-ML Tile 阵列并行计算:                                            │     │
│  │                                                                      │     │
│  │  Tile 0:  MAC阵列 ◄── 特征向量切片 0 ──► 部分和累加                  │     │
│  │  Tile 1:  MAC阵列 ◄── 特征向量切片 1 ──► 部分和累加                  │     │
│  │  Tile 2:  MAC阵列 ◄── 特征向量切片 2 ──► 部分和累加                  │     │
│  │  Tile 3:  MAC阵列 ◄── 特征向量切片 3 ──► 部分和累加                  │     │
│  │                                                                      │     │
│  │  计算:  output = W × input + b  (矩阵-向量乘法 + 偏置)                │     │
│  └─────────────────────────────────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│              阶段 4：结果输出 (PLIO → 文件系统)                               │
├─────────────────────────────────────────────────────────────────────────────┤
│  data/ofm_o.txt ◄── 10 个 float32 logits (对应数字 0-9 的原始分数)           │
│  (PS 侧可通过 argmax 选择最大 logit 作为最终分类结果)                          │
└─────────────────────────────────────────────────────────────────────────────┘

6. 使用模式与扩展指南

6.1 典型使用流程

// 步骤 1: 包含必要的头文件
#include "dense_w7_graph.h"  // 计算核心定义
#include <aie_api/aie.hpp>    // AIE 运行时 API

// 步骤 2: 定义顶层图（或直接复用 dut_graph）
class my_dense_graph : public graph {
public:
    dense_w7_graph dense;  // 复用计算核心
    input_plio ifm, wts;
    output_plio ofm;
    
    my_dense_graph() {
        // 自定义 PLIO 配置：可修改数据宽度、文件名等
        ifm = input_plio::create("IFM", plio_64_bits, "my_ifm.txt");
        wts = input_plio::create("WTS", plio_64_bits, "my_wts.txt");
        ofm = output_plio::create("OFM", plio_64_bits, "my_ofm.txt");
        
        connect<>(ifm.out[0], dense.ifm_i);
        connect<>(wts.out[0], dense.wts_i);
        connect<>(dense.ofm_o, ofm.in[0]);
    }
};

// 步骤 3: 主程序控制
my_dense_graph g;

int main() {
    g.init();           // 初始化 AIE 阵列
    g.run(4);           // 运行 4 次迭代（处理 16 张图片）
    g.wait();           // 等待完成（替代 end() 的同步版本）
    g.end();            // 清理资源
    return 0;
}

6.2 扩展到其他配置

6.3 常见陷阱与调试技巧

陷阱 1：文件路径错误

// 错误：相对路径基准可能不是预期的工作目录
ifm_i = input_plio::create("PLIO_i", plio_64_bits, "data/ifm_i.txt");

诊断：仿真器报错 "Cannot open input file" 或输出全零。

修复：使用绝对路径，或在仿真器配置（aiesimulator.cfg）中设置正确的工作目录。

陷阱 2：数据格式不匹配

输入文件中的数据格式必须与 dense_w7_graph 内部期望的类型严格一致。如果文件包含 int8 数据但内核期望 float：

诊断：输出结果看起来是"随机数"或极大/极小的数值。

调试：使用 aiesimulator 的 --dump 选项转储 AIE 核的内部内存，检查原始数据值。

陷阱 3：迭代次数与数据量不匹配

aie_dut.run(1);  // 处理 4 张图片

如果 ifm_i.txt 只包含 2 张图片的数据：

诊断：仿真挂起（hang）在最后一张图片的处理，或输出文件中后 2 张图片重复前 2 张的结果。

调试：使用 x86simulator（快速功能仿真）验证数据量，再切换到 aiesimulator（周期精确仿真）进行性能分析。

7. 相关模块参考

8. 总结与核心要点

8.1 模块核心职责

dense_classification_layer_graph（以 dut_graph 类形式呈现）是 MNIST 神经网络推理流水线的最后一棒。它不承担复杂的数学创新，而是专注于系统级集成：将计算密集的 dense_w7_graph 与 Versal 平台的 PL/PS 接口无缝对接。

8.2 关键设计洞察

1. 分层解耦：dut_graph（I/O 层）与 dense_w7_graph（计算层）的分离，让同一计算核心可适配多种系统集成场景。

2. 仿真优先：PLIO 与文本文件绑定的设计，让开发者无需编写 PS 主机代码即可验证 AIE 图功能，极大降低了学习和调试门槛。

3. 编译期确定性：所有连接和配置在编译时解析，确保 AIE 硬件资源分配的确定性，避免了运行时的资源竞争。

8.3 新贡献者检查清单

如果你是刚接触此模块的开发者，请按以下顺序建立理解：

• [ ] 通读 dut_graph 的构造函数，画出 PLIO ↔ dense_w7_graph 的数据流图
• [ ] 确认 data/ 目录下的 .txt 文件格式与 dense_w7_graph 期望的数据类型匹配
• [ ] 运行 x86simulator 验证功能正确性，再用 aiesimulator 确认性能
• [ ] 阅读 dense_w7_graph 的源码（本模块的核心依赖），理解矩阵-向量乘法的 AIE 并行化策略
• [ ] 尝试 修改 run(N) 的参数，观察输出文件的变化，验证对"迭代 = 4 张图片"的理解

文档版本: 1.0 最后更新: 基于 AIE-ML Design Tutorials 08-MNIST-ConvNet 实现