简介：这份资源面向嵌入式开发与FPGA学习者，聚焦ZYNQ平台上PL与PS协同通信并通过网口TCP协议向上位机传输数据的完整实现思路。内容围绕AXI总线（AXI4-Lite、AXI4-Full、AXI4-Stream）的选型与硬件描述实现、LWIP轻量级协议栈在PS端的移植配置、PL侧以太网MAC与DMA数据交换，以及TCP连接建立、收发与关闭等关键环节展开，并涉及实时性、带宽与功耗的优化策略和逻辑仿真、硬件在环、抓包分析等调试手段。压缩包为zip格式，约56.6MB，上游未提供文件数量与类型明细，故不展开具体文件构成。该资源已有10910人学习下载，适合希望打通ZYNQ软硬件协同链路、理解PL与PS数据通路及网络传输机制的开发者参考，可据此梳理从Vivado逻辑设计到LWIP应用编程的整体框架与排错方向。

1. 从“数据出不来”说起：ZYNQ 双核架构下的 TCP 上传链路到底难在哪

做 ZYNQ 项目的人大多踩过同一个坑：PL 端逻辑跑得飞快，采样数据在片上 RAM 里堆成山，可一到“把数据送到上位机”这一步就卡住——串口太慢，USB 要写驱动，SD 卡只能离线存。真正能兼顾带宽和通用性的，还是 PL 与 PS 协同、走网口 TCP 这条链路。这套方案要解决的就是：PL 端采集或生成的数据，经 AXI 总线交给 PS 端的 ARM 核，再由 PS 跑 TCP 协议栈，通过以太网口稳定推给上位机。它适合正在做 ZYNQ 毕设、课设，或需要交付一套“FPGA 采集 + 网络传输”原型的同学和工程师。zynq fpga tcp pl ps 这四个词，基本就是整条链路的骨架，下面按需求、设计、实现、避坑、验收一层层拆开。

2. 需求与选型：为什么是 PL+PS+TCP 这套组合

2.1 先把数据通路的需求量化

任何方案落地前，先把“要传多少、多快、多稳”写清楚，否则后面选型全是拍脑袋。我一般会先列一张需求表，把模糊的“实时传输”翻译成可验收的数字。

把这张表填完，你会发现两个结论：第一，数据量在百兆以内，PS 端的 ARM 核跑轻量 TCP 协议栈完全扛得住；第二，可靠性优先于极限时延，所以选 TCP 而不是 UDP。这就是选型的起点，不是“大家都用 TCP 所以我也用”。

2.2 PL 与 PS 的分工边界

ZYNQ 的价值在于软硬协同，但分工划不清就会互相拖累。我的划分原则是：跟时序强相关、需要并行处理的放 PL；跟协议、调度、人机交互相关的放 PS。

PL 端负责数据采集、缓存、打包成固定格式，并通过 AXI4-Stream 或 AXI4-Lite 把数据送到 PS 侧；PS 端负责跑 TCP 服务端/客户端、管理连接、把收到的数据流按帧重组后发给上位机。中间用 AXI DMA 做搬运，避免 CPU 逐字节拷贝——这是整条链路性能的关键分水岭。很多同学一开始用 AXI-Lite 轮询读寄存器，带宽上不去还占满 CPU，这就是没划清边界的典型翻车。

2.3 协议栈与开发环境的选择

PS 端跑 TCP 有两条路：裸机（bare-metal）下用 lwIP，或者在 Linux 下用标准 socket。选哪条取决于项目性质：

• 裸机 + lwIP：启动快、无操作系统开销、适合课设和确定性要求高的场景，但协议栈功能相对精简，调试要靠打印和抓包。
• Linux + socket：协议栈成熟、工具链丰富、方便写多线程和文件落盘，适合毕设和产品原型，代价是启动时间和系统复杂度上升。

