1. 项目概述在Zynq-7030上为实时边缘服务寻找最优通信路径在工业自动化、智能安防或者自动驾驶这类场景里干活久了你一定会遇到一个核心矛盾前端传感器比如摄像头、振动传感器产生的数据流又急又多需要立刻处理并做出响应但传统的云端处理链路太长等数据传到云中心、算完、再传回来黄花菜都凉了。这就是为什么“边缘计算”这几年火得不行——把计算力下沉到数据产生的地方。但光把计算节点放在边缘还不够节点本身的“内功”决定了实时性的上限。这就是为什么像Xilinx Zynq-7000系列这样的异构系统级芯片SoC在边缘侧越来越受青睐。它把通用的ARM处理器Processing System, PS和一块可编程的FPGA逻辑Programmable Logic, PL塞进了同一颗芯片里。想法很美好让Linux跑在PS上处理复杂的协议栈和用户界面让实时操作系统比如FreeRTOS或者干脆是裸机程序跑在另一个核上负责硬实时控制再把那些计算密集、重复性高的算法比如图像预处理、加密、神经网络推理烧进FPGA里做硬件加速。理论上这简直是边缘实时应用的“梦幻组合”。然而理想很丰满现实却很骨感。真正上手做项目时你会发现一个关键问题PS和PL之间PS的两个核之间数据到底怎么传用GPIO一根根线怼用AXI总线流式传输还是走DMA不同的选择带来的延迟和吞吐量可能是数量级的差异。更头疼的是这些选择往往和你的应用场景强相关你是要连续传输视频流还是处理突发的小数据包延迟要求是微秒级还是毫秒级这些决策直接决定了项目的成败但相关的实测数据和工程指南却散落在各种手册和论坛帖子里不成体系。我最近基于Zynq-7030平台完整地走了一遍这个“寻路”的过程。目标很明确抛开理论参数通过实际的硬件平台测量搞清楚在Linux、FreeRTOS和FPGA这三者之间各种通信方式GPIO, AXI4-Stream, DMA, OpenAMP/RPMsg的真实性能表现到底如何。更重要的是把这些冷冰冰的数据翻译成可以直接用于项目设计的“行动指南”。这篇文章就是这次实测之旅的完整记录和总结。如果你正在或即将涉及基于Zynq或类似异构SoC的实时边缘系统开发特别是对PS-PL、PS-PS之间的数据交换性能有要求那么下面的内容应该能帮你避开不少坑。2. 核心思路与方案选型为什么是这些测试组合在动手写代码和连逻辑之前得先把测试的“骨架”搭好。我们的目标是摸清Zynq-7030这个芯片内部数据通路的“脾气”因此测试组合必须覆盖最典型、最有可能用到的通信场景。整个思路可以分解为三个层次对应三种不同的数据交换需求。2.1 场景一操作系统间的协调与控制Linux ↔ FreeRTOS在很多边缘应用中我们需要一个功能全面的操作系统比如Linux来提供网络服务、文件系统、丰富的驱动和用户界面同时还需要一个确定性的实时环境比如FreeRTOS来保证关键任务的截止时间。在Zynq的双核Cortex-A9上我们可以采用非对称多处理AMP模式让Linux和FreeRTOS各占一个核。那么这两个核上的任务如何通信最典型的方式就是使用OpenAMP框架及其核心协议RPMsg。它的本质是基于共享内存和中断的消息传递。Linux作为主核负责加载FreeRTOS的固件到从核并启动它然后双方通过预先划分好的一块内存区域Vring来交换消息。为什么测这个因为这是实现“软实时”与“硬实时”协同的经典架构。但RPMsg是为控制和小数据量设计的它的开销有多大延迟是多少这决定了它能否用于传输图像数据还是说只适合传递“开始采集”、“停止”、“报警”这类控制命令。这是我们第一个需要量化的关键点。2.2 场景二处理器与硬件加速器的数据通道PS ↔ PL这是SoC发挥异构计算优势的核心。PS无论是跑Linux还是FreeRTOS需要把大量数据喂给PL中的硬件加速模块比如一个图像处理IP核并取回结果。这里主要有两条技术路径代表了两个极端GPIO通用输入输出最简单粗暴的方式。把FPGA上的寄存器映射到PS的地址空间PS像访问普通内存一样用write/read操作来设置或读取FPGA的引脚状态。优点是配置简单资源占用少软件直观。AXI4-Stream DMA专业的高速数据流方式。AXI4-Stream是一种无地址、单向流式数据协议非常适合视频、音频等连续数据。结合DMA直接内存访问PS只需要配置好源地址、目的地址和数据长度DMA控制器就会自动在DDR内存和FPGA的流接口之间搬运数据完全不需要CPU参与搬运过程。为什么同时测这两种GPIO和AXI4-Stream代表了“灵活性”与“性能”的权衡。GPIO适合小数据量、低频次、或者作为控制接口而AXI4-StreamDMA是为大数据量、高带宽场景而生的。我们需要知道到底多“大”的数据量值得上马更复杂的AXI DMA方案这个切换的临界点在哪里2.3 场景三实时核与硬件加速器的直连FreeRTOS ↔ PL这个场景是场景二的一个特例但至关重要。当我们对延迟极其敏感时例如电机控制、高速AD采样我们可能会让FreeRTOS独占一个核并让它直接与FPGA通信完全绕过Linux。这样避免了Linux内核调度、内存管理带来的非确定性延迟。测试这个场景的价值在于量化“绕过Linux”所带来的性能提升究竟有多大。是略有改善还是质的飞跃这能帮助我们决策是否值得为了这点性能提升而增加系统复杂度需要维护两套软件环境。基于以上思路我们最终的测试矩阵包含了以下六种组合的延迟与吞吐量实测Linux (Core 0) ↔ FreeRTOS (Core 1) via RPMsgLinux ↔ FPGA via GPIOLinux ↔ FPGA via AXI4-Stream DMAFreeRTOS ↔ FPGA via GPIOFreeRTOS ↔ FPGA via AXI4-Stream DMA3. 硬件与软件平台搭建从Vivado工程到测试程序理论分析完毕接下来就是撸起袖子干的阶段。所有的性能数据都必须基于一个可重复、可测量的实际硬件平台和软件栈。3.1 硬件平台与Vivado工程我们使用的是Avnet ZedBoard其核心是一颗Xilinx Zynq-7030SoC。对于硬件设计全部在Vivado 2022.1中完成。这里的关键是理解不同通信方式对应的硬件IP核配置。对于GPIO测试硬件设计非常简单。在Block Design中从Zynq PS引出两个AXI GPIO IP核一个配置为输出PS到PL一个配置为输入PL到PS。在PL侧我们设计了一个极简的Verilog模块其功能就是对输入的数据执行按位取反NOT操作然后从输出端口送出。这个设计几乎不消耗逻辑资源能确保我们测量的时间几乎全部花在通信上而不是FPGA的计算上。注意GPIO的位宽是可配置的。为了测试不同数据量下的性能我们分别测试了1位、8位、16位和32位并行传输。在Vivado中需要相应设置GPIO IP核的位宽参数。对于AXI4-Stream DMA测试设计要复杂一些但这是实现高性能传输的标准做法。首先在Zynq PS配置中使能HP0和HP1这两个高性能AXI从端口。这两个端口是PL高速访问DDR内存通道。在Block Design中添加两个AXI DMAIP核。一个用于Memory to Stream (MM2S)即从DDR内存读数据发送到FPGA另一个用于Stream to Memory (S2MM)即从FPGA接收数据写回DDR。使用AXI SmartConnectIP核将HP0端口连接到MM2S DMA的S_AXI_LITE控制接口和M_AXI_MM2S数据接口将HP1端口连接到S2MM DMA的相应接口。将两个DMA的M_AXIS_MM2S和S_AXIS_S2MM流接口连接到我们自定义的FPGA模块同样是NOT逻辑模块。最关键的一步在Address Editor中为DMA的数据缓冲区在DDR中分配一段连续的物理内存区域。Linux或FreeRTOS的驱动程序需要知道这个区域的起始地址才能正确配置DMA。3.2 软件栈与测试程序编写硬件描述文件.xsa生成后导入到Vitis 2022.1中进行软件开发。对于Linux ↔ FreeRTOS (RPMsg)Linux侧我们编写了一个用户空间程序。它通过Linux内核提供的rpmsg_char驱动与运行在另一个核上的FreeRTOS建立通信通道。程序的核心是一个循环发送一个数据包等待FreeRTOS回传echo记录往返时间。这里有个坑RPMsg协议内核头对用户空间不可见所以我们必须在payload里自己封装一个应用层头包含序列号和长度信息。FreeRTOS侧使用OpenAMP库提供的RPMsg API。我们创建了一个echo任务等待Linux发来的消息收到后原样发回。FreeRTOS的固件.elf文件需要被编译成一个“远程处理器固件”由Linux在启动时加载到从核的内存并启动。对于PS ↔ FPGA (GPIO)Linux驱动方式传统上可以通过/sys/class/gpio来操作但为了追求极致性能和直接控制我们采用了内存映射的方式。程序打开/dev/mem设备将GPIO控制器对应的物理地址映射到用户空间虚拟地址然后直接读写这些地址来操控GPIO引脚。这避免了系统调用的开销。FreeRTOS/Baremetal方式更直接。使用Xilinx提供的XGpio驱动库直接调用XGpio_DiscreteWrite和XGpio_DiscreteRead函数。这些函数底层就是操作寄存器几乎没有额外开销。对于PS ↔ FPGA (AXI DMA) 这是最复杂但也最体现性能的环节。缓存一致性这是最大的坑Zynq-7000的ARM Cortex-A9数据缓存不是硬件一致性的。意思是CPU写入缓存的数据DMA控制器是看不见的因为它直接访问DDR物理内存。因此在启动DMA传输之前必须手动将缓存中已修改的数据刷回flush到DDR。对于接收缓冲区在DMA写入后CPU读取之前必须将对应的缓存行失效invalidate否则CPU读到的将是缓存里的旧数据。// Linux 示例使用 GCC 内置函数 void flush_cache(void *addr, size_t size) { __builtin___clear_cache((char *)addr, (char *)addr size); } // 在启动DMA传输前flush发送缓冲区 flush_cache(tx_buffer, data_size); // 在DMA传输完成后读取数据前invalidate接收缓冲区 // 在ARM上flush和invalidate通常由同一个函数完成 flush_cache(rx_buffer, data_size);DMA配置我们使用DMA的直接寄存器模式Scatter-Gather禁用。程序需要将源/目标物理地址写入DMA的SRCADDR/DESTADDR寄存器。将传输长度字节数写入LENGTH寄存器。启动传输写入控制寄存器。同步机制我们采用轮询方式检查DMA状态寄存器的完成中断标志位而不是配置硬件中断。虽然轮询会占用CPU但简化了测试程序的复杂性避免了中断处理程序带来的额外延迟抖动使得测量结果更纯粹地反映数据传输本身的时间。时间测量Linux使用clock_gettime(CLOCK_MONOTONIC_RAW, ts)精度可达纳秒级。FreeRTOS使用XTime_GetTime()函数基于ARM的私有定时器时钟频率为666MHz分辨率约1.5ns。切忌使用FreeRTOS自带的xTaskGetTickCount()它的典型分辨率是10ms100Hz完全不够用。4. 性能实测数据与深度解析所有测试均运行1000次迭代丢弃前50次作为预热最终结果取平均值和标准差。下面这张表浓缩了所有核心测试结果我们先有一个全局观感表1Zynq-7030各通信路径延迟与吞吐量实测汇总通信路径接口/协议最小有效载荷平均往返延迟 (µs)最大吞吐量 (MB/s)性能瓶颈分析Linux ↔ FreeRTOSRPMsg (OpenAMP)1 Byte69.2 ± 15.1~6.5 (随包长增长)协议限制。协议栈开销大共享内存中断机制导致延迟高且不稳定。Linux ↔ FPGAGPIO (32-bit)4 Bytes3.8 ± 0.2~105 (32-bit并行)软件开销限制。内存映射I/O操作、系统调用上下文切换是主要开销。Linux ↔ FPGAAXI4-Stream DMA8 Bytes4.1 ± 0.3~250 (平台极限)硬件链路限制。达到AXI总线带宽上限延迟随包长线性增长。FreeRTOS ↔ FPGAGPIO (32-bit)4 Bytes1.2 ± 0.1~320 (32-bit并行)硬件接口限制。接近GPIO物理读写极限延迟极低且稳定。FreeRTOS ↔ FPGAAXI4-Stream DMA8 Bytes3.8 ± 0.2~1000(平台极限)硬件链路限制。充分发挥DMA和总线性能吞吐量是Linux下的4倍。4.1 延迟性能深度剖析Linux ↔ FreeRTOS昂贵的隔离代价实测平均延迟高达69微秒且标准差不小。这清楚地告诉我们RPMsg不适合传输实时数据流。它的设计目标是可靠的进程间控制消息传递其路径涉及Linux用户空间 - 内核驱动 - 共享内存拷贝 - 中断唤醒FreeRTOS - FreeRTOS响应 - 反向路径。每一层都有不可忽略的调度和上下文切换开销。更值得注意的是在测试初期前200个样本延迟波动极大见图1。这意味着如果你在系统启动后立刻进行通信可能会遭遇数百微秒的延迟尖峰。设计建议仅用RPMsg传递启动、停止、模式切换等非实时控制命令。任何对时间敏感的数据流必须寻找其他路径。PS ↔ FPGAGPIO vs AXI DMA的抉择GPIO的真相GPIO延迟极低FreeRTOS下仅1.2µs因为它本质上是CPU直接读写一个内存映射的寄存器几乎没有中间环节。但它的吞吐量受限于CPU的读写速度和位宽一次最多32位。它完美适用于低频、小数据量的状态读取或控制信号传递例如读取一个传感器状态字、发送一个脉冲触发信号。AXI DMA的真相在传输小数据包如8字节时其延迟~4µs甚至略高于GPIO这是因为配置DMA控制器本身有开销。DMA的优势在于“搬大块数据”。当数据包增大时GPIO需要CPU多次循环读写而DMA在启动后便独立工作CPU可处理其他任务。如图2所示随着数据包增大DMA的吞吐量迅速上升并达到平台期而GPIO的吞吐量增长缓慢。FreeRTOS vs Linux操作系统的决定性影响对比同一通信路径如AXI DMAFreeRTOS下的性能始终显著优于Linux。吞吐量有数倍之差延迟也更低、更稳定。这根本原因在于Linux是一个通用的、非实时的操作系统。即使不进行任何操作内核的调度器、中断处理、虚拟内存管理都会引入不可预测的延迟“jitter”。而FreeRTOS作为实时操作系统任务调度是确定性的且通常运行在裸机模式直接操作硬件免了绝大多数中间层开销。这是一个关键的设计启示对延迟和确定性要求极高的任务必须放在FreeRTOS或裸机环境中执行。4.2 吞吐量性能与瓶颈分析吞吐量的测试结果揭示了系统瓶颈的本质区别。协议瓶颈 vs 硬件瓶颈Linux ↔ FreeRTOS (RPMsg)如图3所示其吞吐量随着数据包增大几乎线性增长直到达到RPMsg协议本身的最大包长限制约64KB。没有出现平台期。这说明瓶颈不在物理传输能力而在协议处理开销。每个数据包都需要经过复杂的封装、解封装、缓冲区管理CPU时间主要花在这上面。PS ↔ FPGA (AXI DMA)如图4所示吞吐量随着包长增加快速上升但在达到约8KB包长后曲线明显变得平缓进入平台期。此时的吞吐量FreeRTOS下约1000 MB/s已经触及了Zynq-7000系列HP端口AXI总线的理论带宽上限。这说明瓶颈在于硬件链路带宽协议和DMA引擎已经充分发挥了硬件潜力。这个区分至关重要。如果你的应用吞吐量上不去首先需要判断是协议栈太“重”还是物理总线已经“堵车”了。前者需要优化软件或更换通信方式后者则可能需要更换更高性能的硬件平台如Zynq UltraScale。5. 设计指南从数据到决策基于以上实测数据我们可以提炼出针对不同边缘计算应用场景的具体设计指南。5.1 按应用类型选择通信方案1. 硬实时控制应用延迟敏感型场景电机伺服控制、高速AD采样闭环、安全急停。核心需求微秒级确定性延迟低抖动。首选方案FreeRTOS ↔ FPGA via GPIO。理由1.2µs的延迟是你能在Zynq-7030上获得的最快响应。GPIO操作简单直接确定性极高。适合传输控制字、状态标志等小数据。备选方案如果控制算法复杂需要向FPGA传递较多参数如PID系数数组可考虑FreeRTOS ↔ FPGA via AXI4-Lite。AXI4-Lite是一种简单的内存映射总线延迟比GPIO略高但支持更结构化的寄存器访问。2. 流式数据处理应用吞吐量敏感型场景视频流分析、雷达信号处理、高速数据记录。核心需求高且稳定的吞吐量CPU占用率低。首选方案FreeRTOS ↔ FPGA via AXI4-Stream DMA。理由接近1000 MB/s的吞吐量足以应对大多数高速数据流。DMA解放了CPU使其能专注于业务逻辑而非数据搬运。务必注意缓存一致性操作flush/invalidate这是正确性的前提。设计技巧使用**双缓冲Ping-Pong Buffer**技术。当DMA正在从Buffer A向FPGA传输数据时CPU可以处理上一帧已存入Buffer B的数据并准备下一帧填入Buffer A实现流水线操作最大化吞吐量。3. 混合型应用控制数据场景智能相机Linux处理UI和网络FreeRTOS负责实时对焦控制FPGA做图像预处理。核心需求功能隔离兼顾灵活性与实时性。架构方案控制路径Linux ↔ FreeRTOS via RPMsg。用于传递用户命令、工作模式切换。高速数据路径FreeRTOS ↔ FPGA via AXI4-Stream DMA。用于传输原始图像数据和处理结果。管理路径Linux ↔ FPGA via AXI4-Lite或GPIO。用于配置FPGA的IP核参数、读取状态信息。关键严格区分数据平面高速、实时和控制平面低速、可靠。不要让实时数据流经过Linux。5.2 关键参数配置与优化技巧1. DMA传输优化突发长度Burst Length在Vivado中配置AXI DMA IP核时最大化突发长度通常为256。这允许DMA在一次事务中传输更多数据减少总线仲裁开销显著提升效率。数据位宽使用64位数据位宽如果FPGA设计支持以匹配Zynq HP端口的位宽最大化总线利用率。内存对齐确保DMA缓冲区地址按缓存行大小通常32字节或64字节对齐。不对齐的访问会导致额外的总线周期降低性能。2. FreeRTOS任务与中断配置任务优先级将负责与FPGA通信的FreeRTOS任务设置为最高优先级确保它能及时响应。中断处理如果使用DMA完成中断而非轮询其中断服务程序ISR应尽可能短仅做标记将数据处理等耗时操作放在高优先级任务中。避免在ISR中进行复杂的内存操作或函数调用。3. Linux侧实时性调优如果必须使用如果某些功能不得不放在Linux中且对延迟有要求可以尝试以下优化但需知效果有限内核配置使用PREEMPT_RT补丁的实时内核。这能将最坏情况下的延迟从毫秒级降低到百微秒级。CPU隔离与绑核使用isolcpus内核参数隔离出一个CPU核然后通过taskset或sched_setaffinity将实时进程绑定到该核上。避免其他进程和内核线程的干扰。中断绑定将DMA或网络设备的中断IRQ绑定到非实时核上防止中断处理打断实时任务。Tickless内核配置nohz_full参数在隔离的CPU核上停止定时器滴答减少不必要的定时中断带来的抖动。6. 工业案例实战基于SoC的视觉缺陷检测系统理论最终要服务于实践。我们设计并实现了一个工业视觉缺陷检测的样例系统来验证上述设计原则。系统工作流程如下图像采集工业相机以30fps的速率捕获传送带上的产品图像。缺陷识别在Linux中运行一个轻量级深度学习模型如MobileNet SSD对每一帧进行推理识别出缺陷位置输出一个边界框坐标。实时标注将边界框坐标通过AXI4-Lite接口发送给FPGA。FPGA内实现了一个视频叠加OverlayIP核在对应的视频流位置上实时画出一个红色框。视频输出叠加了框的视频流通过HDMI或网络实时输出。架构设计与通信路径选择为什么用Linux因为需要运行复杂的AI推理框架如TensorFlow Lite, ONNX Runtime和视频流协议栈如GStreamer。这些在FreeRTOS上移植和运行非常困难。为什么用FPGA画框因为要在30fps即每33ms一帧的节奏下在1080p的图像上画框如果用CPU即使是ARM A9进行像素级操作极易掉帧。FPGA可以并行处理像素能在极短时间内完成叠加。通信路径控制命令Linux启动/停止检测 - FreeRTOS via RPMsg。低频适合。框坐标传输Linux - FPGA viaAXI4-Lite。数据量小几个整数但需要低延迟确保框的位置同步。AXI4-Lite比GPIO更规整比DMA更简单。视频流传输Camera - FPGA (VDMA) - DDR。这是最重的数据流使用专用的Video DMA (VDMA) IP核完全绕过CPU。标注后视频流FPGA - HDMI Controller。纯硬件流水线。性能结果在Zynq-7030上该系统能够稳定处理720p30fps的视频流并进行实时画框。尝试用纯软件方案在Linux上用OpenCV的cv2.rectangle实现画框即使在x86高性能PC上处理720p图像也难以达到30fps而在Zynq的ARM A9上更是只有个位数的帧率。这充分证明了“CPU协调 FPGA加速”异构架构在边缘实时处理中的不可替代性。7. 常见问题与调试心得在开发过程中踩过不少坑这里分享几个最具代表性的问题和解决方法。问题一DMA传输数据错乱时好时坏。现象从FPGA读回的数据随机错误但并非每次都会发生。根本原因缓存一致性问题这是Zynq PS和PL共享内存时最经典的坑。如3.2节所述CPU的缓存和DMA访问的DDR物理内存不同步。解决确保在启动DMA传输前对发送缓冲区执行flush操作在DMA传输完成后从接收缓冲区读取数据前执行invalidate操作。在Linux用户空间可以使用ioctl调用DMA_BUF_SYNC_START和DMA_BUF_SYNC_END如果使用dma-buf或者直接使用__builtin___clear_cache内置函数。在FreeRTOS/baremetal中需要调用Xil_DCacheFlushRange和Xil_DCacheInvalidateRange。问题二RPMsg通信建立失败Linux端打开设备节点超时。现象Linux用户空间程序打开/dev/rpmsgX设备时卡住或报错。排查步骤检查设备树确认remoteproc和rpmsg相关节点已正确配置并且状态为okay。检查固件加载通过ls /sys/class/remoteproc/查看远程处理器是否存在通过cat /sys/class/remoteproc/remoteprocX/state查看状态是否为running。检查资源表确保FreeRTOS编译出的固件中包含了正确的资源表resource table其中定义了vring的内存区域和大小。这是OpenAMP框架约定的“合同”双方必须一致。查看内核日志dmesg | grep rpmsg或dmesg | grep remoteproc通常会有详细的错误信息。问题三AXI-Stream链路不通FPGA侧收不到数据。现象PS启动DMA传输后FPGA逻辑分析仪ILA上看不到tvalid和tdata信号有效。排查步骤检查时钟和复位这是硬件调试第一步。确认AXI-Stream总线时钟ACLK和复位ARESETn已正确连接到FPGA模块并且复位已释放。检查握手信号AXI-Stream遵循tvalid/tready握手协议。确保FPGA模块在准备好接收数据时将m_axis_tready信号置为高电平。如果FPGA侧一直不拉高treadyDMA就会一直等待。检查地址映射在Vitis中确认DMA控制寄存器和数据缓冲区的物理地址与Vivado Address Editor中的配置完全一致。一个十六进制的错误就可能导致访问到错误的位置。使用ILA抓取信号在Vivado中插入ILA IP核抓取AXI-Stream接口上的关键信号tvalid,tready,tdata,tlast这是定位硬件逻辑问题最直接的手段。问题四FreeRTOS与FPGA通过GPIO通信读取值不稳定。现象偶尔读取到错误的值。原因信号同步问题。当PS写GPIO到FPGA读取或者FPGA写输出到PS读取如果两边时钟不同步可能会在信号变化沿进行采样导致亚稳态。解决在FPGA侧对来自PS的GPIO输入信号用PS的时钟进行打两拍同步两级寄存器同步器。always (posedge ps_clk) begin gpio_in_sync1 gpio_from_ps; gpio_in_sync2 gpio_in_sync1; end // 使用 gpio_in_sync2 作为稳定的输入信号在PS侧如果读取FPGA的输出在两次关键读取之间加入小的延时微秒级或者采用握手协议如先发请求等FPGA拉高应答信号后再读。最后我想分享一点最深的体会在异构SoC上进行边缘计算开发“选择比努力更重要”。在项目初期花时间厘清数据流为每一类数据选择最合适的通信路径GPIO, AXI-Lite, AXI-Stream DMA, RPMsg所带来的性能收益和系统稳定性提升远大于后期在单一路径上进行的代码级优化。这份基于Zynq-7030的实测指南希望能为你下一次的“选择”提供一个坚实的参考坐标系。
Zynq-7030异构SoC通信性能实测：GPIO、AXI DMA与RPMsg对比指南
发布时间：2026/5/27 14:48:23
1. 项目概述在Zynq-7030上为实时边缘服务寻找最优通信路径在工业自动化、智能安防或者自动驾驶这类场景里干活久了你一定会遇到一个核心矛盾前端传感器比如摄像头、振动传感器产生的数据流又急又多需要立刻处理并做出响应但传统的云端处理链路太长等数据传到云中心、算完、再传回来黄花菜都凉了。这就是为什么“边缘计算”这几年火得不行——把计算力下沉到数据产生的地方。但光把计算节点放在边缘还不够节点本身的“内功”决定了实时性的上限。这就是为什么像Xilinx Zynq-7000系列这样的异构系统级芯片SoC在边缘侧越来越受青睐。它把通用的ARM处理器Processing System, PS和一块可编程的FPGA逻辑Programmable Logic, PL塞进了同一颗芯片里。想法很美好让Linux跑在PS上处理复杂的协议栈和用户界面让实时操作系统比如FreeRTOS或者干脆是裸机程序跑在另一个核上负责硬实时控制再把那些计算密集、重复性高的算法比如图像预处理、加密、神经网络推理烧进FPGA里做硬件加速。理论上这简直是边缘实时应用的“梦幻组合”。然而理想很丰满现实却很骨感。真正上手做项目时你会发现一个关键问题PS和PL之间PS的两个核之间数据到底怎么传用GPIO一根根线怼用AXI总线流式传输还是走DMA不同的选择带来的延迟和吞吐量可能是数量级的差异。更头疼的是这些选择往往和你的应用场景强相关你是要连续传输视频流还是处理突发的小数据包延迟要求是微秒级还是毫秒级这些决策直接决定了项目的成败但相关的实测数据和工程指南却散落在各种手册和论坛帖子里不成体系。我最近基于Zynq-7030平台完整地走了一遍这个“寻路”的过程。目标很明确抛开理论参数通过实际的硬件平台测量搞清楚在Linux、FreeRTOS和FPGA这三者之间各种通信方式GPIO, AXI4-Stream, DMA, OpenAMP/RPMsg的真实性能表现到底如何。更重要的是把这些冷冰冰的数据翻译成可以直接用于项目设计的“行动指南”。这篇文章就是这次实测之旅的完整记录和总结。如果你正在或即将涉及基于Zynq或类似异构SoC的实时边缘系统开发特别是对PS-PL、PS-PS之间的数据交换性能有要求那么下面的内容应该能帮你避开不少坑。2. 核心思路与方案选型为什么是这些测试组合在动手写代码和连逻辑之前得先把测试的“骨架”搭好。我们的目标是摸清Zynq-7030这个芯片内部数据通路的“脾气”因此测试组合必须覆盖最典型、最有可能用到的通信场景。整个思路可以分解为三个层次对应三种不同的数据交换需求。2.1 场景一操作系统间的协调与控制Linux ↔ FreeRTOS在很多边缘应用中我们需要一个功能全面的操作系统比如Linux来提供网络服务、文件系统、丰富的驱动和用户界面同时还需要一个确定性的实时环境比如FreeRTOS来保证关键任务的截止时间。在Zynq的双核Cortex-A9上我们可以采用非对称多处理AMP模式让Linux和FreeRTOS各占一个核。那么这两个核上的任务如何通信最典型的方式就是使用OpenAMP框架及其核心协议RPMsg。它的本质是基于共享内存和中断的消息传递。Linux作为主核负责加载FreeRTOS的固件到从核并启动它然后双方通过预先划分好的一块内存区域Vring来交换消息。为什么测这个因为这是实现“软实时”与“硬实时”协同的经典架构。但RPMsg是为控制和小数据量设计的它的开销有多大延迟是多少这决定了它能否用于传输图像数据还是说只适合传递“开始采集”、“停止”、“报警”这类控制命令。这是我们第一个需要量化的关键点。2.2 场景二处理器与硬件加速器的数据通道PS ↔ PL这是SoC发挥异构计算优势的核心。PS无论是跑Linux还是FreeRTOS需要把大量数据喂给PL中的硬件加速模块比如一个图像处理IP核并取回结果。这里主要有两条技术路径代表了两个极端GPIO通用输入输出最简单粗暴的方式。把FPGA上的寄存器映射到PS的地址空间PS像访问普通内存一样用write/read操作来设置或读取FPGA的引脚状态。优点是配置简单资源占用少软件直观。AXI4-Stream DMA专业的高速数据流方式。AXI4-Stream是一种无地址、单向流式数据协议非常适合视频、音频等连续数据。结合DMA直接内存访问PS只需要配置好源地址、目的地址和数据长度DMA控制器就会自动在DDR内存和FPGA的流接口之间搬运数据完全不需要CPU参与搬运过程。为什么同时测这两种GPIO和AXI4-Stream代表了“灵活性”与“性能”的权衡。GPIO适合小数据量、低频次、或者作为控制接口而AXI4-StreamDMA是为大数据量、高带宽场景而生的。我们需要知道到底多“大”的数据量值得上马更复杂的AXI DMA方案这个切换的临界点在哪里2.3 场景三实时核与硬件加速器的直连FreeRTOS ↔ PL这个场景是场景二的一个特例但至关重要。当我们对延迟极其敏感时例如电机控制、高速AD采样我们可能会让FreeRTOS独占一个核并让它直接与FPGA通信完全绕过Linux。这样避免了Linux内核调度、内存管理带来的非确定性延迟。测试这个场景的价值在于量化“绕过Linux”所带来的性能提升究竟有多大。是略有改善还是质的飞跃这能帮助我们决策是否值得为了这点性能提升而增加系统复杂度需要维护两套软件环境。基于以上思路我们最终的测试矩阵包含了以下六种组合的延迟与吞吐量实测Linux (Core 0) ↔ FreeRTOS (Core 1) via RPMsgLinux ↔ FPGA via GPIOLinux ↔ FPGA via AXI4-Stream DMAFreeRTOS ↔ FPGA via GPIOFreeRTOS ↔ FPGA via AXI4-Stream DMA3. 硬件与软件平台搭建从Vivado工程到测试程序理论分析完毕接下来就是撸起袖子干的阶段。所有的性能数据都必须基于一个可重复、可测量的实际硬件平台和软件栈。3.1 硬件平台与Vivado工程我们使用的是Avnet ZedBoard其核心是一颗Xilinx Zynq-7030SoC。对于硬件设计全部在Vivado 2022.1中完成。这里的关键是理解不同通信方式对应的硬件IP核配置。对于GPIO测试硬件设计非常简单。在Block Design中从Zynq PS引出两个AXI GPIO IP核一个配置为输出PS到PL一个配置为输入PL到PS。在PL侧我们设计了一个极简的Verilog模块其功能就是对输入的数据执行按位取反NOT操作然后从输出端口送出。这个设计几乎不消耗逻辑资源能确保我们测量的时间几乎全部花在通信上而不是FPGA的计算上。注意GPIO的位宽是可配置的。为了测试不同数据量下的性能我们分别测试了1位、8位、16位和32位并行传输。在Vivado中需要相应设置GPIO IP核的位宽参数。对于AXI4-Stream DMA测试设计要复杂一些但这是实现高性能传输的标准做法。首先在Zynq PS配置中使能HP0和HP1这两个高性能AXI从端口。这两个端口是PL高速访问DDR内存通道。在Block Design中添加两个AXI DMAIP核。一个用于Memory to Stream (MM2S)即从DDR内存读数据发送到FPGA另一个用于Stream to Memory (S2MM)即从FPGA接收数据写回DDR。使用AXI SmartConnectIP核将HP0端口连接到MM2S DMA的S_AXI_LITE控制接口和M_AXI_MM2S数据接口将HP1端口连接到S2MM DMA的相应接口。将两个DMA的M_AXIS_MM2S和S_AXIS_S2MM流接口连接到我们自定义的FPGA模块同样是NOT逻辑模块。最关键的一步在Address Editor中为DMA的数据缓冲区在DDR中分配一段连续的物理内存区域。Linux或FreeRTOS的驱动程序需要知道这个区域的起始地址才能正确配置DMA。3.2 软件栈与测试程序编写硬件描述文件.xsa生成后导入到Vitis 2022.1中进行软件开发。对于Linux ↔ FreeRTOS (RPMsg)Linux侧我们编写了一个用户空间程序。它通过Linux内核提供的rpmsg_char驱动与运行在另一个核上的FreeRTOS建立通信通道。程序的核心是一个循环发送一个数据包等待FreeRTOS回传echo记录往返时间。这里有个坑RPMsg协议内核头对用户空间不可见所以我们必须在payload里自己封装一个应用层头包含序列号和长度信息。FreeRTOS侧使用OpenAMP库提供的RPMsg API。我们创建了一个echo任务等待Linux发来的消息收到后原样发回。FreeRTOS的固件.elf文件需要被编译成一个“远程处理器固件”由Linux在启动时加载到从核的内存并启动。对于PS ↔ FPGA (GPIO)Linux驱动方式传统上可以通过/sys/class/gpio来操作但为了追求极致性能和直接控制我们采用了内存映射的方式。程序打开/dev/mem设备将GPIO控制器对应的物理地址映射到用户空间虚拟地址然后直接读写这些地址来操控GPIO引脚。这避免了系统调用的开销。FreeRTOS/Baremetal方式更直接。使用Xilinx提供的XGpio驱动库直接调用XGpio_DiscreteWrite和XGpio_DiscreteRead函数。这些函数底层就是操作寄存器几乎没有额外开销。对于PS ↔ FPGA (AXI DMA) 这是最复杂但也最体现性能的环节。缓存一致性这是最大的坑Zynq-7000的ARM Cortex-A9数据缓存不是硬件一致性的。意思是CPU写入缓存的数据DMA控制器是看不见的因为它直接访问DDR物理内存。因此在启动DMA传输之前必须手动将缓存中已修改的数据刷回flush到DDR。对于接收缓冲区在DMA写入后CPU读取之前必须将对应的缓存行失效invalidate否则CPU读到的将是缓存里的旧数据。// Linux 示例使用 GCC 内置函数 void flush_cache(void *addr, size_t size) { __builtin___clear_cache((char *)addr, (char *)addr size); } // 在启动DMA传输前flush发送缓冲区 flush_cache(tx_buffer, data_size); // 在DMA传输完成后读取数据前invalidate接收缓冲区 // 在ARM上flush和invalidate通常由同一个函数完成 flush_cache(rx_buffer, data_size);DMA配置我们使用DMA的直接寄存器模式Scatter-Gather禁用。程序需要将源/目标物理地址写入DMA的SRCADDR/DESTADDR寄存器。将传输长度字节数写入LENGTH寄存器。启动传输写入控制寄存器。同步机制我们采用轮询方式检查DMA状态寄存器的完成中断标志位而不是配置硬件中断。虽然轮询会占用CPU但简化了测试程序的复杂性避免了中断处理程序带来的额外延迟抖动使得测量结果更纯粹地反映数据传输本身的时间。时间测量Linux使用clock_gettime(CLOCK_MONOTONIC_RAW, ts)精度可达纳秒级。FreeRTOS使用XTime_GetTime()函数基于ARM的私有定时器时钟频率为666MHz分辨率约1.5ns。切忌使用FreeRTOS自带的xTaskGetTickCount()它的典型分辨率是10ms100Hz完全不够用。4. 性能实测数据与深度解析所有测试均运行1000次迭代丢弃前50次作为预热最终结果取平均值和标准差。下面这张表浓缩了所有核心测试结果我们先有一个全局观感表1Zynq-7030各通信路径延迟与吞吐量实测汇总通信路径接口/协议最小有效载荷平均往返延迟 (µs)最大吞吐量 (MB/s)性能瓶颈分析Linux ↔ FreeRTOSRPMsg (OpenAMP)1 Byte69.2 ± 15.1~6.5 (随包长增长)协议限制。协议栈开销大共享内存中断机制导致延迟高且不稳定。Linux ↔ FPGAGPIO (32-bit)4 Bytes3.8 ± 0.2~105 (32-bit并行)软件开销限制。内存映射I/O操作、系统调用上下文切换是主要开销。Linux ↔ FPGAAXI4-Stream DMA8 Bytes4.1 ± 0.3~250 (平台极限)硬件链路限制。达到AXI总线带宽上限延迟随包长线性增长。FreeRTOS ↔ FPGAGPIO (32-bit)4 Bytes1.2 ± 0.1~320 (32-bit并行)硬件接口限制。接近GPIO物理读写极限延迟极低且稳定。FreeRTOS ↔ FPGAAXI4-Stream DMA8 Bytes3.8 ± 0.2~1000(平台极限)硬件链路限制。充分发挥DMA和总线性能吞吐量是Linux下的4倍。4.1 延迟性能深度剖析Linux ↔ FreeRTOS昂贵的隔离代价实测平均延迟高达69微秒且标准差不小。这清楚地告诉我们RPMsg不适合传输实时数据流。它的设计目标是可靠的进程间控制消息传递其路径涉及Linux用户空间 - 内核驱动 - 共享内存拷贝 - 中断唤醒FreeRTOS - FreeRTOS响应 - 反向路径。每一层都有不可忽略的调度和上下文切换开销。更值得注意的是在测试初期前200个样本延迟波动极大见图1。这意味着如果你在系统启动后立刻进行通信可能会遭遇数百微秒的延迟尖峰。设计建议仅用RPMsg传递启动、停止、模式切换等非实时控制命令。任何对时间敏感的数据流必须寻找其他路径。PS ↔ FPGAGPIO vs AXI DMA的抉择GPIO的真相GPIO延迟极低FreeRTOS下仅1.2µs因为它本质上是CPU直接读写一个内存映射的寄存器几乎没有中间环节。但它的吞吐量受限于CPU的读写速度和位宽一次最多32位。它完美适用于低频、小数据量的状态读取或控制信号传递例如读取一个传感器状态字、发送一个脉冲触发信号。AXI DMA的真相在传输小数据包如8字节时其延迟~4µs甚至略高于GPIO这是因为配置DMA控制器本身有开销。DMA的优势在于“搬大块数据”。当数据包增大时GPIO需要CPU多次循环读写而DMA在启动后便独立工作CPU可处理其他任务。如图2所示随着数据包增大DMA的吞吐量迅速上升并达到平台期而GPIO的吞吐量增长缓慢。FreeRTOS vs Linux操作系统的决定性影响对比同一通信路径如AXI DMAFreeRTOS下的性能始终显著优于Linux。吞吐量有数倍之差延迟也更低、更稳定。这根本原因在于Linux是一个通用的、非实时的操作系统。即使不进行任何操作内核的调度器、中断处理、虚拟内存管理都会引入不可预测的延迟“jitter”。而FreeRTOS作为实时操作系统任务调度是确定性的且通常运行在裸机模式直接操作硬件免了绝大多数中间层开销。这是一个关键的设计启示对延迟和确定性要求极高的任务必须放在FreeRTOS或裸机环境中执行。4.2 吞吐量性能与瓶颈分析吞吐量的测试结果揭示了系统瓶颈的本质区别。协议瓶颈 vs 硬件瓶颈Linux ↔ FreeRTOS (RPMsg)如图3所示其吞吐量随着数据包增大几乎线性增长直到达到RPMsg协议本身的最大包长限制约64KB。没有出现平台期。这说明瓶颈不在物理传输能力而在协议处理开销。每个数据包都需要经过复杂的封装、解封装、缓冲区管理CPU时间主要花在这上面。PS ↔ FPGA (AXI DMA)如图4所示吞吐量随着包长增加快速上升但在达到约8KB包长后曲线明显变得平缓进入平台期。此时的吞吐量FreeRTOS下约1000 MB/s已经触及了Zynq-7000系列HP端口AXI总线的理论带宽上限。这说明瓶颈在于硬件链路带宽协议和DMA引擎已经充分发挥了硬件潜力。这个区分至关重要。如果你的应用吞吐量上不去首先需要判断是协议栈太“重”还是物理总线已经“堵车”了。前者需要优化软件或更换通信方式后者则可能需要更换更高性能的硬件平台如Zynq UltraScale。5. 设计指南从数据到决策基于以上实测数据我们可以提炼出针对不同边缘计算应用场景的具体设计指南。5.1 按应用类型选择通信方案1. 硬实时控制应用延迟敏感型场景电机伺服控制、高速AD采样闭环、安全急停。核心需求微秒级确定性延迟低抖动。首选方案FreeRTOS ↔ FPGA via GPIO。理由1.2µs的延迟是你能在Zynq-7030上获得的最快响应。GPIO操作简单直接确定性极高。适合传输控制字、状态标志等小数据。备选方案如果控制算法复杂需要向FPGA传递较多参数如PID系数数组可考虑FreeRTOS ↔ FPGA via AXI4-Lite。AXI4-Lite是一种简单的内存映射总线延迟比GPIO略高但支持更结构化的寄存器访问。2. 流式数据处理应用吞吐量敏感型场景视频流分析、雷达信号处理、高速数据记录。核心需求高且稳定的吞吐量CPU占用率低。首选方案FreeRTOS ↔ FPGA via AXI4-Stream DMA。理由接近1000 MB/s的吞吐量足以应对大多数高速数据流。DMA解放了CPU使其能专注于业务逻辑而非数据搬运。务必注意缓存一致性操作flush/invalidate这是正确性的前提。设计技巧使用**双缓冲Ping-Pong Buffer**技术。当DMA正在从Buffer A向FPGA传输数据时CPU可以处理上一帧已存入Buffer B的数据并准备下一帧填入Buffer A实现流水线操作最大化吞吐量。3. 混合型应用控制数据场景智能相机Linux处理UI和网络FreeRTOS负责实时对焦控制FPGA做图像预处理。核心需求功能隔离兼顾灵活性与实时性。架构方案控制路径Linux ↔ FreeRTOS via RPMsg。用于传递用户命令、工作模式切换。高速数据路径FreeRTOS ↔ FPGA via AXI4-Stream DMA。用于传输原始图像数据和处理结果。管理路径Linux ↔ FPGA via AXI4-Lite或GPIO。用于配置FPGA的IP核参数、读取状态信息。关键严格区分数据平面高速、实时和控制平面低速、可靠。不要让实时数据流经过Linux。5.2 关键参数配置与优化技巧1. DMA传输优化突发长度Burst Length在Vivado中配置AXI DMA IP核时最大化突发长度通常为256。这允许DMA在一次事务中传输更多数据减少总线仲裁开销显著提升效率。数据位宽使用64位数据位宽如果FPGA设计支持以匹配Zynq HP端口的位宽最大化总线利用率。内存对齐确保DMA缓冲区地址按缓存行大小通常32字节或64字节对齐。不对齐的访问会导致额外的总线周期降低性能。2. FreeRTOS任务与中断配置任务优先级将负责与FPGA通信的FreeRTOS任务设置为最高优先级确保它能及时响应。中断处理如果使用DMA完成中断而非轮询其中断服务程序ISR应尽可能短仅做标记将数据处理等耗时操作放在高优先级任务中。避免在ISR中进行复杂的内存操作或函数调用。3. Linux侧实时性调优如果必须使用如果某些功能不得不放在Linux中且对延迟有要求可以尝试以下优化但需知效果有限内核配置使用PREEMPT_RT补丁的实时内核。这能将最坏情况下的延迟从毫秒级降低到百微秒级。CPU隔离与绑核使用isolcpus内核参数隔离出一个CPU核然后通过taskset或sched_setaffinity将实时进程绑定到该核上。避免其他进程和内核线程的干扰。中断绑定将DMA或网络设备的中断IRQ绑定到非实时核上防止中断处理打断实时任务。Tickless内核配置nohz_full参数在隔离的CPU核上停止定时器滴答减少不必要的定时中断带来的抖动。6. 工业案例实战基于SoC的视觉缺陷检测系统理论最终要服务于实践。我们设计并实现了一个工业视觉缺陷检测的样例系统来验证上述设计原则。系统工作流程如下图像采集工业相机以30fps的速率捕获传送带上的产品图像。缺陷识别在Linux中运行一个轻量级深度学习模型如MobileNet SSD对每一帧进行推理识别出缺陷位置输出一个边界框坐标。实时标注将边界框坐标通过AXI4-Lite接口发送给FPGA。FPGA内实现了一个视频叠加OverlayIP核在对应的视频流位置上实时画出一个红色框。视频输出叠加了框的视频流通过HDMI或网络实时输出。架构设计与通信路径选择为什么用Linux因为需要运行复杂的AI推理框架如TensorFlow Lite, ONNX Runtime和视频流协议栈如GStreamer。这些在FreeRTOS上移植和运行非常困难。为什么用FPGA画框因为要在30fps即每33ms一帧的节奏下在1080p的图像上画框如果用CPU即使是ARM A9进行像素级操作极易掉帧。FPGA可以并行处理像素能在极短时间内完成叠加。通信路径控制命令Linux启动/停止检测 - FreeRTOS via RPMsg。低频适合。框坐标传输Linux - FPGA viaAXI4-Lite。数据量小几个整数但需要低延迟确保框的位置同步。AXI4-Lite比GPIO更规整比DMA更简单。视频流传输Camera - FPGA (VDMA) - DDR。这是最重的数据流使用专用的Video DMA (VDMA) IP核完全绕过CPU。标注后视频流FPGA - HDMI Controller。纯硬件流水线。性能结果在Zynq-7030上该系统能够稳定处理720p30fps的视频流并进行实时画框。尝试用纯软件方案在Linux上用OpenCV的cv2.rectangle实现画框即使在x86高性能PC上处理720p图像也难以达到30fps而在Zynq的ARM A9上更是只有个位数的帧率。这充分证明了“CPU协调 FPGA加速”异构架构在边缘实时处理中的不可替代性。7. 常见问题与调试心得在开发过程中踩过不少坑这里分享几个最具代表性的问题和解决方法。问题一DMA传输数据错乱时好时坏。现象从FPGA读回的数据随机错误但并非每次都会发生。根本原因缓存一致性问题这是Zynq PS和PL共享内存时最经典的坑。如3.2节所述CPU的缓存和DMA访问的DDR物理内存不同步。解决确保在启动DMA传输前对发送缓冲区执行flush操作在DMA传输完成后从接收缓冲区读取数据前执行invalidate操作。在Linux用户空间可以使用ioctl调用DMA_BUF_SYNC_START和DMA_BUF_SYNC_END如果使用dma-buf或者直接使用__builtin___clear_cache内置函数。在FreeRTOS/baremetal中需要调用Xil_DCacheFlushRange和Xil_DCacheInvalidateRange。问题二RPMsg通信建立失败Linux端打开设备节点超时。现象Linux用户空间程序打开/dev/rpmsgX设备时卡住或报错。排查步骤检查设备树确认remoteproc和rpmsg相关节点已正确配置并且状态为okay。检查固件加载通过ls /sys/class/remoteproc/查看远程处理器是否存在通过cat /sys/class/remoteproc/remoteprocX/state查看状态是否为running。检查资源表确保FreeRTOS编译出的固件中包含了正确的资源表resource table其中定义了vring的内存区域和大小。这是OpenAMP框架约定的“合同”双方必须一致。查看内核日志dmesg | grep rpmsg或dmesg | grep remoteproc通常会有详细的错误信息。问题三AXI-Stream链路不通FPGA侧收不到数据。现象PS启动DMA传输后FPGA逻辑分析仪ILA上看不到tvalid和tdata信号有效。排查步骤检查时钟和复位这是硬件调试第一步。确认AXI-Stream总线时钟ACLK和复位ARESETn已正确连接到FPGA模块并且复位已释放。检查握手信号AXI-Stream遵循tvalid/tready握手协议。确保FPGA模块在准备好接收数据时将m_axis_tready信号置为高电平。如果FPGA侧一直不拉高treadyDMA就会一直等待。检查地址映射在Vitis中确认DMA控制寄存器和数据缓冲区的物理地址与Vivado Address Editor中的配置完全一致。一个十六进制的错误就可能导致访问到错误的位置。使用ILA抓取信号在Vivado中插入ILA IP核抓取AXI-Stream接口上的关键信号tvalid,tready,tdata,tlast这是定位硬件逻辑问题最直接的手段。问题四FreeRTOS与FPGA通过GPIO通信读取值不稳定。现象偶尔读取到错误的值。原因信号同步问题。当PS写GPIO到FPGA读取或者FPGA写输出到PS读取如果两边时钟不同步可能会在信号变化沿进行采样导致亚稳态。解决在FPGA侧对来自PS的GPIO输入信号用PS的时钟进行打两拍同步两级寄存器同步器。always (posedge ps_clk) begin gpio_in_sync1 gpio_from_ps; gpio_in_sync2 gpio_in_sync1; end // 使用 gpio_in_sync2 作为稳定的输入信号在PS侧如果读取FPGA的输出在两次关键读取之间加入小的延时微秒级或者采用握手协议如先发请求等FPGA拉高应答信号后再读。最后我想分享一点最深的体会在异构SoC上进行边缘计算开发“选择比努力更重要”。在项目初期花时间厘清数据流为每一类数据选择最合适的通信路径GPIO, AXI-Lite, AXI-Stream DMA, RPMsg所带来的性能收益和系统稳定性提升远大于后期在单一路径上进行的代码级优化。这份基于Zynq-7030的实测指南希望能为你下一次的“选择”提供一个坚实的参考坐标系。
