简介面向需要实现PL与PS协同工作的FPGA开发者、嵌入式工程师和高校学生这份资源围绕Xilinx ZYNQ平台以网口TCP/IP协议为数据出口系统梳理了从硬件架构、总线通信到上位机收发的工程方案。内容基于AXI、LWIP、以太网MAC与DMA等关键环节覆盖接口选型、协议栈配置、数据通路搭建、实时性与带宽优化以及调试测试方法可帮助读者建立起清晰的设计与排错思路。压缩包整体约56.6MB文件清单与类型明细暂未提供但方案说明与关键步骤的衔接仍可作为完整项目参考。该资源已有10883人学习适合需要从整体理解PL/PS通信链路并通过TCP完成网络数据传输实践的工程师也可为ZYNQ网口通信类设计提供直接借鉴。1. 把 ZYNQ PL 与 PS 通信讲透TCP 上行数据的关键在于寄存器接口设计用 ZYNQ 做数据采集然后通过网口把数据送到上位机这个需求在项目里出现的频率比想象中高得多。很多开发者第一次接触 ZYNQ 时都有同样的困惑PL 和 PS 到底怎么交换数据TCP 协议栈跑在哪一端实际做下来你会发现TCP 协议本身是现成的LwIP 协议栈一挂就能跑真正的难点在于 PL 端的寄存器读写接口设计以及数据从 PL 到 PS 再到网口的这条链路怎么打通。这份资源的价值就在于此它不只是一个 TCP 例程而是把 PL 与 PS 通信的完整链路拆开从 AXI 接口设计到 LwIP 网络发送每一步都有可落地的代码和验证方法。2. AXI 接口选型与寄存器映射PL 与 PS 通信的第一步是定数据通道2.1 四种 AXI 接口模式的适用边界ZYNQ 的 PS 端通过 AXI 总线访问 PL 端的逻辑资源常见的有 AXI4、AXI4-Lite、AXI4-Stream 和 AXI-Full 四种接口类型。初学者最容易犯的错误是一上来就选 AXI4-Stream 做寄存器读写结果数据通路建立不起来卡在握手信号上。选型之前先明确一个原则控制面用 AXI4-Lite数据面用 AXI4-Stream两头都要走就用 AXI-Full。AXI4-Lite 的特点是一次只传一笔数据地址和数据通道独立时序简单非常适合读写 PL 端的寄存器。比如你要配置采集模块的采样率、启动停止标志位、查询状态寄存器这些都属于低频控制操作用 AXI4-Lite 就够了。AXI4-Stream 走的是流式数据传输没有地址阶段数据像流水线一样连续往外送适用于 ADC 采集数据、DMA 搬运这种高吞吐场景。AXI-Full 则同时支持突发传输和地址映射适合需要 PS 端频繁读写 PL 端大块存储空间的场景但是在 ZYNQ 上实现起来复杂度明显更高。加上中断机制后AXI4-Lite 加 AXI4-Stream 的组合在绝大多数数据采集上传项目中够用了。中断在 ZYNQ 里的实现不复杂PL 端拉高一个中断信号PS 端注册中断处理函数就能做到数据到达即通知 CPU。很多人在这里有个误区以为 PS 轮询 PL 寄存器更简单实际项目里数据量一大轮询会拖垮 CPU 占用率。2.2 寄存器映射的地址分配策略用 AXI4-Lite 实现寄存器读写时地址分配要做长远规划。通常的做法是把一个自定义 IP 核的寄存器空间划分为四个段控制寄存器区偏移 0x00 - 0x0F、状态寄存器区偏移 0x10 - 0x1F、数据缓冲描述区偏移 0x20 - 0x2F、扩展保留区偏移 0x30 以上。拿一个典型的 ADC 采集上传项目举例寄存器映射可以做这样的分配偏移地址读/写功能说明0x00写控制寄存器bit0 启动采集bit1 复位bit2 开启 FIFO 写使能0x04写采样率配置写入分频系数实际采样率 时钟频率 / (分频系数 1)0x10读状态寄存器bit0 FIFO 空标志bit1 FIFO 满标志bit2 采集忙标志0x14读数据计数寄存器当前 FIFO 中积累的数据字节数0x20读数据读取寄存器每读一次FIFO 出一个数据Vivado 中自定义 IP 核时会默认生成顶层模块和 AXI 接口的示例代码。建议在自动生成的模板基础上修改保留 AXI 接口部分把用户逻辑区域换成自己的设计。我一般会把地址解码逻辑全部放在top_module中用一个reg [31:0] reg_file [N]数组做寄存器阵列这样后续扩展寄存器方便维护成本低。module adc_ctrl_ip # ( parameter integer C_S_AXI_DATA_WIDTH 32, parameter integer C_S_AXI_ADDR_WIDTH 8 ) ( // 自定义端口 —— 采集数据输入 input wire [31:0] adc_data_in, input wire adc_data_valid, // 自定义端口 —— 中断输出 output wire irq_out, // AXI-Lite 接口端口自动生成部分略 ... ); // 寄存器文件定义 reg [31:0] reg_ctrl; // 偏移 0x00 控制寄存器 reg [31:0] reg_samp_cfg; // 偏移 0x04 采样率配置 reg [31:0] reg_status; // 偏移 0x10 状态寄存器 reg [31:0] reg_data_cnt; // 偏移 0x14 数据计数 reg [31:0] reg_fifo_data; // 偏移 0x20 数据读取 // 状态寄存器 bit1FIFO 满标志 wire fifo_full (fifo_wr_count FIFO_DEPTH); assign reg_status[1] fifo_full; assign reg_status[2] adc_run_flag; // 本地 FIFO 写控制 always (posedge clk or negedge rst_n) begin if (!rst_n) begin fifo_wr_en 1b0; end else if (adc_data_valid reg_ctrl[0]) begin fifo_wr_en 1b1; end end ... endmodule这里有几个参数需要重点理解C_S_AXI_ADDR_WIDTH 8表示地址宽度 8 位寻址空间 256 字节按 32 位寄存器对齐后最多支持 64 个寄存器一般项目够用了。adc_data_valid是外部 ADC 模块送来的数据有效标志这个信号被拉高时FIFO 的写使能才有效。注意代码中把reg_ctrl[0]作为采集总开关这是典型的设计模式——所有模块的启动、停止都由统一的控制寄存器管理后续上位机命令分发时只需往一个地址写数据避免多个寄存器协同操作带来的时序问题。2.3 FIFO 深度的工程权衡PL 端 FIFO 深度的选择直接决定数据传输链路会不会因为瞬间阻塞而丢数据。FIFO 深度太小PS 来不及读数据时就会溢出FIFO 深度太大占用 BRAM 资源影响其他逻辑的综合布局。从工程经验上看FIFO 深度至少为 PS 端 DMA 突发长度的两倍。如果 PS 端 DMA 配置的突发长度是 64 个 32 位字那么 FIFO 深度建议 128 以上。这个参数怎么推导的DMA 读数据时总线协议要求一次突发传输中间不能被中断如果 FIFO 中的数据少于突发长度DMA 就要等待 FIFO 攒够数据等待期间总线处于闲置状态。FIFO 深度大于两倍突发长度就能保证 DMA 连续读取时几乎不需要等待。另外还要考虑 FIFO 数据宽度与 DMA 数据宽度的匹配问题。如果 PL 端每拍产生 16 位数据而 PS 端 DMA 的读写位宽是 32 位中间需要做位宽转换。一种方式是直接用 Xilinx FIFO IP 核的位宽转换功能输入 16 位、输出 32 位另一种方式是用两个 16 位 FIFO 交替存储读出时拼接。前者简单后者可以节省资源但代码复杂度上升。如果数据速率不高我通常选择 Xilinx FIFO IP 核自带的标准模式转化功能设置好读写位宽就能用。3. PS 端工程配置与 LwIP 网络发送数据到 PS 之后谁来接管3.1 SDK 工程的 BSP 配置与 GIC 中断初始化Vivado 硬件导出到 SDK 后工程模板会自动生成 BSP 包但是 LwIP 协议栈默认不是开启的。在 SDK 环境下进入 BSP 设置窗口找到lwip141库选项把lwip勾上。这里有个版本兼容的坑Vivado 2018.3 之前的版本对应的 LwIP 版本是 141Vivado 2020.1 之后的版本 LwIP 升级到 211两者的 API 接口有细微差异后续代码编译报错时优先检查这里。GIC 中断控制器初始化是另一个核心点。PS 端要接收 PL 发来的中断信号就必须在 GIC 里注册中断服务函数。GIC 有 SPID 和 PPID 两个中断源组PL 端的中断一般连接到 GIC 的 SPI 中断号上。在 ZYNQ-7000 系列中PL 到 PS 的中断线有 16 条对应 GIC 的中断号从 61 开始递增。#include xscugic.h static XScuGic Gic; static XScuGic_Config *GicConfig; int Gic_Init(void) { GicConfig XScuGic_LookupConfig(0); if (GicConfig NULL) { return XST_FAILURE; } XScuGic_CfgInitialize(Gic, GicConfig, GicConfig-CpuBaseAddress); // 初始化异常处理必须在 GIC 初始化之后、中断注册之前完成 Xil_ExceptionInit(); Xil_ExceptionRegisterHandler( XIL_EXCEPTION_ID_INT, (Xil_ExceptionHandler)XScuGic_InterruptHandler, Gic ); Xil_ExceptionEnable(); return XST_SUCCESS; }这段代码里最容易被忽略的是Xil_ExceptionInit()调用的位置。很多人把异常初始化放在系统启动阶段最先处理但在 ZYNQ 上正确的顺序是先初始化 GIC 控制器再把 CPU 的异常处理函数指向 GIC 的中断分发入口。如果顺序搞反了中断信号到了 CPU 侧没有一个统一的入口去查找中断号程序就会跑飞。3.2 LwIP 协议栈的移植与网络接口配置LwIP 在 ZYNQ PS 端的移植已经比较成熟BSP 包里包含了 AXI Ethernet 驱动但我们这里用的是 PS 自带的千兆以太网控制器BSP 生成时会自动加入相应驱动。需要手动调整的是lwipopts.h文件中几个全局配置宏#define MEM_SIZE (8 * 1024 * 1024) // 内存堆大小 #define MEMP_NUM_PBUF 64 // PBUF 结构体数量 #define MEMP_NUM_TCP_SEG 128 // TCP 报文段缓冲区数量 #define TCP_SND_BUF_DEFAULT (16 * 1024) // 发送缓冲 #define TCP_WND_DEFAULT (16 * 1024) // 接收窗口 #define LWIP_DHCP 0 // 关掉 DHCP用静态 IP #define LWIP_NETCONN 1 // 启用中断/轮询模式 APIMEM_SIZE决定整个 LwIP 协议栈运行时能够使用的内存总量如果这个值太小TCP 连接建立时可能出现内存分配失败表现为上位机连接后立即断开。TCP_SND_BUF_DEFAULT 直接影响单次发送的数据包大小这个值可以按 MTU 的整数倍来配置常见取 16KB 是因为 TCP 窗口和 MTU 协商后16KB 的缓冲空间可以容纳约 10 个 MSS最大分段大小的数据量。网络接口初始化的代码固定框架其中关键在网络参数的结构体填充。我们是设备端服务器上位机是客户端主动连过来所以本地 IP、端口配置好后只需开启监听。#include lwip/init.h #include lwip/netif.h #include lwip/tcp.h #include xparameters.h #include xil_printf.h // 静态 IP 配置 #define TCP_SERVER_PORT 8080 #define DEVICE_IP_ADDR 192.168.1.100 #define DEVICE_NETMASK 255.255.255.0 #define DEVICE_GATEWAY 192.168.1.1 static struct tcp_pcb *server_pcb; static struct netif eth0_netif; void Network_Init(void) { struct ip_addr ipaddr, netmask, gw; IP4_ADDR(ipaddr, 192, 168, 1, 100); IP4_ADDR(netmask, 255, 255, 255, 0); IP4_ADDR(gw, 192, 168, 1, 1); lwip_init(); netif_add(eth0_netif, ipaddr, netmask, gw, NULL, ethernetif_init, ethernet_input); netif_set_default(eth0_netif); netif_set_up(eth0_netif); // 创建 TCP 控制块并绑定到监听端口 server_pcb tcp_new(); if (server_pcb NULL) { xil_printf(TCP PCB create error\r\n); return; } tcp_bind(server_pcb, IP_ADDR_ANY, TCP_SERVER_PORT); server_pcb tcp_listen(server_pcb); tcp_accept(server_pcb, Server_Accept_Callback); }这里有一个关键的设计选择netif_add的最后一个参数ethernet_input是 LwIP 的网卡数据输入函数这个函数在 ZYNQ 的裸机 BSP 环境中对应的是emacps_rx_thread之类的回调。务必确认 BSP 中以太网驱动的接收中断已经打开否则ethernet_input永远收不到数据TCP 就建立不起连接。3.3 数据发送的阻塞与非阻塞选择数据从 PL 读到 PS 后通过 TCP 发送给上位机。发送路径上有两种思路阻塞发送和回调发送。阻塞发送最简单——直接调用tcp_write加tcp_output数据就能发出去。问题在于tcp_write只是把数据拷贝到内核缓冲真正的网络发送发生在tcp_output之后如果缓冲区满tcp_write会返回ERR_MEM。很多初学者的程序在这里出现偶发丢包。正确做法是利用 LwIP 的发送完成回调机制。给 TCP 控制块注册一个sent回调函数当系统确认数据已经发送并得到对端 ACK 后才释放标志位允许下一批数据写入。static uint32_t tx_busy_flag; static uint8_t send_buffer[8192]; void Send_Data_To_Host(uint8_t *data, uint16_t len) { err_t err; // 等待上次数据发送完成 while (tx_busy_flag) { // 非阻塞等待发送完成回调会清除标志位 } memcpy(send_buffer, data, len); err tcp_write(server_pcb, send_buffer, len, TCP_WRITE_FLAG_COPY); if (err ERR_OK) { err tcp_output(server_pcb); if (err ERR_OK) { tx_busy_flag 1; } } } static err_t Server_Sent_Callback(void *arg, struct tcp_pcb *tpcb, u16_t len) { tx_busy_flag 0; return ERR_OK; }这段代码的逻辑亮点在TCP_WRITE_FLAG_COPY标志。不使用这个标志时tcp_write只是把指针存到待发送队列如果上层缓冲在 TCP 报文段真正发出前被修改会产生错误数据。使用 COPY 标志后LwIP 会先将数据拷贝到内部 PBUF函数返回后就可以安全地重用本地缓冲区。代价是多了一次内存拷贝但在千兆网口下这个开销可以接受。需要注意tx_busy_flag的等待循环不是严格意义上的阻塞因为 LwIP 协议栈需要持续调用tcp_tmr来处理定时器事件。在裸机环境下通常的做法是在主循环中刷新 LwIP 的定时器否则 TCP 的 ACK 超时重传机制无法工作while (1) { tcp_tmr(); // 刷新 LwIP 定时器处理重传、超时逻辑 // 检查 FIFO 数据计数寄存器有数据则读取并发送 if (Data_Is_Ready()) { Read_FIFO_And_Send(); } }4. 上位机 TCP 客户端与数据对齐链接建好了数据格式才是下一道关卡4.1 上位机的 TCP 接收实现要点上位机端推荐直接使用 Python 的 socket 模块快速验证先确认链路通不通再去做复杂的界面封装。很多开发者在这个项目上的做法是边写 Qt 界面边调试网络问题排查起来非常痛苦——网络不同时你很难判断是 PL 端逻辑坏了还是界面线程阻塞了。先用一个纯命令行脚本验证收发再把网络模块移植到图形界面中调通概率高很多。import socket import struct import time def recv_tcp_data(port: int, timeout: float 5.0) - None: TCP 客户端接收上位机数据按固定帧格式解析 client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.settimeout(timeout) server_addr (192.168.1.100, port) try: client.connect(server_addr) print(f[INFO] connected to {server_addr}) # 数据接收缓冲区避免一次 recv 零散切割造成解析错误 buffer b while True: try: chunk client.recv(4096) if not chunk: print([WARN] connection closed by device) break buffer chunk # 按帧头 0xAA55 长度字段协议解析 while len(buffer) 6: if buffer[0] 0xAA and buffer[1] 0x55: frame_len struct.unpack(H, buffer[2:4])[0] if len(buffer) 4 frame_len: break # 数据不完整继续等待 # 提取一帧有效数据 payload buffer[4:4 frame_len] print(f[INFO] received frame len{frame_len}, fdata_head{payload[:16].hex()}) buffer buffer[4 frame_len:] else: buffer buffer[1:] # 丢一个字节重新找帧头 except socket.timeout: print([WARN] recv timeout, no data in last period) break except ConnectionRefusedError: print([ERROR] device not listening, check IP and port) finally: client.close() if __name__ __main__: recv_tcp_data(port8080)这个脚本同时演示了 TCP 流式协议的拆包处理。TCP 是字节流协议两次send的数据可能在一次recv中混在一起也可能一次send被拆成多次recv。如果没有帧结构设计上位机收到的数据就是乱序的。代码中0xAA55帧头加长度字段的方案是工程最常用的做法先找帧头再按长度解帧能有效对抗粘包和半包问题。4.2 大小端与数据对齐的隐性战争PL 端是 ARM 架构的 ZYNQ 双核上位机通常跑在 X86 架构上ARM 默认小端序X86 也是小端序很多情况下不用考虑大小端转换问题。但问题是数据从 PL 硬件 FPGA 出来时开发者习惯整理成大端格式。一个 32 位的数据在 PL 端被拆成 4 个字节发送如果上位机按小端序解析数字就完全对不上。import struct # PL 端以特定字节序发送 4 字节数据 # 场景1PL 端按小端发送上位机用 符号解析 raw_small b\x01\x00\x00\x00 value struct.unpack(I, raw_small)[0] print(f小端解析结果: {value}) # 输出 1 # 场景2PL 端按大端发送上位机必须用 符号解析否则出错 raw_big b\x00\x00\x00\x01 value_wrong struct.unpack(I, raw_big)[0] value_right struct.unpack(I, raw_big)[0] print(f错误解析: {value_wrong}) # 输出 16777216 print(f正确解析: {value_right}) # 输出 1处理字节序最稳妥的做法是 PL 端发送时遵循固定的网络字节序大端上位机统一用!或符号解析。网络协议栈内部的 IP 头、TCP 头都是网络字节序如果应用层数据也统一用大端整个链路的数据格式就一致了。另外一种做法是 PL 端发送数据前把各字节按照上位机的预期存储顺序排列好上位机不做任何转换直接解析。这种方式效率最高但没有通用性一旦上位机换了平台所有解析逻辑都要改。我建议应用层还是定义大端格式协议头统一用struct.pack(!I, value)打包虽然多花几行代码但未来换上位机平台时不会翻车。5. 避坑与排查从连接失败到数据错乱的五个典型问题5.1 TCP 连接建立不了网络一直 ping 不通抓包软件看不到设备发出的 ARP 请求。排查发现 BSP 配置时没有正确生成xemacps_g.c驱动文件导致 PS 端以太网控制器根本没有初始化。原因是 SDK 中 BSP 包生成时没有勾选 Standalone 的emacps驱动或者勾选了但 BSP 没有重新生成。解决方法是右键点击 BSP 工程选择BSP Settings查找drivers分支下的ps7_ethernet_0是否为emacps不是则改为emacps然后重新生成 BSP。5.2 数据突发丢包TCP 连接正常但数据不完整现象是上位机连接正常但是数据每隔几秒会有一批缺失丢包数量没有规律。用 Wireshark 抓包发现 TCP 报文段重复 ACK 频繁出现。原因大概率在 PS 到 PL 的数据读取路径上。PS 读取 FIFO 数据时如果采用轮询方式但轮询间隔太长FIFO 溢出就会丢数据。此外LwIP 的tcp_write缓冲区设置太小发送缓冲满后新数据被丢弃。解决办法是把 FIFO 读取从轮询模式改成中断模式让 PL 端在 FIFO 半满时触发中断PS 立即响应读取。LwIP 参数调整同时把TCP_SND_BUF_DEFAULT从 4KB 提到 16KB给发送链路更多缓冲余量。5.3 AXI 读写寄存器一直返回错误值在 Vivado 的 Hardware Manager 里通过 JTAG 读 IP 核的寄存器状态寄存器一直显示 0xFFFFFFFF。检查 AXI 地址映射发现IP 核的基地址配置成了 0x40000000但 vivado 中地址编辑器的段分配把寄存器起始地址设在了 0x40001000两者错位导致访问落到了未实现的空间上。解决方法是打开 Address Editor确认adc_ctrl_ip的偏移地址是否从 0x0 开始建议把 Base Address 固定为 0x40000000Range 设为 64KB这样简单干净。类似问题在多个 IP 挂在同一个 AXI 总线上时更容易出现排查时要逐个确认地址段没有重叠。5.4 上位机收到的数据是反的帧头识别成功数据长度也对但是数值完全不对。比如理论上应该收到 10000实际收到 2055208960十六进制 0x7A690000。克制住去纠结 LwIP 代码的冲动先检查字节序。这是最典型的字节序问题。PL 端 Verilog 代码里把 32 位数据{data[31:16], data[15:0]}做了拼接发送相当于整体交换了两个 16 位半字实际就是大小端处理混乱。统一按大端处理后问题不再出现。5.5 开发板偶尔死机复位后恢复设备运行一段时间后网口 ping 不通串口也输出不了任何信息。检查时钟配置和复位序列发现 PL 端使用了独立的 MMCM 时钟域但 FIFO IP 核的复位引脚连接的是 AXI 接口的 rst 信号两个时钟域的复位时序不一致。解决方法是把 PL 端所有模块的复位信号统一使用proc_sys_resetIP 生成的interconnect_aresetn并检查 FIFO IP 的reset_pol设置是否与复位模块输出极性一致。在开发板上加一个看门狗复位超时自动重启整个系统也能规避偶发的死机问题。6. 进阶从千兆带宽利用到双通道设计实战性能再翻倍TCP 上传数据链路打通之后可以往下做两件缩小系统瓶颈的事一是吞吐量调优二是多路复用扩展。吞吐量调优的核心指标是计算实际有效带宽。ZYNQ PS 网口硬件理论带宽是 1000Mbps但是应用层实测通常只有 300 到 500Mbps原因在于 LwIP 裸机协议栈的运行机制限制以及 TCP ACK 往返时延带来的窗口占用。网络带宽利用率的计算公式为有效带宽 发送数据量 / 总耗时。在嵌入式设备上还会有一个额外限制LwIP 的tcp_write每调一次都要经历和本地内存系统打交道大量交互会消耗 CPU 时间。有一个简单有效的优化是加大单次发送包长。把TCP_SND_BUF_DEFAULT提升到 64KB同时在应用层使用tcp_write连续发送多个待发块配合tcp_output做一次集中刷出。这种策略下即使单块数据包较小协议栈也会积攒到足够数据后一次性发出有效降低网口 TX 中断触发频率。双通道设计适合需要同时上传两路数据的场景。做一个 AXI-Stream 到 AXI4-Lite 的桥接模块将两路 ADC 数据交替写入同一个 DMA 描述符环。上位机按帧号区分两路数据帧格式中前三字节固定为数据通道标识。这种设计比双 TCP 连接简洁PS 端只需维护一个tcp_pcb数据到达后按照既定的帧号交错发送即可。实践中的验证方法也很直接先用开发板配置一个固定数据源比如计数器计数值替代真实采集数据上位机统计接收总数和发送端计数对比。两端计数值一致说明链路无损不一致就对中间过程进行逐段 debug先看 PL FIFO 读写指针差值再看 PS 读出的数据累计值最后看 LwIP 发送字节统计量哪个环节对不上就重点检查哪个环节。那次调通双通道方案后我给自己立了一条规矩每次把代码从仿真环境挪到裸机网络环境先花 5 分钟核对三个关键参数——FIFO 写使能极性、TCP 发送缓冲大小、字节序解析格式。这三样没有问题的情况下网络异常往往不出在通信本身而是出在系统初始化的细节顺序。ZYNQ 的中断初始化顺序、LwIP 的内存堆大小、PHY 芯片的复位时序这三个位置是翻车高发区每次排查都从它们开始验证。希望这次拆解能帮你少走一段弯路。本文还有配套的精品资源点击获取
