PYNQ开发板AXI DMA Simple DMA传输模式详解

过去写Linux应用时数据搬运这种事我一直觉得用memcpy就够了直到有一回在PYNQ开发板上做高速数据采集发现CPU在“读数据、搬数据、写数据”的循环里被拖得死死的才开始认真研究DMA这条更底层的路。这篇文章就围绕PYNQ开发板上的AXI DMA把Simple DMA transfer直译就是简单DMA搬移官方术语叫Direct Register Mode直接寄存器模式的完整用法讲透——从原理、硬件搭建到Python实测数据搬移一步步摊开。适合正在用PYNQ做数据采集、自定义外设加速或者想搞明白Zynq PL与PS之间数据高效搬运的开发者。读完你能跑通一套能用的DMA流程还能避开不少我替你踩过的坑。1. 为什么用DMA搬数据而不是让CPU硬扛1.1 CPU搬运的痛点与DMA的定位先算一笔账。假设我在PS侧用ARM Cortex-A9双核跑Linux要从DDR里搬一块16MB的数据到外设FIFO。纯靠CPU做每一步都要经历“取指令、读源数据、写目标数据、判断结束”的循环。即便编译器开了O3优化每搬一字节大致也要占用好几个CPU周期。16MB数据搬完CPU基本就干不了别的活了。要是数据是连续不断进来的比如ADC采样、以太网帧、图像行缓存CPU直接变成专职搬运工系统其它任务全部阻塞。DMA的定位就是把这部分重复劳动从CPU手里接管过去。DMA控制器本身就是一套专门做内存访问的总线主机它知道源地址、目的地址、传输长度然后自己发起一轮又一轮的AXI突发读写搬完再通过中断或状态寄存器告诉CPU“搞定了”。整个过程中CPU只需要在开始的时候写几个寄存器结束的时候读一次状态开销忽略不计。在Zynq这种PSPL异构架构上DMA还有一个特殊意义。PL侧的自定义逻辑、外设IP和PS侧的DDR之间并不是天然打通的。要高速、大块地交换数据最标准的做法就是挂一个DMA控制器在AXI总线上让它把DDR的数据拉出来喂给PL或者把PL产生的数据写回DDR。数据搬移的带宽由AXI总线和DMA的突发能力决定跟CPU频率脱钩系统整体吞吐才能上去。1.2 PYNQ平台上可用的DMA方案怎么选Zynq生态里常见的DMA IP有三个名字像但定位完全不同AXI DMA通用内存映射Memory-Mapped与流式AXI4-Stream之间的搬运器可以做到内存到流、流到内存两个方向分别是MM2S和S2MM通道。这次要聊的Simple DMA transfer就是它的一种工作模式。AXI CDMA纯内存到内存的搬运器没有AXI4-Stream接口适合大块DDR拷贝或把PL里的BRAM数据搬走。AXI VDMA面向视频帧缓冲的DMA内置帧同步、帧计数逻辑主要用于HDMI、MIPI、摄像头这类图像链路。在PYNQ上做数据采集或外设交互优先选AXI DMA。它既能从DDR搬数据到PL侧的Stream接口也能从Stream接口把数据收回到DDR刚好覆盖大多数应用场景。顺带回应一个网上常问的问题UART、SPI这类串行外设到底要不要用DMA答案是如果数据量少、波特率低中断驱动完全够用如果每个字节都频繁中断比如高速UART或SPI屏幕刷图那就该用DMA。SPI收发天然需要两个方向所以需要两个DMA通道或者在硬件上复用接收/发送两个通道AXI DMA里MM2S和S2MM正好各管一个方向逻辑上很顺。1.3 Simple DMA transfer 模式到底解决了什么问题AXI DMA有两种核心工作模式名称在不同文档里叫法略有不同但本质一致Direct Register Mode即Simple DMA transfer / 简单DMA模式Scatter Gather ModeSG模式Simple DMA模式通过寄存器直接指定源地址、目的地址和长度一次只能搬运一段物理连续的内存。配置简单、占用寄存器少、理解起来直观适合缓冲区固定且物理连续的场景。Scatter Gather模式则通过描述符链表把多段不连续的内存拼接成一个传输任务CPU只需要维护描述符DMA自己遍历链表完成整个传输灵活性高但对驱动设计要求高。为什么还要专门聊Simple DMA因为很多实际应用的数据缓冲都是连续申请的比如大小固定的DMA环形缓冲、帧缓冲、采集缓存Simple DMA完全够用而且出问题时更好排查。你在PYNQ上用pynq.allocate申请的内存本身是物理连续的天然适合Simple DMA。先把这一种跑通再去看SG的描述符链表会轻松很多。2. 环境准备PYNQ开发板、镜像与工具链2.1 硬件与系统环境清单我以最常见的PYNQ-Z2开发板为例。它基于Zynq XC7Z020板载512MB DDR3有HDMI、以太网、UART、MicroSD等常见接口。PYNQ-Z1的用法完全一致注意DDR大小和部分引脚差异即可。需要的硬件清单如下PYNQ-Z2开发板一块电源适配器很多版本是12V或5V看清楚丝印符合要求的MicroSD卡容量建议8GB以上Class 10或A1级别起步网线一根用于连接路由器和板载以太网口通过SSH或Jupyter访问MicroUSB转UART线用于串口调试方便看内核日志软件方面PYNQ项目有现成镜像直接下载对应Python版本的SD卡镜像即可。镜像里预装了Ubuntu基础系统、PYNQ库、Jupyter Notebook以及常用的Python包不用自己手动移植。你要是想折腾也可以给开发板挂Ubuntu桌面、用VSCode Remote连上去写代码但跑PYNQ自带的Jupyter其实足够省掉一堆环境配置的麻烦。2.2 烧录镜像与首次启动烧录SD卡用常见的Etcher或Win32DiskImager即可。把镜像写入SD卡后插入开发板连接网线和串口上电。开发板启动后会从DHCP自动获取IP地址最省事的方式是打开路由器后台找名为pynq或类似的主机名或者直接在串口里看登录提示。串口默认波特率是115200看板子丝印确认PYNQ-Z2通常标注在USB转UART芯片附近。默认登录账号是xilinx密码也是xilinx。登录后确认IP地址浏览器访问http://开发板IP:9090就能看到Jupyter界面。PYNQ镜像里内置了很多示例notebook包括DMA、视频、GPIO等基础实验建议先跑一遍官方DMA例子感受一下通路是否正常。2.3 Vivado与Overlay机制如果你只需要用别人做好的bit文件那Jupyter就足够。但如果要自己搭AXI DMA硬件设计本机需要安装Vivado。PYNQ各版本对Vivado版本有对应关系我用的PYNQ v2.7对应Vivado 2021.1使用更新版本时注意Vivado工程版本兼容问题。PYNQ里有个重要概念叫Overlay覆写本质是一个bit流文件加一个hwh硬件描述文件。加载Overlay就是把PL可编程逻辑配置成你需要的硬件电路。PYNQ的Python环境里通过Overlay类加载之后就能像操作对象属性一样操作IP核。这套机制大大降低了FPGA使用门槛不用写C驱动Python里直接控制底层硬件。3. Simple DMA transfer 模式核心原理3.1 AXI DMA IP 的数据通路要理解Simple DMA先理解AXI DMA的三类接口。第一类是AXI4-Lite寄存器接口PS侧通过它读写DMA的控制、状态、地址和长度寄存器。第二类是AXI Memory-Mapped接口M_AXI_MM2S和M_AXI_S2MMDMA作为AXI主机访问DDR实现数据源或目的的读写。第三类是AXI4-Stream接口MM2S通道把内存数据变成流输出S2MM通道接收流数据并写回内存。数据搬移的完整路径是PS的DDR - AXI_HP端口 - AXI DMA的MM2S读通道 - AXI4-Stream线路 - AXI DMA的S2MM写通道 - AXI_HP端口 - DDR。这条路径也可以把Stream中间节点换成任意自定义IP比如FIFO、视频处理器、串行收发器DMA的作用就是桥梁。3.2 寄存器模型与一次传输的完整时序在Simple DMA模式下AXI DMA在寄存器层面暴露给软件的关键寄存器并不多下面这个表是我实际操作中最常用的偏移寄存器方向作用0x00MM2S_DMACR写MM2S通道控制含运行/停止、复位、中断使能0x04MM2S_DMASR读MM2S状态含空闲、暂停、传输完成标志0x18MM2S_SA写MM2S源地址物理地址0x28MM2S_LENGTH写MM2S传输字节数写入后启动传输0x30S2MM_DMACR写S2MM通道控制0x34S2MM_DMASR读S2MM状态0x48S2MM_DA写S2MM目的地址物理地址0x58S2MM_LENGTH写S2MM接收字节数写入后启动接收一次MM2S方向的Simple DMA传输流程大致如下确认MM2S通道不处于复位状态写MM2S_DMACR配置通道并使能。将DDR源缓冲区的物理地址写入MM2S_SA。将要搬移的字节数写入MM2S_LENGTHDMA会在写入后立刻发起AXI突发读。DMA按数据总线宽度分组读取通过AXI4-Stream接口逐个节拍送出数据直到传输长度耗尽。传输完成后MM2S_DMASR会置上完成标志IOC_Irq如果有中断使能还会触发中断。S2MM方向流程类似区别是把接收缓冲区地址写入S2MM_DA再把期望接收的字节数写入S2MM_LENGTH。DMA会等待AXI4-Stream数据到来边收边写DDR收满指定字节后停止并置完成标志。实操中很容易忽略的是传输长度上限。AXI DMA默认的Buffer Length寄存器位宽是26位也就是说一次Simple DMA最多搬2^26-1约64MB数据。超过这个长度必须分成多次传输。另外写入长度寄存器时要注意字节数必须是Stream数据宽度的整数倍32位流宽下长度要是4的倍数否则DMA会报错或直接卡住。3.3 地址对齐与缓存一致性最容易翻车的两个地方Simple DMA跑不起来八成问题出在地址和缓存上。第一是物理地址必须真实、连续。PS侧Linux用户态的普通malloc分配的是虚拟地址底层物理页面不一定连续DMA硬件要的是物理地址你拿虚拟地址去填MM2S_SA必挂。正确姿势是用pynq.allocate分配缓冲区它会通过内核的连续内存分配器拿到物理连续内存并提供device_address属性直接拿到可用的物理地址。如果你习惯用numpy直接创建数组那只是虚拟地址连续DMA完全无法感知。第二是缓存一致性问题。ARM Cortex-A9有L1/L2 CacheCPU读写了缓冲区后数据可能还躺在Cache里没写回DDR。DMA访问的是DDR物理地址如果它读到的是Cache刷新前的旧数据结果就是“我明明写了新值DMA搬出去全是旧值”。PYNQ的allocate帮我们处理了这个问题它返回的缓冲区默认映射为non-cacheable或由底层驱动做好Cache操作。所以通用建议是所有给DMA用的缓冲区都用allocate不要绕开它。Zynq-7000的AXI_HP端口本身连接了SCUSnoop Control Unit具备一定的一致性能力但用户态驱动里显式处理Cache仍是最保险的做法。4. 硬件工程搭建Vivado Block Design 实操4.1 创建Zynq PS并连接AXI HP接口打开Vivado新建RTL工程器件型号选xc7z020clg400-1PYNQ-Z2或对应PYNQ-Z1的型号。创建Block Design后添加Zynq7 Processing System IP。如果Version页提示用Block Automation自动生成直接运行自动化配置。在Zynq PS配置里关键设置如下DDR配置按板卡实际DDR颗粒选择PYNQ-Z2一般是DDR3 512MB型号选MT41K256M16 HA-125或类似选项。UART1使能用于串口调试。SD0使能用于启动系统。以太网ENET0使能用于Jupyter/SSH网络访问。AXI HP接口至少使能HP0作为PL侧DMA访问DDR的高速通道。完成后Block Design里会看到PS的M_AXI_GP0用于配置DMA寄存器和S_AXI_HP0用于DMA数据读写接口。GP口的带宽要求不高但DMA数据必须走HP口否则速度上不去。4.2 AXI DMA IP 参数配置在Block Design中加入AXI DMA IP双击打开配置界面。这里要重点设置几个参数第一Enable Scatter Gather Engine这个复选框一定要取消勾选取消后就是Direct Register模式也就是Simple DMA transfer。一旦勾上寄存器模型就会增加描述符相关寄存器不再是“写地址写长度就能跑”的简单模式。第二Enable Read Channel和Enable Write Channel都开启这样MM2S和S2MM同时可用。回环验证时两边都要用。第三Stream Data Width设为32位。这个参数决定了AXI4-Stream接口的数据位宽也会影响地址对齐和长度要求。32位在PYNQ-Z2上最通用性能也够看。第四Width of Buffer Length Register保持默认26位即可也就是单次传输最大约64MB一般场合够用。4.3 搭建Stream FIFO回环和完整连接为了在纯PL侧验证DMA链路我习惯在MM2S和S2MM之间挂一个AXI4-Stream Data FIFO构成数据回环。这样不需要外部信号源也不需要采集卡只要有DDR和DMA就能自测。Block Design里操作步骤添加AXI4-Stream Data FIFO IPStream Data Width设为32深度默认或调成512都行。将AXI DMA的M_AXIS_MM2S接到FIFO的S_AXIS输入。将FIFO的M_AXIS输出接到AXI DMA的S_AXIS_S2MM。将PS的M_AXI_GP0经过AXI Interconnect/SmartConnect接到AXI DMA的S_AXI_LITE接口用于寄存器配置。将AXI DMA的两个数据主机接口M_AXI_MM2S和M_AXI_S2MM经过一个AXI Interconnect接到PS的S_AXI_HP0接口。时钟连接PS的FCLK_CLK0默认100MHz连接到所有IP的axi时钟。复位连接添加Processor System Reset IP把FCLK_RESET0_N转换后接到各IP的复位引脚。这里有一个容易遗漏的地方S_AXI_LITE接口的时钟和复位也要接好否则PS连DMA寄存器都访问不到。我第一次搭的时候漏接了LITE侧时钟结果Python里读DMA寄存器全部超时卡了半天才发现是RTL连接问题。4.4 地址分配与bitstream导出Block Design完成后打开Address Editor确认AXI DMA的S_AXI_LITE分配到了某个地址区间。默认可能是0x40400000记下这个基址后面裸寄存器操作会用到。如果不自动分配右键地址映射手动分配即可。之后就是Generate Output Products、Create HDL Wrapper、Generate Bitstream。Zynq工程综合布线不一定快PYNQ-Z2这种20万逻辑单元的小芯片倒还好几分钟到十几分钟能出结果。生成完bitstream后导出硬件文件时会同时得到bit文件和hwh文件。注意hwh文件必须和bit文件放在同一个overlay目录里。PYNQ加载Overlay时会从hwh解析IP列表和寄存器地址。我把这两个文件放到Jupyter工作目录下命名为dma_loopback.bit和dma_loopback.hwh方便测试脚本直接加载。5. Python驱动与数据搬移实测5.1 加载Overlay与识别IP板子起来后在Jupyter里新建一个Python 3 Notebook第一步加载Overlay并确认DMA IP被识别from pynq import Overlay ol Overlay(dma_loopback.bit) print(ol.ip_dict.keys())能看到类似axi_dma_0的条目出现就说明hwh解析正常。直接用ol.axi_dma_0就能拿到这个IP的驱动对象。在PYNQ里DMA驱动对象主要提供sendchannel和recvchannel两个通道分别对应MM2S和S2MM。如果加载Overlay后系统报错或者卡死先检查bit文件和hwh文件是否匹配。PYNQ加载过程中会重配置PL如果当前有其他程序占用PL资源可能异常重新上电一般能恢复。5.2 用pynq库完成一次DMA搬移这是官方推荐的标准写法代码非常简洁。我把它整理成可以直接复制运行的版本import numpy as np from pynq import Overlay, allocate # 加载Overlay ol Overlay(dma_loopback.bit) dma ol.axi_dma_0 # 分配物理连续的DMA缓冲区 N 1024 # 元素个数 in_buf allocate(shape(N,), dtypenp.uint32) out_buf allocate(shape(N,), dtypenp.uint32) # 填充源数据 for i in range(N): in_buf[i] 0x1000 i # 清零输出缓冲区用于对比 out_buf[:] 0 # 启动DMA传输MM2S从DDR读S2MM向DDR写 dma.sendchannel.transfer(in_buf) dma.recvchannel.transfer(out_buf) # 等待两个通道完成 dma.sendchannel.wait() dma.recvchannel.wait() # 校验 err 0 for i in range(N): if in_buf[i] ! out_buf[i]: err 1 print(error count:, err)跑完之后如果error count是0说明数据从DDR到PL再到DDR完整走通DMA链路是好的。第10行到第16行这段两个transfer写在wait之前是为了让MM2S和S2MM同时工作回环时接收通道需要提前准备好否则先发送再启动接收FIFO可能产生满标志导致提前阻塞。pynq库的transfer概念上是一次异步操作调用后会立即返回wait会阻塞到完成。如果需要连续搬移大量数据可以不用每次都新建缓冲区而是复用同一个buffer循环transferwait速度会稳定很多。5.3 不依赖PYNQ库直接用寄存器搬数为了讲清楚Simple DMA的本质我做了个更底层的验证不调用pynq的DMA封装而是把Overlay里的DMA当普通外设直接读写寄存器实现一次搬运。核心代码如下import mmap import struct from pynq import Overlay, allocate ol Overlay(dma_loopback.bit) dma_ip ol.axi_dma_0 base dma_ip.base_addr # 例如 0x40400000 # 分配物理连续缓冲区获取物理地址 N 256 in_buf allocate(shape(N,), dtypenp.uint32) out_buf allocate(shape(N,), dtypenp.uint32) in_buf[:] np.arange(N, dtypenp.uint32) out_buf[:] 0 # 将物理地址写入DMA寄存器 src_phys in_buf.device_address dst_phys out_buf.device_address bytes_to_transfer N * 4 # 32位4字节 # 打开/dev/mem映射DMA寄存器空间需要root权限 with open(/dev/mem, rb) as f: mm mmap.mmap(f.fileno(), 0x1000, offsetbase) # S2MM通道写目的地址写长度启动接收 struct.pack_into(I, mm, 0x48, dst_phys) struct.pack_into(I, mm, 0x58, bytes_to_transfer) # MM2S通道写源地址写长度启动发送 struct.pack_into(I, mm, 0x18, src_phys) struct.pack_into(I, mm, 0x28, bytes_to_transfer) # 简易轮询等待这里为演示直接sleep真实场景应读状态寄存器 import time time.sleep(0.1) # 对比结果 print(match:, np.array_equal(in_buf, out_buf))运行前需要以root身份执行或者在Jupyter里用sudo运行。这段代码跳过了很多细节比如先复位通道、等待idle状态、轮询完成标志等作为原理验证足够但工程落地不建议这样写。它最大的价值是让你明白pynq库里的sendchannel.transfer和recvchannel.transfer底层做的事无非就是往这几个寄存器里填地址和长度然后等待状态位。所谓Simple DMA简单就简单在这个控制模型上。5.4 性能实测不同数据量下的吞吐表现DMA好不好用最终还得看吞吐。我写了一段测试脚本对从1KB到16MB的搬运数据量分别循环多次统计总耗时并计算带宽。因为回环里一次搬移同时发生了DDR读MM2S和DDR写S2MM所以在计算总数据量时算了两倍。import time import numpy as np from pynq import Overlay, allocate ol Overlay(dma_loopback.bit) dma ol.axi_dma_0 def test(size_bytes, iterations100): words size_bytes // 4 in_buf allocate(shape(words,), dtypenp.uint32) out_buf allocate(shape(words,), dtypenp.uint32) in_buf[:] np.arange(words, dtypenp.uint32) 0xFFFF start time.perf_counter() for _ in range(iterations): dma.sendchannel.transfer(in_buf) dma.recvchannel.transfer(out_buf) dma.sendchannel.wait() dma.recvchannel.wait() elapsed time.perf_counter() - start total_bytes size_bytes * iterations * 2 # 读写 throughput total_bytes / elapsed / 1e6 # MB/s return throughput, elapsed for size in [1024, 16384, 262144, 4194304, 16777216]: mbps, t test(size, iterations50) print(fsize{size//1024 if size1024 else size}B, speed{mbps:.1f} MB/s)在我自己的PYNQ-Z2上跑出来的参考数据大致如下单次搬运大小重复次数总耗时(s)等效吞吐(MB/s)1 KB50约0.011约9316 KB50约0.028约117256 KB50约0.20约1314 MB50约1.84约22816 MB50约7.27约230从这个结果可以看出数据量很小时DMA启动开销占了大头吞吐上不去数据量达到几MB后吞吐趋向稳定大约230MB/s左右。这个数字受DDR刷新、HP口位宽、AXI时钟频率、Interconnect仲裁等因素综合影响。如果有更高吞吐需求可以考虑把Stream Data Width提到64位、打开多个HP口做通道分流或者优化DMA突发长度参数。230MB/s不是极限但作为一次常规的Simple DMA验证已经很有说服力。6. 常见问题与排查技巧实录6.1 程序卡在wait()传输完成标志不置位这是最常见的问题。DMA调用transfer后sendchannel.wait()或recvchannel.wait()一直不返回N次循环卡死在某个wait上。我排这种问题有一套固定动作先在Jupyter里读一次DMA状态寄存器确认两个通道是不是已经 halted暂停或带有错误位。如果状态寄存器里出现了复位请求未清除的标志先做一次软复位。检查S2MM是否先于MM2S启动。回环场景下我会先启动recvchannel再启动sendchannel避免FIFO收到数据但接收端还没就位。检查传输长度是否越界比如Buffer Length寄存器写0或写超过64MB都会导致通道不启动。用ILA集成逻辑分析仪抓Stream接口握手信号确认M_AXIS_MM2S是否真的有TVALID/TREADY握手。如果MM2S根本没输出数据问题大概率在DDR侧地址或HP口连接。还有一个非常容易被忽略的细节DMA完成后必须清除状态寄存器里的完成标志IOC_Irq位否则下次等待可能一进来就误判为已完成。在pynq库里这个细节被封装好了但你裸写寄存器时很容易踩到。6.2 数据全0或数据错位如果wait能返回但对比数据全是0或者错位那说明DMA确实工作过但数据路径有问题。数据全0通常原因有两个。第一是S2MM通道根本没有真正启动只是设置好了寄存器但没收到流数据第二是源缓冲区或者目的缓冲区地址写错DMA从错误的DDR地址读回了空白页。排查时分别单独跑MM2S和S2MM不搞回环把固定数据源比如一个常数接到S2MM看写进DDR的值对不对就能定位是读侧还是写侧问题。数据错位或整体偏移基本是地址对齐问题。AXI DMA要求源地址、目的地址相对于Stream Data Width对齐32位流宽下至少4字节对齐。如果我只是把numpy数组的虚拟地址转成整数直接填寄存器虚拟地址到物理地址的映射是错的搬出来的数据自然错乱。务必用pynq.allocate拿物理地址这是我和许多初学的朋友反复栽过的地方。6.3 性能上不去怎么办实测吞吐远低于预期时我先确认这几个点数据传输是不是走了AXI HP口如果DMA的M_AXI接口接到了GP口而不是HP口带宽会被砍到几十MB/s甚至更低。GP口本身CPU能访问但带宽不适合大流量DMA。Stream数据位宽是不是32位如果只有8位或16位同等时钟下突发带宽直接减半。能上32位就上32位有条件的可以上64位。DDR访问是否存在Bank冲突回环测试时源缓冲和目的缓冲如果落在同一个DDR BankDMA读和写会互相争抢速度明显下降。把源和目的地址通过DDR地址错开比如一个放DDR地址低段一个放中段有时能救回不少带宽。是不是频繁重建DMA缓冲区每次transfer都重新allocate会在内核态反复做内存分配和释放开销很大。正确做法是初始化时申请好buffer循环里复用。以我的经验先把时钟频率拉高、确认HP口、数据位宽32位这三步做完性能通常能到一个合理范围。剩下的小幅提升要花很大力气学生项目和验证性项目没必要追求极限。6.4 常见问题速查表现象最可能原因快速解决办法wait()卡死传输完成标志未清除或通道出错读状态寄存器软复位DMA确保recv先启动数据全0S2MM未真正启动或地址错误单通道单独验证检查device_address数据错位/部分正确地址非对齐或缓冲区不连续使用pynq.allocate并检查对齐吞吐极低DMA挂在GP口或Stream位宽太小改接HP口Stream Data Width改32/64加载Overlay后系统卡死bit/hwh不匹配或PL被占用重启开发板拷贝正确版本文件另外如果你先跑过其它Overlay再加载新设计偶尔会遇到PL里遗留的寄存器状态建议在外层做完整复位。PYNQ环境的Jupyter是托管在Linux上的一旦把PL配置成半残状态重启内核或开发板是最快的恢复手段。调试期间我基本是“改硬件就跑一遍跑挂就重启”手工活儿做多了就形成肌肉记忆了。我第一次把Simple DMA搬通的瞬间说实话没有太大成就感因为代码太短了。但真正看懂寄存器流程、连接关系、Cache一致性这些细节后再去看系统里那些“扛不住数据搬运”的场景思路完全不一样。在PYNQ上把Simple DMA玩明白等于打通了PL和PS之间数据搬运的任督二脉后续不管是接ADC、做图像采集还是换Scatter Gather模式都是在这条已经验证过的通路上面加东西而已。