通常的做法是：课设/验证阶段用裸机 lwIP 快速打通链路，毕设/交付阶段切到 Linux 提升可维护性。两者在“PL 采集 → PS 发送”这条主链路上的设计思路是一致的，差别只在 PS 侧代码形态。

提示：选型阶段就把“上位机用什么收”定下来。上位机用 Python 写个 socket 客户端最省事，调试期还能顺手存成 csv 做波形回放。

3. 总体架构设计：四条数据通路与三个职责模块

3.1 系统框图与数据流向

整套系统可以拆成四条通路：采集通路、搬运通路、协议通路、呈现通路。用文字把框图描述清楚，比画一张花哨的图更有用：

• 采集通路：PL 端采样逻辑 → 片内 FIFO → 打包模块（加帧头、长度、校验）。
• 搬运通路：打包后的数据经 AXI4-Stream 进入 AXI DMA，DMA 写 DDR，产生中断通知 PS。
• 协议通路：PS 端从 DDR 取数据，经 lwIP/socket 封装成 TCP 段，走 MAC → PHY → 网口。
• 呈现通路：上位机 socket 接收，按帧头解析，实时显示或落盘。

四条通路里，搬运通路最容易成为瓶颈，因为它横跨 PL 和 PS 两个时钟域，还要和 DDR 控制器抢带宽。设计时要把 DMA 的突发长度、FIFO 深度、中断频率一起调，单看某一项都会误判。

3.2 三个职责模块的划分

按职责把系统切成三个模块，每个模块有明确的输入输出和验收点：

1. 数据生产模块（PL）：输入是传感器/逻辑信号，输出是带帧格式的 AXI-Stream 数据。验收点是“帧头正确、长度字段与实际一致、无溢出丢帧”。
2. 数据搬运与协议模块（PS）：输入是 DMA 中断和 DDR 中的数据，输出是 TCP 字节流。验收点是“连接建立成功、发送字节数与接收一致、断线能重连”。
3. 上位机接收模块（PC）：输入是 TCP 字节流，输出是解析后的数据记录。验收点是“帧同步不丢、解析字段与 PL 定义一致、长时间运行不崩”。

模块划分的意义在于：出问题时能快速定位是哪一段的锅。比如上位机收到的帧长度对不上，先查 PL 打包，再查 DMA 搬运，最后才怀疑 TCP——顺序反了会浪费大量时间。

3.3 时钟与复位策略

ZYNQ 里 PL 和 PS 各自有时钟域，跨域处理不当就是玄学故障的源头。我的做法是：PL 采集用外部采样时钟，打包和 AXI-Stream 侧统一到 PS 提供的FCLK_CLK0，跨域处用异步 FIFO 隔离；复位信号用 PS 输出的FCLK_RESET0_N统一管理，避免 PL 先起来、PS 后起来导致的握手错位。这套策略不复杂，但能省掉后面大量“偶发丢帧”的排查。

4. PL 端实现：打包、缓存与 AXI-Stream 对接

4.1 帧格式定义：先定协议再写逻辑

PL 和上位机之间必须有一份双方都认的帧格式，否则解析全靠猜。我一般定一个定长头 + 变长载荷的结构：

帧头用固定魔数是为了上位机做字节流重同步——TCP 是字节流，不保证一次 recv 就是一帧，没有帧头就只能靠长度字段硬凑，一旦错位就全乱。这个细节是血泪经验，后面避坑章节还会展开。

4.2 打包模块的 Verilog 骨架

打包逻辑的核心是“来一个采样就写进 FIFO，攒够一帧就加头加尾推给 AXI-Stream”。下面是一个简化骨架，重点看状态机和握手信号：

