这次从零到一调通 Vitis 2023.1 LWIP Echo Server YT8521S 这套组合前后花了三天。第一感觉是Xilinx 官方 demo 本来就能跑通但一换成国产 PHY各种问题就冒出来了。这篇文章就把我在搭建中的那些弯路和经验拿出来分享一下尤其是在 YT8521S 调试上的心得。这个组合能解决什么问题简单说就是用一块带 ARM 内核的 Xilinx SoC常见的是 Zynq-7000 系列跑起轻量级 TCP/IP 协议栈 LWIP通过网络接口实现数据的接收、处理、回传。Echo Server 虽然看着简单但它验证了从处理器、DMA、MAC、PHY 到网线的完整链路是所有网络应用开发最可靠的起点。如果你正好在用 Vitis 2023.1或者手里有一颗 YT8521S 正愁调不通又或者只是想看看国产 PHY 和常用 PHY 在调试上到底有什么不同这篇内容都适合你。下面我按我的实际经历来写不按教程的套路来。1. 为什么非要在 Vitis 2023.1 上做 LWIP又为什么选了 YT8521S1.1 先讲清楚这套方案要解决什么问题其实在做这个工程之前我自己先列出过几个候选方案最简单的是直接用 Petalinux在 Linux 下面跑 Socket 服务硬件上基本不用自己操心。但为什么最后选回了 Vitis 裸机/轻量级 RTOS 呢因为两个原因首先Echo Server 的目标不只是“能通”而是要在一个尽量小的软件栈里把整个数据通路盘清楚。Linux 底下出了问题可能是驱动层的状态机也可能是 PHY 协商阶段的时序排查优先级永远是乱的。而在 Vitis 自带的 standalone BSP 下代码路径短寄存器和中断都是直接暴露的更容易定位问题是在 DMA、MAC 还是 PHY。其次Vitis 2023.1 这个版本对老 Zynq-7000 系列和 Zynq UltraScale 系列的支持都已经非常成熟LWIP 库也整合在 BSP 里不需要像早期版本那样手工移植。对于一个需要快速验证硬件、评估网络性能的项目来说这是最省时间的一条路。1.2 YT8521S 这颗国产 PHY 的角色选 YT8521S 并不是一开始就定下来的。之前用的 PHY 芯片主要是 Marvell 的 88E1512和 Xilinx 的 demo 配合度极好几乎零调试。但这两年供应和成本的考量大家都开始看国产 PHY。YT8521S 是裕太微出的单口千兆 PHY支持 SGMII/RGMII引脚可选配置也比较全在国产 PHY 里资料算相对完整的。不过它的坑在于很多调试经验是 Marvell 那套思维直接套在 YT8521S 上经常会卡住。比如 PHY 地址的默认值比如寄存器 0 的复位行为这些都跟国外老牌 PHY 有细微差别。所以这篇文章里我花了不少篇幅专门讲 YT8521S 的调试不是市面上随便一篇 LWIP 教程会覆盖的。从分类上看大家经常讨论“电压型和电流型 PHY”。简单说PHY 的接口驱动方式会直接影响硬件的端接电阻设计。以 RGMII 为例如果 PHY 内部没有内置端接或者端接是电流型输出那么板子外面需要并联/串联合适的电阻来保证信号完整性。YT8521S 的数据手册里一般会画出推荐电路但硬件工程师如果默认按普通 PHY 来画很可能漏掉某个下拉电阻于是调试时发现“偶尔通、重连就断”。这种问题用示波器看信号沿就能发现但在没测到之前真的很迷惑。2. 动手前的硬件梳理接口、时钟、复位都得先盘清楚2.1 GEM 与 PHY 的接口怎么配才不吵架Zynq 的 PS 端有好几个千兆以太网控制器GEM每个 GEM 可以接 RGMII 或者 SGMII。用 RGMII 时TX/RX 各 4 根数据线加上控制信号连接到 PHY 的 MAC 接口用 SGMII 时则是通过高速 SerDes 差分对走通常占用 PS 的 GT 资源。我在这个项目里用的是 SGMII 方式因为硬件设计上板端的走线更清爽但 SGMII 有个很重要的概念PHY 芯片和 MAC 之间的自动协商逻辑与普通 RGMII 不太一样。SGMII 接口上的速度协商本质上是 PHY 告诉 MAC“我对端协商出来的是多少兆”而 RGMII 模式下 MAC 基本是复用 PHY 的状态寄存器来决定收发时钟。这里就牵扯到那个大家常搜的说法SGMII IP 核与 PHY 芯片一起使用时应配置成 MAC 模式。严格说在 Vitis 的 BSP 配置里GEM 驱动对 SGMII 接口有一个自动协商开关这个开关应该打开让 PHY 在 SGMII 链路上主动向 MAC 广播速度与双工状态。如果这里配错成强制千兆模式就会出现一种非常诡异的现象PHY 对端显示协商 1000M 成功了但 MAC 侧却始终停在 10M 的速率上实际吞吐惨不忍睹。检查的时候确认 PHY Interface 是不是和硬件一致以及 SGMII 的 auto-neg 是否开启。2.2 时钟和复位最容易背锅的两个“稻草人”以太网 PHY 的时钟分两类一是 PHY 内部所需的参考时钟二是 MAC 侧的参考时钟。RGMII 模式下通常需要 MAC 提供给 PHY 一个 125MHz 的参考时钟或反过来SGMII 模式下一般需要给 PHY 提供 125MHz 的参考时钟再通过 GT 内部 PLL 处理。时钟频率不对或相噪差PHY 能起来但眼图质量会崩。复位的坑通常更隐蔽。YT8521S 要求上电后至少保持一段时间的复位低脉冲然后拉高再等内部初始化完成。如果 SGMII 模式下一次复位后 PHY 的 SGMII 端自适应可能需要几百毫秒才能完成这时候去读状态寄存器就会读到 link down。这不是 PHY 坏了是时序没等够。用 Vivado 的 Hardware Manager 去复位 PS 端时经常会把 GEM 的复位一起拉下来然后立刻读 PHY结果自然是不通的。我的建议是硬件上确认 RESET 引脚有 RC 延迟或由 PS 的 MIO 控制软件调试时在初始化代码中加一段延时200ms 到 500ms 都很常见再初始化 LWIP 协议栈。2.3 在 Vivado 里生成硬件平台时的三个检查点这一步虽然是在 Vitis 里写代码但硬件平台的质量决定后面调试的顺不顺。我在生成 xsa 文件时吃过三个亏第一PS 端 GEM 的中断必须在 Vivado 里使能并连接到 GIC通用中断控制器。否则 Vitis 里代码就算跑起来收包没有任何中断回调函数永远不触发。第二MDIO 时钟必须合理。GEM 的 MDC 时钟是通过分频得到的在 Vivado 里有配置项默认值在 100MHz 下可能偏快导致 MDIO 读写不稳定。建议配置到 2.5MHz 左右老式 PHY 的上限或 5MHz 以内这种配置对国产 PHY 尤其友好。第三如果调试引脚占用了 JTAG 或 EMIO下载阶段可能提示无法识别芯片这也是很多人第一次接触 Vitis 就卡住的地方。我遇到过一直提示找不到设备最后发现是硬件上 JTAG 菊花链上的另一个器件配置了错误的电压。Vitis 无法识别芯片时别急着怪软件先用 Vivado Hardware Manager 扫一下设备树看看是不是连设备都枚举不到。3. Echo Server 建工程从 xsa 导入到 lwIP 库加载3.1 Vitis 2023.1 创建应用的完整步骤在 Vitis 2023.1 里流程其实已经简化到几步之内用 Vivado 生成硬件平台以后.xsa 文件在 Vitis 里选择 File - Platform - Create Platform Project导入这个 xsa。在 platform 工程上右键 Build然后把 platform 设为 active。File - Application Project选择刚刚的 platform名字随意例如 lwip_echo。在模板选择界面有几个和 LWIP 相关的模板lwIP Echo Server、lwIP HTTP Server 等。选 lwIP Echo Server。这里有个容易忽略的点Vitis 2023.1 里平台工程和应用工程的 BSP 是分开的。如果之后你在 system.mss 里改了 LWIP 的配置必须先在应用工程里把 BSP 重新编译一次再把整个应用工程 rebuild。很多人直接点 run结果发现改动没有生效其实是被缓存的旧库坑了。3.2 在 BSP 里设置 PHY 地址、速度等关键参数Vitis 的 platform 工程里会生成一个 BSP里面包含了 standalone 操作系统的设置。找到 system.mss展开 lwip141不同版本号可能叫 lwip220 之类你能看到一堆配置项但最重要的其实就两个PHY 地址和 link 速度。PHY 地址不是随便写的。YT8521S 的 PHY 地址由硬件上的 PHYAD 引脚决定常见是 0x01 或 0x03。如果 BSP 的默认 PHY 地址跟你的实际硬件对不上真机测试时读不到 PHY ID表现出来的症状跟“PHY 坏了”几乎一样。我在调试时就花了半天不断怀疑 PHY 芯片最后才想到去看引脚默认地址。link 速度选项一般有三种10M、100M、1000M。对 YT8521S 这类千兆 PHY如果硬件没有特别限制就直接用 AUTO。但注意如果你在 SGMII 模式下还强行把 MAC 侧速度配成 1000M而 PHY 对端只能协商到 100M那收发就永远对不上。BSP 里的配置一定要遵循“接口模式 自动协商优先级最高”的原则。另外BSP 里还有一个可选参数叫 PHY link speed有的版本也叫 phy_link_speed。我之前试过把它手动改成 1000以为这样能强制千兆结果在 SGMII 模式下反而破坏了 PHY 和 MAC 的握手。所以除非你明确知道强制速率的意义否则一律 AUTO。3.3 Echo Server 代码逻辑逐段看Vitis 的 lwIP Echo Server 模板本身已经能跑但代码很短我建议还是自己读一遍核心逻辑。初始化顺序一般是lwip_init(); // 协议栈内部初始化 netif_add(netif, ipaddr, netmask, gateway, NULL, ethernetif_init, ethernet_input); netif_set_default(netif); netif_set_up(netif);然后会启动一个 echo 任务的循环。这个任务的核心就是int sock lwip_socket(AF_INET, SOCK_STREAM, 0); lwip_bind(sock, (struct sockaddr *)server_addr, sizeof(server_addr)); lwip_listen(sock, 0); while (1) { int client_sock lwip_accept(sock, (struct sockaddr *)client_addr, client_len); // 收到数据之后原样发回 len lwip_recv(client_sock, buffer, sizeof(buffer), 0); if (len 0) { lwip_send(client_sock, buffer, len, 0); } lwip_close(client_sock); }这个循环看似简单但对初学者来说真正容易翻车的地方在于端口号和地址绑定。Zynq 默认网口的 IP 地址如果不符合你的测试网段你需要直接在 netif 配置那里改掉或者做好 DHCP。Echo 端口一般是 7echo 协议默认端口Vitis 模板里可能直接用 7但如果你在路由器环境测试某些交换机或操作系统可能屏蔽 7 端口建议先改成 5001 或 8000 来验证。我在这阶段有个小技巧先不管 echo 逻辑直接用 ping 验证链路层通不通。如果 ping 不通就不要盲目去查 socket 代码。如果 ping 通了但 echo 服务不响应多半是应用层的 socket 绑定或线程调度问题。4. YT8521S PHY 调试日记三天排查全复盘4.1 调试前的工具集和自检顺序我个人建议的开发调试工具一根能看链路状态的网线 一台千兆交换机带 VLAN 管理更佳串口终端用来观察 LWIP 启动日志Vivado/Vitis 的 Hardware Manager可以扫描 JTAG 设备如果平台支持用 ILA 抓取 MDIO/MDC 波形定位物理层访问问题拿到一块新板子我不会直接跑 LWIP而是先执行一个“自检三步走”第一步用万用表确认 PHY 的电源电压和电源纹波第二步确认复位释放之后的 PHY 时钟用示波器测量参考时钟是否稳定第三步用 MDIO 去读 PHY 的寄存器 0x02、0x03确认能不能拿到 PHY 的 ID。只有这三步全部通过才会进到协议栈调试。这个自检方法帮我节省了大量时间因为很多看起来像协议栈的问题其实是硬件连不到 PHY。4.2 第一道坎MDIO 读不到 PHY ID先说现象代码跑起来驱动初始化时报了一个类似 “PHY address not responding” 的错误然后在串口上看到一系列 PHY read timeout。排查思路先确认 MDC 和 MDIO 引脚是不是真的连到了 PHY。不少集成板为了少走线会用一个电平转换芯片把 MDIO 信号切出去如果这个芯片的方向控制脚配置错了读出来的就全是 0xFFFF。确认 MDIO 地址。YT8521S 的地址引脚在不同板上绑定方式不同。直接在 Vivado 的 Hardware Manager 里通过 MDIO 遍历一下地址 0~31看哪个地址有 ACK。这种遍历方式比反复改代码要快十几倍。确认 MDC 频率。前面说过MDC 分频太高会无法访问 PHY建议调到 2.5MHz 以下。如果这三点都查过还是读不到那就需要考虑硬件层的问题比如 PHY 没有正常从复位状态退出。YT8521S 的 RESET 脚如果悬空某些批次会一直处于不定态表现为上电后 MDIO 时而能读、时而不能读。这种时候软件就更加需要用代码保证延时。4.3 第二道坎Link 状态反复横跳MDIO 通了之后PHY ID 也读对了但串口日志里频繁打 Link Up 然后 Link Down非常不确定。这个阶段的第一反应是检查对端设备和网线但很多时候对端设备是好的。我后来发现问题出在 PHY 的自动协商状态机没有收到稳定信号。有几个可能的原因对端设备强制了速度但 YT8521S 这边配置成了自动协商两边商定不下来。SGMII 模式下MAC 与 PHY 之间的 auto-neg 没有同步。GEM 驱动会周期性地向 PHY 请求 SGMII 状态如果 PHY 在 SGMII 握手之前就把 link 状态报告为 up随后又会因为 SGMII 链路不稳定报 down。供电不稳也会导致 PHY 内部 PLL 频繁失锁表现为每几秒钟 link 抖一次。用示波器看 PHY 供电引脚纹波超过 50mV 就要引起注意。排查顺序是先强制两边成相同的速率比如都强制 100M 全双工试试 link 是否会稳定如果稳定再切回自动协商看是不是协商状态机的问题。如果强制模式下依然不稳就要查供电和时钟。4.4 第三道坎能 Link 但是 Ping 不通这个问题是最磨人的。PHY 已经 Link Up状态寄存器也显示 1000M 全双工但主机那边 ping 永远 timeout。排查这一层要先把问题分成两个方向MAC 收不到包还是 MAC 发不出包。如果是 MAC 收不到包检查接收侧的 DMA 描述符是否初始化正确以及 RX 中断是否挂到了正确的中断控制器和优先级。常见错误是描述符环配置错误导致驱动走到某个位置就停摆。如果是 MAC 发不出包检查 TX 描述符的 ownership 位是否被正确清零以及 PHY 的 TX_CLK 是否正常。我见过一个案例由于 PHY 的 TX 方向时钟在 SGMII 模式下没有对齐MAC 发出的包实际上根本没到网线上。缓存一致性是另一个高频问题。Zynq 的 standalone BSP 一般会为 DMA 缓冲区处理好 cache 操作但如果你自己申请缓冲区并直接传给网卡没有调用Xil_DCacheFlush()或Xil_DCacheInvalidate()就可能出现“发出去的数据是旧的收进来的数据是脏的”这种灵异现象。解决方法是给网卡驱动使用 cache 一致性内存区域或者每次收发都显式刷 cache。另外不要忘记 ARP。第一次 ping 不通先抓一下 ARP 包看有没有响应。如果 ARP 都没有基本就是链路层或 IP 层配置问题。如果 ARP 有但 ping 的 ICMP request 没有回应就要去查 echo 应用的 recv 和 send 是否成对。4.5 YT8521S 特有的时序与配置留意点抛开通用 PHY 的调试逻辑YT8521S 这颗芯片在调试时还有几个地方我会专门留意芯片内部有多个电源域上电顺序不能乱。如果硬件上把 AVDDH、DVDD 这些共用一个电源而没有做时序控制芯片可能进入一个异常状态MDIO 能读但同步信号异常。这个要跟硬件规格书对。寄存器的默认配置不一定适合你的板子。我遇到过一次默认的 LED 配置占用了某些控制引脚导致 PHY 工作模式被改。要是遇到不可解释的行为先恢复一下寄存器 0 的软件复位等内部重新配置完成再继续。在 SGMII 模式YT8521S 支持通过寄存器关闭 SGMII 自动协商直接强制成 1000M 或者 100M。虽然这样能绕过某些协商问题但代价是 MAC 侧必须与 PHY 侧配置一致否则出现能发不能收或能收不能发。所以除非你非常确定否则建议保持 SGMII 自动协商打开。5. 跑通之后的实测数据与工程扩展思路5.1 一个“能用”的 Echo Server 应该达到什么水准在 Zynq-7000 667MHz 主频加上千兆 PHY 的情况下跑 LWIP Echo Server 的实测回环吞吐量大约可以到 600Mbps 以上瓶颈主要在协议栈和 CPU 频率而不是 PHY。测试工具用 iperf 或自写的 socket 客户端只要不丢包延迟在毫秒级这个 Echo Server 就算真正及格了。如果测出来吞吐只有几十兆别急着优化协议栈先看是不是链路协商到了百兆甚至十兆。用 iperf 测试之前确认 PHY 状态寄存器显示的 speed 是 1000 而不是 100这一步能过滤掉一大半问题。Echo 场景里还有一个隐形的性能杀手每次 recv 后重新 sendCPU 的开销会很大。如果主要目的是验证链路没太大问题如果想跑到接近线速建议直接使用 RAW APIpbuf模式或者把 echo 逻辑改成零拷贝式的数据块回传。5.2 从 Echo 到业务协议栈的改造建议在实际项目中Echo Server 一般只是入口。常见的改动方向是把 echo 逻辑替换成自定义应用层协议比如 Modbus TCP、MQTT、HTTP或者私有二进制协议。把单线程 accept/recv/send 改成多线程或 select 模型提升并发能力。用 FreeRTOS 代替 standalone把网络任务与采集任务分离保证业务中断不会误伤协议栈。从我个人经验来看Echo Server 跑通后最值得做的一步是用 Wireshark 抓一次完整的 TCP 三次握手和回显数据帧。这个动作能让你对 LWIP 的 socket 行为有非常直观的认识不是看代码能替代的。5.3 该考虑引入 LWIP 的哪些进阶特性如果你的业务对实时性有要求可以考虑这几个方向使能 LWIP_DHCP快速接入现网而不固定 IP。开启 LWIP_DNS支持域名解析。调整 TCP 窗口大小和重传超时改善长距离链路的吞吐。使用内存池而不是内存堆来管理 pbuf避免长时间运行后内存碎片化。我不建议在一开始就全部打开这些特性那样调试难度会指数级上升。先把最简单的 Echo 跑到稳定再逐步叠加功能。6. 调试经验之外的几条“软建议”6.1 我在调试时积累的三条自查习惯第一改任何配置之前做一次三要素快照硬件上确认电源、时钟、复位软件上确认 PHY 地址、接口模式、BSP 配置。每一条都对照一遍往往能快速定位。第二把串口日志分成“链路层日志”和“应用层日志”。链路层只看 MAC/PHY 状态应用层只看 TCP/echo 结果不要混在一起。调试时精神压力大日志清晰是效率救星。第三遇到 Vitis 下载调试提示不识别芯片先查 Hardware Manager 里的 JTAG 链再查调试器驱动不要反复烧录浪费时间。我见过有人烧了十几次最后发现是板子 JTAG 电压被省掉了这个坑和 PHY 无关但同样会让你心态崩。6.2 国产 PHY 和常见 Marvell PHY 在调试上的差异拿 YT8521S 和 88E1512 对比我的体感是88E1512 的驱动成熟Vitis 的 BSP 里默认支持度很高几乎不用改。YT8521S 需要更多手工调寄存器但数据手册和配套文档相对容易获取芯片的设计思路也符合主流 PHY 规范所以只要方法对调试并不难。两者的自动协商行为有细微差别但底层都是 802.3 标准所以务必先把标准行为吃掉再研究厂商差异。如果是小批量产品我建议直接用官方 demo 验证一遍你的 PHY 型号再投入应用层开发。这种方案花的时间最低风险也最低。6.3 低成本高效率的自测小工具当你没有专业网络分析仪也可以准备一台普通 PC 加 Wireshark抓包调试 TCP/IP 行为一个 USB 转 Ethernet 的千兆网卡用于隔离 PC 主板网卡的底层机制差异一根经过验证的标准 CAT6 网线优先排除线序和屏蔽问题。网络调试很多时候是“排到最后发现网线是坏的”所以这些基础工具千万别忽略。我在这次调 YT8521S 之前也曾经觉得 PHY 调试是最磨人的一环。但三天下来最大的收获其实不是 echo 通了而是建立了一套“先链路层、后网络层、再应用层”的排查方法。这套方法在后来调试别的 PHY 和网卡芯片时依然有效。如果你正在被类似的问题卡住建议从我说的第一步“拿 MDIO 读 PHY ID”开始一步一步走大多数问题都是纸老虎。 
长河君 · 2026/9/21 1:22:42 · 阅读 1.2k Vitis 2023.1下LWIP Echo Server与YT8521S PHY调试全攻略
这次从零到一调通 Vitis 2023.1 LWIP Echo Server YT8521S 这套组合前后花了三天。第一感觉是Xilinx 官方 demo 本来就能跑通但一换成国产 PHY各种问题就冒出来了。这篇文章就把我在搭建中的那些弯路和经验拿出来分享一下尤其是在 YT8521S 调试上的心得。这个组合能解决什么问题简单说就是用一块带 ARM 内核的 Xilinx SoC常见的是 Zynq-7000 系列跑起轻量级 TCP/IP 协议栈 LWIP通过网络接口实现数据的接收、处理、回传。Echo Server 虽然看着简单但它验证了从处理器、DMA、MAC、PHY 到网线的完整链路是所有网络应用开发最可靠的起点。如果你正好在用 Vitis 2023.1或者手里有一颗 YT8521S 正愁调不通又或者只是想看看国产 PHY 和常用 PHY 在调试上到底有什么不同这篇内容都适合你。下面我按我的实际经历来写不按教程的套路来。1. 为什么非要在 Vitis 2023.1 上做 LWIP又为什么选了 YT8521S1.1 先讲清楚这套方案要解决什么问题其实在做这个工程之前我自己先列出过几个候选方案最简单的是直接用 Petalinux在 Linux 下面跑 Socket 服务硬件上基本不用自己操心。但为什么最后选回了 Vitis 裸机/轻量级 RTOS 呢因为两个原因首先Echo Server 的目标不只是“能通”而是要在一个尽量小的软件栈里把整个数据通路盘清楚。Linux 底下出了问题可能是驱动层的状态机也可能是 PHY 协商阶段的时序排查优先级永远是乱的。而在 Vitis 自带的 standalone BSP 下代码路径短寄存器和中断都是直接暴露的更容易定位问题是在 DMA、MAC 还是 PHY。其次Vitis 2023.1 这个版本对老 Zynq-7000 系列和 Zynq UltraScale 系列的支持都已经非常成熟LWIP 库也整合在 BSP 里不需要像早期版本那样手工移植。对于一个需要快速验证硬件、评估网络性能的项目来说这是最省时间的一条路。1.2 YT8521S 这颗国产 PHY 的角色选 YT8521S 并不是一开始就定下来的。之前用的 PHY 芯片主要是 Marvell 的 88E1512和 Xilinx 的 demo 配合度极好几乎零调试。但这两年供应和成本的考量大家都开始看国产 PHY。YT8521S 是裕太微出的单口千兆 PHY支持 SGMII/RGMII引脚可选配置也比较全在国产 PHY 里资料算相对完整的。不过它的坑在于很多调试经验是 Marvell 那套思维直接套在 YT8521S 上经常会卡住。比如 PHY 地址的默认值比如寄存器 0 的复位行为这些都跟国外老牌 PHY 有细微差别。所以这篇文章里我花了不少篇幅专门讲 YT8521S 的调试不是市面上随便一篇 LWIP 教程会覆盖的。从分类上看大家经常讨论“电压型和电流型 PHY”。简单说PHY 的接口驱动方式会直接影响硬件的端接电阻设计。以 RGMII 为例如果 PHY 内部没有内置端接或者端接是电流型输出那么板子外面需要并联/串联合适的电阻来保证信号完整性。YT8521S 的数据手册里一般会画出推荐电路但硬件工程师如果默认按普通 PHY 来画很可能漏掉某个下拉电阻于是调试时发现“偶尔通、重连就断”。这种问题用示波器看信号沿就能发现但在没测到之前真的很迷惑。2. 动手前的硬件梳理接口、时钟、复位都得先盘清楚2.1 GEM 与 PHY 的接口怎么配才不吵架Zynq 的 PS 端有好几个千兆以太网控制器GEM每个 GEM 可以接 RGMII 或者 SGMII。用 RGMII 时TX/RX 各 4 根数据线加上控制信号连接到 PHY 的 MAC 接口用 SGMII 时则是通过高速 SerDes 差分对走通常占用 PS 的 GT 资源。我在这个项目里用的是 SGMII 方式因为硬件设计上板端的走线更清爽但 SGMII 有个很重要的概念PHY 芯片和 MAC 之间的自动协商逻辑与普通 RGMII 不太一样。SGMII 接口上的速度协商本质上是 PHY 告诉 MAC“我对端协商出来的是多少兆”而 RGMII 模式下 MAC 基本是复用 PHY 的状态寄存器来决定收发时钟。这里就牵扯到那个大家常搜的说法SGMII IP 核与 PHY 芯片一起使用时应配置成 MAC 模式。严格说在 Vitis 的 BSP 配置里GEM 驱动对 SGMII 接口有一个自动协商开关这个开关应该打开让 PHY 在 SGMII 链路上主动向 MAC 广播速度与双工状态。如果这里配错成强制千兆模式就会出现一种非常诡异的现象PHY 对端显示协商 1000M 成功了但 MAC 侧却始终停在 10M 的速率上实际吞吐惨不忍睹。检查的时候确认 PHY Interface 是不是和硬件一致以及 SGMII 的 auto-neg 是否开启。2.2 时钟和复位最容易背锅的两个“稻草人”以太网 PHY 的时钟分两类一是 PHY 内部所需的参考时钟二是 MAC 侧的参考时钟。RGMII 模式下通常需要 MAC 提供给 PHY 一个 125MHz 的参考时钟或反过来SGMII 模式下一般需要给 PHY 提供 125MHz 的参考时钟再通过 GT 内部 PLL 处理。时钟频率不对或相噪差PHY 能起来但眼图质量会崩。复位的坑通常更隐蔽。YT8521S 要求上电后至少保持一段时间的复位低脉冲然后拉高再等内部初始化完成。如果 SGMII 模式下一次复位后 PHY 的 SGMII 端自适应可能需要几百毫秒才能完成这时候去读状态寄存器就会读到 link down。这不是 PHY 坏了是时序没等够。用 Vivado 的 Hardware Manager 去复位 PS 端时经常会把 GEM 的复位一起拉下来然后立刻读 PHY结果自然是不通的。我的建议是硬件上确认 RESET 引脚有 RC 延迟或由 PS 的 MIO 控制软件调试时在初始化代码中加一段延时200ms 到 500ms 都很常见再初始化 LWIP 协议栈。2.3 在 Vivado 里生成硬件平台时的三个检查点这一步虽然是在 Vitis 里写代码但硬件平台的质量决定后面调试的顺不顺。我在生成 xsa 文件时吃过三个亏第一PS 端 GEM 的中断必须在 Vivado 里使能并连接到 GIC通用中断控制器。否则 Vitis 里代码就算跑起来收包没有任何中断回调函数永远不触发。第二MDIO 时钟必须合理。GEM 的 MDC 时钟是通过分频得到的在 Vivado 里有配置项默认值在 100MHz 下可能偏快导致 MDIO 读写不稳定。建议配置到 2.5MHz 左右老式 PHY 的上限或 5MHz 以内这种配置对国产 PHY 尤其友好。第三如果调试引脚占用了 JTAG 或 EMIO下载阶段可能提示无法识别芯片这也是很多人第一次接触 Vitis 就卡住的地方。我遇到过一直提示找不到设备最后发现是硬件上 JTAG 菊花链上的另一个器件配置了错误的电压。Vitis 无法识别芯片时别急着怪软件先用 Vivado Hardware Manager 扫一下设备树看看是不是连设备都枚举不到。3. Echo Server 建工程从 xsa 导入到 lwIP 库加载3.1 Vitis 2023.1 创建应用的完整步骤在 Vitis 2023.1 里流程其实已经简化到几步之内用 Vivado 生成硬件平台以后.xsa 文件在 Vitis 里选择 File - Platform - Create Platform Project导入这个 xsa。在 platform 工程上右键 Build然后把 platform 设为 active。File - Application Project选择刚刚的 platform名字随意例如 lwip_echo。在模板选择界面有几个和 LWIP 相关的模板lwIP Echo Server、lwIP HTTP Server 等。选 lwIP Echo Server。这里有个容易忽略的点Vitis 2023.1 里平台工程和应用工程的 BSP 是分开的。如果之后你在 system.mss 里改了 LWIP 的配置必须先在应用工程里把 BSP 重新编译一次再把整个应用工程 rebuild。很多人直接点 run结果发现改动没有生效其实是被缓存的旧库坑了。3.2 在 BSP 里设置 PHY 地址、速度等关键参数Vitis 的 platform 工程里会生成一个 BSP里面包含了 standalone 操作系统的设置。找到 system.mss展开 lwip141不同版本号可能叫 lwip220 之类你能看到一堆配置项但最重要的其实就两个PHY 地址和 link 速度。PHY 地址不是随便写的。YT8521S 的 PHY 地址由硬件上的 PHYAD 引脚决定常见是 0x01 或 0x03。如果 BSP 的默认 PHY 地址跟你的实际硬件对不上真机测试时读不到 PHY ID表现出来的症状跟“PHY 坏了”几乎一样。我在调试时就花了半天不断怀疑 PHY 芯片最后才想到去看引脚默认地址。link 速度选项一般有三种10M、100M、1000M。对 YT8521S 这类千兆 PHY如果硬件没有特别限制就直接用 AUTO。但注意如果你在 SGMII 模式下还强行把 MAC 侧速度配成 1000M而 PHY 对端只能协商到 100M那收发就永远对不上。BSP 里的配置一定要遵循“接口模式 自动协商优先级最高”的原则。另外BSP 里还有一个可选参数叫 PHY link speed有的版本也叫 phy_link_speed。我之前试过把它手动改成 1000以为这样能强制千兆结果在 SGMII 模式下反而破坏了 PHY 和 MAC 的握手。所以除非你明确知道强制速率的意义否则一律 AUTO。3.3 Echo Server 代码逻辑逐段看Vitis 的 lwIP Echo Server 模板本身已经能跑但代码很短我建议还是自己读一遍核心逻辑。初始化顺序一般是lwip_init(); // 协议栈内部初始化 netif_add(netif, ipaddr, netmask, gateway, NULL, ethernetif_init, ethernet_input); netif_set_default(netif); netif_set_up(netif);然后会启动一个 echo 任务的循环。这个任务的核心就是int sock lwip_socket(AF_INET, SOCK_STREAM, 0); lwip_bind(sock, (struct sockaddr *)server_addr, sizeof(server_addr)); lwip_listen(sock, 0); while (1) { int client_sock lwip_accept(sock, (struct sockaddr *)client_addr, client_len); // 收到数据之后原样发回 len lwip_recv(client_sock, buffer, sizeof(buffer), 0); if (len 0) { lwip_send(client_sock, buffer, len, 0); } lwip_close(client_sock); }这个循环看似简单但对初学者来说真正容易翻车的地方在于端口号和地址绑定。Zynq 默认网口的 IP 地址如果不符合你的测试网段你需要直接在 netif 配置那里改掉或者做好 DHCP。Echo 端口一般是 7echo 协议默认端口Vitis 模板里可能直接用 7但如果你在路由器环境测试某些交换机或操作系统可能屏蔽 7 端口建议先改成 5001 或 8000 来验证。我在这阶段有个小技巧先不管 echo 逻辑直接用 ping 验证链路层通不通。如果 ping 不通就不要盲目去查 socket 代码。如果 ping 通了但 echo 服务不响应多半是应用层的 socket 绑定或线程调度问题。4. YT8521S PHY 调试日记三天排查全复盘4.1 调试前的工具集和自检顺序我个人建议的开发调试工具一根能看链路状态的网线 一台千兆交换机带 VLAN 管理更佳串口终端用来观察 LWIP 启动日志Vivado/Vitis 的 Hardware Manager可以扫描 JTAG 设备如果平台支持用 ILA 抓取 MDIO/MDC 波形定位物理层访问问题拿到一块新板子我不会直接跑 LWIP而是先执行一个“自检三步走”第一步用万用表确认 PHY 的电源电压和电源纹波第二步确认复位释放之后的 PHY 时钟用示波器测量参考时钟是否稳定第三步用 MDIO 去读 PHY 的寄存器 0x02、0x03确认能不能拿到 PHY 的 ID。只有这三步全部通过才会进到协议栈调试。这个自检方法帮我节省了大量时间因为很多看起来像协议栈的问题其实是硬件连不到 PHY。4.2 第一道坎MDIO 读不到 PHY ID先说现象代码跑起来驱动初始化时报了一个类似 “PHY address not responding” 的错误然后在串口上看到一系列 PHY read timeout。排查思路先确认 MDC 和 MDIO 引脚是不是真的连到了 PHY。不少集成板为了少走线会用一个电平转换芯片把 MDIO 信号切出去如果这个芯片的方向控制脚配置错了读出来的就全是 0xFFFF。确认 MDIO 地址。YT8521S 的地址引脚在不同板上绑定方式不同。直接在 Vivado 的 Hardware Manager 里通过 MDIO 遍历一下地址 0~31看哪个地址有 ACK。这种遍历方式比反复改代码要快十几倍。确认 MDC 频率。前面说过MDC 分频太高会无法访问 PHY建议调到 2.5MHz 以下。如果这三点都查过还是读不到那就需要考虑硬件层的问题比如 PHY 没有正常从复位状态退出。YT8521S 的 RESET 脚如果悬空某些批次会一直处于不定态表现为上电后 MDIO 时而能读、时而不能读。这种时候软件就更加需要用代码保证延时。4.3 第二道坎Link 状态反复横跳MDIO 通了之后PHY ID 也读对了但串口日志里频繁打 Link Up 然后 Link Down非常不确定。这个阶段的第一反应是检查对端设备和网线但很多时候对端设备是好的。我后来发现问题出在 PHY 的自动协商状态机没有收到稳定信号。有几个可能的原因对端设备强制了速度但 YT8521S 这边配置成了自动协商两边商定不下来。SGMII 模式下MAC 与 PHY 之间的 auto-neg 没有同步。GEM 驱动会周期性地向 PHY 请求 SGMII 状态如果 PHY 在 SGMII 握手之前就把 link 状态报告为 up随后又会因为 SGMII 链路不稳定报 down。供电不稳也会导致 PHY 内部 PLL 频繁失锁表现为每几秒钟 link 抖一次。用示波器看 PHY 供电引脚纹波超过 50mV 就要引起注意。排查顺序是先强制两边成相同的速率比如都强制 100M 全双工试试 link 是否会稳定如果稳定再切回自动协商看是不是协商状态机的问题。如果强制模式下依然不稳就要查供电和时钟。4.4 第三道坎能 Link 但是 Ping 不通这个问题是最磨人的。PHY 已经 Link Up状态寄存器也显示 1000M 全双工但主机那边 ping 永远 timeout。排查这一层要先把问题分成两个方向MAC 收不到包还是 MAC 发不出包。如果是 MAC 收不到包检查接收侧的 DMA 描述符是否初始化正确以及 RX 中断是否挂到了正确的中断控制器和优先级。常见错误是描述符环配置错误导致驱动走到某个位置就停摆。如果是 MAC 发不出包检查 TX 描述符的 ownership 位是否被正确清零以及 PHY 的 TX_CLK 是否正常。我见过一个案例由于 PHY 的 TX 方向时钟在 SGMII 模式下没有对齐MAC 发出的包实际上根本没到网线上。缓存一致性是另一个高频问题。Zynq 的 standalone BSP 一般会为 DMA 缓冲区处理好 cache 操作但如果你自己申请缓冲区并直接传给网卡没有调用Xil_DCacheFlush()或Xil_DCacheInvalidate()就可能出现“发出去的数据是旧的收进来的数据是脏的”这种灵异现象。解决方法是给网卡驱动使用 cache 一致性内存区域或者每次收发都显式刷 cache。另外不要忘记 ARP。第一次 ping 不通先抓一下 ARP 包看有没有响应。如果 ARP 都没有基本就是链路层或 IP 层配置问题。如果 ARP 有但 ping 的 ICMP request 没有回应就要去查 echo 应用的 recv 和 send 是否成对。4.5 YT8521S 特有的时序与配置留意点抛开通用 PHY 的调试逻辑YT8521S 这颗芯片在调试时还有几个地方我会专门留意芯片内部有多个电源域上电顺序不能乱。如果硬件上把 AVDDH、DVDD 这些共用一个电源而没有做时序控制芯片可能进入一个异常状态MDIO 能读但同步信号异常。这个要跟硬件规格书对。寄存器的默认配置不一定适合你的板子。我遇到过一次默认的 LED 配置占用了某些控制引脚导致 PHY 工作模式被改。要是遇到不可解释的行为先恢复一下寄存器 0 的软件复位等内部重新配置完成再继续。在 SGMII 模式YT8521S 支持通过寄存器关闭 SGMII 自动协商直接强制成 1000M 或者 100M。虽然这样能绕过某些协商问题但代价是 MAC 侧必须与 PHY 侧配置一致否则出现能发不能收或能收不能发。所以除非你非常确定否则建议保持 SGMII 自动协商打开。5. 跑通之后的实测数据与工程扩展思路5.1 一个“能用”的 Echo Server 应该达到什么水准在 Zynq-7000 667MHz 主频加上千兆 PHY 的情况下跑 LWIP Echo Server 的实测回环吞吐量大约可以到 600Mbps 以上瓶颈主要在协议栈和 CPU 频率而不是 PHY。测试工具用 iperf 或自写的 socket 客户端只要不丢包延迟在毫秒级这个 Echo Server 就算真正及格了。如果测出来吞吐只有几十兆别急着优化协议栈先看是不是链路协商到了百兆甚至十兆。用 iperf 测试之前确认 PHY 状态寄存器显示的 speed 是 1000 而不是 100这一步能过滤掉一大半问题。Echo 场景里还有一个隐形的性能杀手每次 recv 后重新 sendCPU 的开销会很大。如果主要目的是验证链路没太大问题如果想跑到接近线速建议直接使用 RAW APIpbuf模式或者把 echo 逻辑改成零拷贝式的数据块回传。5.2 从 Echo 到业务协议栈的改造建议在实际项目中Echo Server 一般只是入口。常见的改动方向是把 echo 逻辑替换成自定义应用层协议比如 Modbus TCP、MQTT、HTTP或者私有二进制协议。把单线程 accept/recv/send 改成多线程或 select 模型提升并发能力。用 FreeRTOS 代替 standalone把网络任务与采集任务分离保证业务中断不会误伤协议栈。从我个人经验来看Echo Server 跑通后最值得做的一步是用 Wireshark 抓一次完整的 TCP 三次握手和回显数据帧。这个动作能让你对 LWIP 的 socket 行为有非常直观的认识不是看代码能替代的。5.3 该考虑引入 LWIP 的哪些进阶特性如果你的业务对实时性有要求可以考虑这几个方向使能 LWIP_DHCP快速接入现网而不固定 IP。开启 LWIP_DNS支持域名解析。调整 TCP 窗口大小和重传超时改善长距离链路的吞吐。使用内存池而不是内存堆来管理 pbuf避免长时间运行后内存碎片化。我不建议在一开始就全部打开这些特性那样调试难度会指数级上升。先把最简单的 Echo 跑到稳定再逐步叠加功能。6. 调试经验之外的几条“软建议”6.1 我在调试时积累的三条自查习惯第一改任何配置之前做一次三要素快照硬件上确认电源、时钟、复位软件上确认 PHY 地址、接口模式、BSP 配置。每一条都对照一遍往往能快速定位。第二把串口日志分成“链路层日志”和“应用层日志”。链路层只看 MAC/PHY 状态应用层只看 TCP/echo 结果不要混在一起。调试时精神压力大日志清晰是效率救星。第三遇到 Vitis 下载调试提示不识别芯片先查 Hardware Manager 里的 JTAG 链再查调试器驱动不要反复烧录浪费时间。我见过有人烧了十几次最后发现是板子 JTAG 电压被省掉了这个坑和 PHY 无关但同样会让你心态崩。6.2 国产 PHY 和常见 Marvell PHY 在调试上的差异拿 YT8521S 和 88E1512 对比我的体感是88E1512 的驱动成熟Vitis 的 BSP 里默认支持度很高几乎不用改。YT8521S 需要更多手工调寄存器但数据手册和配套文档相对容易获取芯片的设计思路也符合主流 PHY 规范所以只要方法对调试并不难。两者的自动协商行为有细微差别但底层都是 802.3 标准所以务必先把标准行为吃掉再研究厂商差异。如果是小批量产品我建议直接用官方 demo 验证一遍你的 PHY 型号再投入应用层开发。这种方案花的时间最低风险也最低。6.3 低成本高效率的自测小工具当你没有专业网络分析仪也可以准备一台普通 PC 加 Wireshark抓包调试 TCP/IP 行为一个 USB 转 Ethernet 的千兆网卡用于隔离 PC 主板网卡的底层机制差异一根经过验证的标准 CAT6 网线优先排除线序和屏蔽问题。网络调试很多时候是“排到最后发现网线是坏的”所以这些基础工具千万别忽略。我在这次调 YT8521S 之前也曾经觉得 PHY 调试是最磨人的一环。但三天下来最大的收获其实不是 echo 通了而是建立了一套“先链路层、后网络层、再应用层”的排查方法。这套方法在后来调试别的 PHY 和网卡芯片时依然有效。如果你正在被类似的问题卡住建议从我说的第一步“拿 MDIO 读 PHY ID”开始一步一步走大多数问题都是纸老虎。