硅农预备役2024简单粗暴的建议：1. 数据通路：摄像头 -> PL（MIPI IP -> 预处理 -> 立体匹配硬件加速） -> AXI VDMA -> HP端口 -> DDR（预留的物理连续内存块）。PS应用程序轮询该内存块。2. 不要用ACP，除非你的PS应用程序需要频繁、随机地访问加速器内部的中间数据（这本身就不高效）。HP端口延迟更低，带宽更有保障。3. DMA配置：使用VDMA，设置合适的帧缓冲数量（2-3个），采用寄存器直接模式而非微码模式。4. 数据位置：在DDR中开辟一块物理连续的内存区域（可以通过设备树预留）。确保PS端应用以非缓存方式访问这块内存。这样整个数据流就像一条高速公路，没有红绿灯（CPU搬运、缓存维护）。剩下的就是优化你的硬件加速器架构了。
你的核心诉求是‘端到端延迟’，这包括传感器读出、传输、处理、结果输出的总时间。因此，PL内部加速器的架构比PS-PL互联更重要。设计一个深度流水线的立体匹配加速器，让像素级数据流入即处理，而不是攒够一帧再处理。这样，从摄像头像素进入PL到第一个视差结果输出，延迟只有几十到几百个时钟周期。PS-PL通路只用于传递控制命令（开始、参数）和读取最终的视差流。此时，数据通路带宽要求不高，用GP口都行，但为了快速读取结果，还是用HP口配合一个轻量级DMA（或甚至PS通过AXI-lite配置后，让加速器通过AXI Master直接写入内存）。重点：测量并优化PL内部流水线的‘首像素延迟’。
分享一下我们项目的坑。最初我们让PS用CPU搬运数据到PL，延迟直接爆炸。后来改用AXI DMA，好多了。但DMA配置有讲究：1. 使用简单DMA模式（非Scatter Gather）延迟更低，但要求内存物理连续。在Linux下需要用CMA或预留内存块。2. 数据缓冲区一定要用Non-cacheable内存，或者每次操作前后调用cache flush/invalidate函数，否则数据不一致会让你debug到怀疑人生。3. 如果想极致优化，可以考虑用PL端的AXI VDMA，它专为视频流设计，有帧缓冲和异步时钟域处理，比普通DMA更省心。端口选择上，如果PS运行裸机或无复杂任务，HP足够；如果PS跑Linux且有多个主设备争抢带宽，ACP的缓存一致性可以省去手动维护缓存的麻烦，但延迟可能略高。
从数据量角度算一下。假设双目1280x720 @ 60fps，灰度图，每秒数据量约12807201260 ≈ 132 MB。这还没算算法中间数据。HP端口理论带宽很高，但实际要考虑DDR控制器仲裁和效率。我建议：使用两个HP端口（或一个HP口的高性能从机接口）来实现读写并行。一个HP口负责将原始图像数据从DDR读到PL（如果你需要PS先做校正再给PL的话），另一个HP口负责将PL结果写回DDR。但最优方案还是楼上说的，让原始数据不经过DDR，直接在PL里从摄像头流到加速器。这需要你的校正和匹配算法都能流水线化。
别光盯着端口类型，整个数据流架构才是关键。我的经验是：1. 摄像头数据用PL端的MIPI/DPHY IP接收，输出AXI4-Stream。2. 在PL内部实现一个前处理模块（比如去拜耳、校正），然后直接喂给你的立体匹配硬件IP。3. 输出结果用AXI DMA（Scatter Gather模式）通过HP口写入DDR。为什么用HP不用ACP？ACP是给需要缓存一致性的加速器用的，比如PS跑Linux，加速器需要和CPU共享同一份数据。但你的立体匹配整个流程都在PL，PS只是偶尔来取结果，用HP带宽足够，延迟也更确定。数据放在DDR的固定地址或由PS分配的非缓存（Non-cacheable）区域，避免缓存一致性问题。
追求最低延迟的话，我的思路是让数据流尽量‘直通’，避免在DDR里来回搬运。摄像头数据通过MIPI CSI-2 RX子系统进入PL后，立刻进入你的立体匹配加速器IP进行运算。处理完的视差图，再通过VDMA或AXI4-Stream转AXI4-MM的IP，直接通过HP（高性能）端口写入DDR的特定区域。PS端的应用只需要去那个内存区域读取结果即可。这样，数据从进入PL到结果写入DDR，全程在PL内完成，PS只做最轻量的控制和读取，延迟最低。关键是要设计好PL内的流水线，确保实时吞吐量。