// 帧打包模块：采样入 FIFO，攒够 PAYLOAD_LEN 后加帧头帧尾输出 module frame_packer #( parameter PAYLOAD_LEN = 1024, // 每帧载荷字节数 parameter HEAD = 16'hAA55 )( input wire clk, input wire rst_n, input wire [15:0] sample_data, // 来自采集逻辑 input wire sample_valid, output reg [31:0] m_axis_tdata, output reg [3:0] m_axis_tkeep, output reg m_axis_tvalid, input wire m_axis_tready, output reg m_axis_tlast ); // 状态：空闲 -> 发帧头 -> 发载荷 -> 发帧尾 localparam S_IDLE = 2'd0, S_HEAD = 2'd1, S_DATA = 2'd2, S_TAIL = 2'd3; reg [1:0] state; reg [15:0] cnt; // 载荷字节计数 reg [15:0] seq; // 帧序号，每帧递增 always @(posedge clk or negedge rst_n) begin if (!rst_n) begin state <= S_IDLE; cnt <= 0; seq <= 0; m_axis_tvalid <= 0; m_axis_tlast <= 0; end else begin case (state) S_IDLE: if (sample_valid) begin // 收到首个采样，进入发帧头状态 state <= S_HEAD; end S_HEAD: if (m_axis_tready) begin // 帧头+类型+长度+序号打包成一个 32bit 拍 m_axis_tdata <= {HEAD, 8'h01, PAYLOAD_LEN[15:0]}; m_axis_tvalid <= 1; state <= S_DATA; end S_DATA: if (m_axis_tready && m_axis_tvalid) begin // 逐拍输出载荷，cnt 计到 PAYLOAD_LEN 转帧尾 if (cnt == PAYLOAD_LEN - 1) state <= S_TAIL; else cnt <= cnt + 1; end S_TAIL: if (m_axis_tready) begin m_axis_tlast <= 1; // 标记帧结束 seq <= seq + 1; state <= S_IDLE; end endcase end end endmodule

这段代码是骨架，实际工程里还要补 FIFO 缓冲、校验计算和tkeep的按字节有效控制。设计说明有三点：第一，m_axis_tlast必须在帧尾那一拍拉高，DMA 靠它判断一次传输结束；第二，seq递增让上位机能发现丢帧，比事后对长度更直接；第三，状态机只在tready有效时推进，避免数据被覆盖——AXI-Stream 的握手规则不遵守，表现就是“偶尔少几个字节”，极难查。

4.3 FIFO 深度与背压处理

PL 采集是连续的，PS 发送是有间歇的，中间必须有 FIFO 吸收突发。FIFO 太浅，DMA 一忙就溢出丢数；太深，BRAM 不够用还增加延迟。经验值是：FIFO 深度 ≥ 一次 DMA 传输的突发长度 × 2，再留 20% 余量。同时要把 FIFO 的almost_full接到采集逻辑做背压，宁可让采集短暂停顿，也不能静默丢数据——静默丢数据是毕设答辩最容易被问倒的地方。

5. PS 端实现：DMA 搬运与 TCP 发送的闭环

5.1 AXI DMA 的配置与中断流程

PS 侧的第一件事是把 DMA 配起来。以裸机 lwIP 方案为例，典型流程是：初始化 DMA → 设置接收/发送通道 → 启动传输 → 等中断 → 处理数据 → 重新挂缓冲。关键参数是突发长度和缓冲对齐，下面是一段初始化示意：

// AXI DMA 发送通道初始化（裸机环境示意） #include "xaxidma.h" XAxiDma AxiDma; XAxiDma_Config *CfgPtr; int dma_init(u32 base_addr) { CfgPtr = XAxiDma_LookupConfig(base_addr); if (!CfgPtr) return -1; if (XAxiDma_CfgInitialize(&AxiDma, CfgPtr) != XST_SUCCESS) return -1; // 关闭散射聚集，使用简单模式，降低课设复杂度 if (XAxiDma_HasSg(&AxiDma)) return -1; // 使能发送完成中断，供 PS 侧轮询/中断处理 XAxiDma_IntrEnable(&AxiDma, XAXIDMA_IRQ_IOC_MASK, XAXIDMA_DMA_TO_DEVICE); return 0; } // 启动一次发送：buf 必须是物理连续且按 64B 对齐 int dma_send(u32 *buf, u32 len_bytes) { return XAxiDma_SimpleTransfer(&AxiDma, (UINTPTR)buf, len_bytes, XAXIDMA_DMA_TO_DEVICE); }

参数说明：base_addr是 DMA IP 在地址映射里的基地址，由 Vivado 地址编辑器分配；len_bytes必须是 4 的倍数，且缓冲要按缓存行对齐，否则 DMA 和 CPU 的 cache 一致性会出问题——这是裸机下最隐蔽的坑之一。中断掩码选IOC_MASK表示传输完成才触发，避免每拍都进中断拖垮 CPU。

5.2 lwIP 下的 TCP 发送循环

DMA 把数据搬进 DDR 后，PS 要把它塞进 TCP 连接。lwIP 裸机下通常用回调式 API，核心是把“有数据可发”和“连接可写”两个条件对齐：

// TCP 发送回调：连接建立后持续从环形缓冲取数据发送 static err_t tcp_sent_cb(void *arg, struct tcp_pcb *tpcb, u16_t len) { struct app_state *st = (struct app_state *)arg; st->acked += len; // 记录已确认字节，用于流控 return ERR_OK; } static err_t tcp_recv_cb(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { if (!p) { tcp_close(tpcb); return ERR_OK; } tcp_recved(tpcb, p->tot_len); // 必须调用，否则窗口不前进 pbuf_free(p); return ERR_OK; } // 主循环里：DMA 完成 -> 数据入环形缓冲 -> 尝试发送 void app_poll(struct app_state *st) { if (st->dma_done && st->conn_ok) { u16_t avail = tcp_sndbuf(st->pcb); // 当前可写空间 u16_t send_len = (avail < st->pending) ? avail : st->pending; if (send_len > 0) { tcp_write(st->pcb, st->ring + st->rd, send_len, TCP_WRITE_FLAG_COPY); tcp_output(st->pcb); // 立即推出去，降低时延 st->rd += send_len; st->pending -= send_len; } } }

这段代码的关键在tcp_sndbuf和tcp_recved两个调用：前者防止写超过发送窗口导致ERR_MEM，后者告诉协议栈“我处理完了，窗口可以前进”。很多同学只写tcp_write不查窗口，跑一会儿就卡死，现象是“发着发着不动了”，本质是发送窗口被自己堵死。

5.3 连接管理与异常重连

TCP 不是建一次就一劳永逸。上位机重启、网线插拔、对端异常关闭都会让连接失效。稳妥的做法是维护一个连接状态机：LISTEN → ESTABLISHED → CLOSING → LISTEN，在err回调里统一回到LISTEN重新tcp_accept。同时给发送加一个超时计数，连续 N 次tcp_output后acked不增长就主动tcp_abort重建。这套机制不复杂，但决定了系统能不能“无人值守跑一整晚”，答辩演示时尤其重要。

6. 避坑与排查：这条链路上最容易翻车的五个点

6.1 现象：上位机收到的数据错位、帧头找不到

原因：TCP 是字节流，recv返回的边界和 PL 的帧边界没有任何关系；如果上位机按“一次 recv 一帧”解析，必然错位。解决：上位机维护一个接收缓冲，按帧头 0xAA55 做滑动搜索，凑够“头 + 长度字段”后再取整帧，取完从缓冲删除。这是流式协议解析的标准做法，别偷懒。

6.2 现象：DMA 传输偶发失败或数据是旧值

原因：CPU 写缓冲后没做 cache flush，DMA 读到的是 cache 里的旧数据；或者缓冲没按 cache 行对齐，flush 时波及相邻数据。解决：发送前对缓冲执行Xil_DCacheFlushRange，接收后执行Xil_DCacheInvalidateRange，缓冲用memalign(64, size)分配。裸机下这一步漏了，故障就是随机的，极难复现。

6.3 现象：跑几分钟后发送卡死，tcp_write一直返回ERR_MEM

原因：只写不确认，发送窗口被占满；或者tcp_recved没调用，接收窗口不前进。解决：每次发送前查tcp_sndbuf，发送后在sent回调里累计acked；接收回调里必须调tcp_recved。把窗口当资源管理，而不是当无限缓冲。

6.4 现象：PL 采集正常，但 PS 侧收到的帧数偏少

原因：FIFO 溢出静默丢数，或 DMA 中断频率过高导致中断合并/丢失。解决：把 FIFO 的almost_full引到采集背压；DMA 一次传输尽量凑大（如 4 KB 以上），降低中断频率；在 PL 加一个溢出计数器，PS 定期读回，丢没丢一目了然。

6.5 现象：换一台电脑就连不上，或连上后很快断开

原因：IP 网段不匹配、防火墙拦截、或上位机没设SO_REUSEADDR导致端口占用。解决：固定 PS 端 IP 与上位机同网段，上位机绑定端口前设SO_REUSEADDR，调试期先关防火墙。这类问题不是代码错，是环境错，排查时先ping通再谈 TCP。

7. 验收与答辩：怎么证明这条链路真的通了

验收不是“演示时能看到数”就完事，要有可复现、可量化的证据。我一般按三层来验：功能层、性能层、稳定性层。

功能层看三件事：PL 帧头与长度字段是否自洽（用 ILA 抓 AXI-Stream 的tlast和tdata对照）；PS 发送字节数与上位机接收字节数是否一致（两端各打一个累计计数器）；上位机解析出的序号是否连续（不连续就是丢帧，定位到 FIFO 或 DMA）。这三项过了，链路算“通”。

性能层用一个简单办法：PL 端发已知图案（如递增计数），上位机统计 60 秒内的平均带宽和最大间隔。带宽接近理论值、最大间隔没有秒级空洞，说明背压和窗口管理是健康的。下面这段上位机统计逻辑可以直接用：

import socket, time, struct s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.connect(("192.168.1.10", 5001)) # PS 端 IP 与端口，按实际改 buf = b"" total = 0 t0 = time.time() last_rx = t0 max_gap = 0.0 while time.time() - t0 < 60: chunk = s.recv(65536) if not chunk: break now = time.time() max_gap = max(max_gap, now - last_rx) # 记录最大接收间隔 last_rx = now total += len(chunk) buf += chunk # 按帧头 0xAA55 滑动解析，凑够一帧就取出 while len(buf) >= 7: if buf[0:2] != b"\xAA\x55": buf = buf[1:] # 不同步就滑动一个字节 continue plen = struct.unpack("<H", buf[3:5])[0] if len(buf) < 7 + plen: break # 帧未收全，等下一批 frame, buf = buf[:7 + plen], buf[7 + plen:] # 此处做业务解析或落盘 print("带宽 Mbps:", total * 8 / 1e6 / 60, "最大间隔 s:", max_gap)

稳定性层最容易被忽略，也最能拉开差距：让系统连续跑 2 小时以上，中途拔插一次网线、重启一次上位机，观察能否自动重连并继续收数。能过这一关，答辩时被问“断线怎么办”就有底气。

答辩陈述我建议按“需求 → 架构 → 关键实现 → 实测数据 → 踩坑与解决”五段走，每段控制在两分钟内，重点讲你做的取舍而不是罗列模块。评委最爱问的三个问题通常是：为什么用 TCP 不用 UDP、DMA 和 CPU 拷贝差在哪、丢帧怎么定位——这三个答案在前面章节里都有，提前写成一句话备着。

从那以后我每次做这类跨 PL/PS 的传输项目，都会在动手写逻辑前先把帧格式和验收指标钉死，再倒推模块划分，因为返工最贵的从来不是写代码，而是协议没定就开干。希望帮到你。

本文还有配套的精品资源，点击获取