企业官网建设流程全解析

前阵子做采集板卡，FPGA把多路ADC数据汇总之后要实时上报，网络通信顺理成章成了刚需。一开始我天真地想在FPGA里自己写精简TCP/IP协议栈，折腾两个星期后老实了，改成了FPGA + W5500的方案：FPGA只用SPI接口访问W5500这颗自带MAC/PHY和硬件协议栈的芯片，把以太网、IP、TCP/UDP、ARP这些脏活全部交给它。这个改动让项目进度一下子顺畅起来，也让我把W5500从硬件连接到寄存器操作、从UDP回环到TCP断线重连完整走了一遍。这篇就把整段“奇妙之旅”拆开讲清楚，适合正打算在FPGA上做以太网通信、又不想被协议栈细节劝退的工程师参考。

1. 项目概述与方案选型

1.1 W5500在FPGA系统里扮演什么角色

W5500是WIZnet家族里一颗非常经典的以太网控制芯片，内部集成了10/100M以太网MAC和PHY，更重要的是把TCP/IP协议栈做成了硬件，TCP、UDP、IPv4、ARP、ICMP、IGMP这些协议的处理不再占用FPGA逻辑资源。FPGA和W5500之间只有SPI四线接口：SCLK、MOSI、MISO、SCS，外加一个复位引脚和一个中断引脚。

对FPGA工程师来说，W5500把“联网”这个任务从“需要精通协议栈”降级成了“会操作SPI外设”。你需要关心的不是以太网帧怎么封装、TCP三次握手怎么实现、重传超时怎么计算，而是：怎么通过SPI读写芯片内部寄存器、怎么把应用数据放进发送缓冲区、怎么从接收缓冲区把数据取出来。协议栈里的状态机被封装在芯片内部，FPGA侧只需要维护一个简单的应用层状态机。

它解决的典型问题是：数据采集系统需要把测量结果、设备状态、告警信息上报给上位机；或者上位机需要下发配置指令给FPGA设备。用W5500构建以太网通信，开发周期可以压缩到原来的三分之一左右，而且通信行为很稳定，因为协议处理不再受FPGA时序收敛问题影响。

1.2 为什么没有选择更“硬核”的协议栈方案

做以太网通信，摆在桌面上的方案其实有好几种，我简单对照一下当时纠结的几个方向：

对我这个采集板卡项目来说，数据量是小百Kbps到几Mbps量级，W5500的吞吐完全够用。而且项目进度是硬指标，与其把两三个月砸在自研协议栈上，不如把省下来的时间投入到采集链路和上位机软件上。这就是选W5500最朴素也最实际的逻辑。

1.3 整体架构与数据流设计

我最终搭建的系统架构分成两层。硬件上，FPGA开发板通过SPI接口连接一块W5500模块，模块上自带网络变压器和RJ45座，插上网线就能和PC交换机连通。FPGA内部则按功能拆成几个模块：应用数据源模块负责产生需要上报的数据包；发送FIFO暂存待发送数据；W5500控制器负责所有SPI读写事务；接收FIFO存放下行数据；应用处理模块解析接收到的指令。

数据流方向很清晰：

采集模块把ADC数据拼成报文格式，写入发送FIFO。W5500控制器检测到FIFO非空后，按UDP或TCP发送流程组织SPI事务，把数据搬进W5500的发送缓冲区，触发芯片发送。接收方向完全相反：W5500收到网络数据后，FPGA控制器通过SPI把数据从接收缓冲区读出来，写入接收FIFO，应用模块再逐条解析。

一开始做模块划分时，我犯过一个错误：把SPI时序控制、寄存器操作、socket管理全写在一个大状态机里，结果调试时一崩全崩，根本分不清是SPI时序问题还是协议流程问题。后来强制拆层：底层只做SPI字节收发，中间层只做寄存器读写原语，上层才做socket生命周期管理。这个分层思路是这次项目里最值得保留的经验。

2. 拆解W5500的寄存器与数据通路

2.1 SPI帧格式：3个字节的“信封”

要把W5500玩明白，第一关是理解它的SPI帧格式。W5500一次SPI事务由两部分组成：3字节的“地址+控制”信息，后面跟真正的数据段。这3个字节相当于一个信封，告诉芯片你要访问哪个区域、干什么操作。

具体来说，前16位是寄存器或缓冲区偏移地址，紧随其后的8位控制字节里，最高位是读写方向，中间两位决定数据段长度模式，低5位是块选择位BSB。BSB负责选通不同的区域：通用寄存器、Socket0到Socket3的寄存器、发送缓冲区、接收缓冲区。所有SPI事务都必须带着这三个字节开头，芯片才能知道后续数据应该落到哪里。

实际用FPGA实现SPI Master时，要特别注意这个帧格式不是普通的SPI寄存器读写模式，不能简单地用“发地址字节地址寄存器”的通用IP核代打。我试过直接用FPGA自带的SPI控制器跑W5500，发现它默认把地址当作普通数据发送，根本不认识W5500的块选择机制。最后老老实实自己写了一个状态机，按W5500手册的帧格式组帧，才把通信跑通。

刚开始接触W5500时，我建议先用信号发生器或逻辑分析仪抓一遍SPI线上的实际波形，看三字节信封和数据段的排列是否符合手册时序图。这一步走稳，后面所有寄存器读写都不会跑偏。

2.2 从VERSIONR开始：自检与初始化

W5500内部有个版本寄存器VERSIONR，偏移地址0x001F，芯片正常工作时默认读回值通常是0x04。这几乎是所有W5500调试的第一步：只要能通过SPI读到这个版本号，就说明供电、复位、SPI接线、时钟极性这些基础条件全部正常。

我习惯把初始化流程写成固定的顺序，每一步都有明确目的：

1. 硬件复位：拉低RSTn并保持至少几百微秒，再拉高，然后延时等待芯片内部稳定。
2. SPI通路自检：读VERSIONR，确认读回0x04，如果不对，立刻停住排查硬件。
3. 配置网络参数：写本机MAC地址SHAR、IP地址SIPR、子网掩码SUBR、默认网关GAR。这些寄存器都是连续字节地址，MAC 6字节、IP 4字节，可以用SPI连续写。
4. 配置收发缓冲区大小：通过RMSR和TMSR给各个socket分配发送、接收缓冲区配额。
5. 配置重传参数：RTR和RCR控制TCP重传延时和次数，对可靠性影响很大。
6. 按需使能中断：IMR、SIMR控制全局和socket级中断使能。
7. 查询PHY状态：通过PHYCFGR的链接状态位确认网线已插好，PHY已建立链路。

这套顺序我后面在FPGA状态机里原封不动实现了。实测下来，只要第2步版本号能读对，后面配置大概率不会出幺蛾子；如果卡在后面的某一步，优先怀疑协议状态而不是SPI通道。

2.3 缓冲区分配：把32KB花在刀刃上

W5500片内有一块约32KB大小的存储，划分成多个发送缓冲区和接收缓冲区区域，分配策略直接决定你能同时开几个socket、每个socket能跑多大的吞吐。

每个socket都有独立的RX和TX空间，大小通过RMSR（接收内存配置）和TMSR（发送内存配置）来控制。如果不改配置，芯片复位后会把空间在4个socket之间平分，每个socket只能分到很小的收发缓冲。这对只做简单UDP透传是够用的，但如果要做大包收发或高吞吐传输，就一定要调整分配策略。

我在项目里只使用了1个socket做TCP Server，于是把剩下的socket缓冲区全部配成最小，把所有空间集中到这个socket上，收发缓冲各给到最大。这样单个连接能缓存更多数据，突发流量到来时不容易丢包。

这里有个容易踩的坑：缓冲区大小配置必须在socket打开之前完成。socket一旦处于打开状态，再修改RMSR/TMSR，缓冲区布局变化可能导致指针错乱、数据写到错误区域。所以在初始化流程里，我把它放在第4步，优先级排在打开socket之前，顺序不能乱。

2.4 一条UDP包在W5500里走完的路径

以UDP发送为例，把数据从FPGA送出去，W5500内部大概经历这么几步：

先读当前发送写指针Sn_TX_WR，这相当于记录“接下来该往缓冲区哪里写”。然后把要发的数据通过SPI连续写入发送缓冲区对应位置。因为缓冲区是环形结构，如果写指针加上数据长度越过了缓冲区末端，必须拆成两段写，先写末尾剩下的部分，再写从开头开始的剩余部分，这一步很多新手会漏。写完数据后，把Sn_TX_WR更新为“原指针+数据长度”，并往Sn_CR写入SEND命令。W5500硬件看到SEND命令，自动完成UDP头封装、IP校验、以太网帧打包，然后从PHY发出去。SEND命令执行期间，Sn_CR不会立即清零，需要轮询直到硬件自动清0，才能继续下一条发送指令。

接收路径是反向的。W5500收到UDP包后，会把一段8字节的头部信息放到接收缓冲区，里面包含源IP、源端口、数据长度等字段，紧接着才是UDP载荷数据。FPGA侧要判断Sn_RX_RSR（接收数据大小寄存器）非零，然后读Sn_RX_RD指向的数据，先读8字节头部，再读载荷，处理完更新Sn_RX_RD并写RECV命令释放缓冲区空间。

理解这条路径后，你会发现FPGA的工作其实非常机械：读指针、写数据、更新指针、发命令、等命令完成。协议栈的复杂逻辑全部被W5500消化掉了。

3. FPGA侧模块划分与状态机设计

3.1 模块划分：别把状态机写成意大利面

FPGA侧如果所有功能挤在一个模块里，后面调试会非常痛苦。我最终把逻辑拆成了4层：

第一层是SPI物理层，负责把SCLK、MOSI、MISO、SCS的时序精确实现出来，对外只提供两个接口：写寄存器和读寄存器，读写参数是寄存器地址、数据长度、数据缓存指针。它不关心W5500的协议细节。

第二层是寄存器层，在SPI物理层之上封装对具体寄存器的操作，比如写网络配置寄存器、读中断寄存器、读写缓冲区等。这一层让上层代码看起来像在操作“一个个有名字的寄存器”，而不是一堆字节流。

第三层是socket管理层，负责实现socket的打开、监听、连接、发送、接收、关闭这些状态转换，以及超时处理。

第四层是应用层，处理具体业务逻辑，比如组装报文、解析指令、维护回环测试状态。

分层最大的好处是定位问题快。回环测试数据乱码，我只需要查第三层指针更新有没有问题，不需要去翻SPI时序。SPI读回全FF，我也只需要在第一层和第二层排查，不会牵扯协议流程。

3.2 SPI主机状态机：怎么样读写才稳

W5500对SPI模式的兼容性算比较好，常用的Mode 0或Mode 3都能正常工作。我最终选了Mode 0，即CPOL=0、CPHA=0，空闲时时钟低电平，数据在上升沿采样、下降沿变化。和FPGA内部逻辑时钟配合起来比较自然。

我的SPI状态机分四步：

第一步是IDLE，等待读写请求。第二步是发送3字节信封，通过MOSI逐位移出地址和控制字节，同时这个阶段MISO上的数据无意义。第三步是数据阶段。写操作时，MOSI继续逐字节移出数据；读操作时，FPGA产生同样的SCLK，但在每个数据位的采样时刻读取MISO。第四步是拉高SCS，结束事务，返回IDLE，回报完成标志。

有一个细节很重要：读操作在发完控制字之后，W5500需要一点时间把第一个数据位准备好。如果时序余量不够，可以在数据阶段开始时先产生一个空时钟沿，再从第二个有效沿开始采样。实际用FPGA实现时，我通过内部计数器把SCLK周期分成了多个时间片，发送沿和采样沿分别放到不同的时间片，这样就能精确控制建立保持时间，不会出现采样到毛刺的问题。

3.3 初始化序列：时序比代码顺序更重要

FPGA上电后，初始化流程要严格按时序推进，不能像写软件那样想先做什么就做什么。我用一个master初始化状态机执行以下序列：

IDLE状态先等待一个固定延时的复位低电平，确保W5500完全复位。随后进入POST状态，读版本寄存器确认SPI通路OK。然后依次进入网络参数配置、缓冲区分配、重传参数配置、中断配置、PHY状态查询等状态。每个状态都设置超时计数器，万一某一环卡住，状态机能自动上报初始化失败，而不是无限等下去。

实际调试中我发现，上电后立刻进行SPI访问有时会失败，原因是W5500内部还在初始化，所以我在复位拉高后加了约5毫秒的延时，再去读版本寄存器，一次性通过了。这个延时数值不算大，但确实避免了很多偶发问题。如果你遇到“第一回读版本号失败，第二回又成功”这种玄学问题，多半就是上电时序没给够。

初始化期间不要打开socket，也不要写任何数据。所有寄存器配置完成后，再去初始化socket，否则可能在配置过程中触发意外的网络行为，导致连接状态混乱。

3.4 发送/接收状态机的关键转移条件

发送状态机最忌讳的是“写完SEND命令就认为发送完成”。W5500的Sn_CR寄存器写入SEND之后，需要等待芯片把命令处理完，它会自动清零。我一开始用固定延时，结果偶尔会导致下一条命令被吞掉，后来改成轮询Sn_CR直到为0，效果好很多。

发送链路状态机大致是：

• 检查发送FIFO是否有数据。
• 读取Sn_TX_FSR，确认发送缓冲区空闲空间足够。
• 读取Sn_TX_WR指针。
• 按环形缓冲区分段写入数据。
• 更新Sn_TX_WR。
• 写Sn_CR = SEND命令。
• 轮询Sn_CR直到清零。
• 回到空闲状态，等待下一包。

接收链路状态机则更依赖中断或轮询。我采用轮询方式，定时读Sn_RX_RSR，发现接收字节数非零就启动接收流程。接收流程要先读头部，确认数据长度，再读载荷，最后更新Sn_RX_RD并写RECV命令释放空间。

在轮询方式下，注意不要频繁读寄存器，否则会占用大量SPI带宽。我设定接收轮询周期为几十微秒一次，对吞吐影响很小，又可以及时响应数据到达。

4. 实操：FPGA + W5500 打通回环通信

4.1 硬件连接与上电自检清单

硬件连线其实只有6根线：SCLK接FPGA时钟输出引脚、MOSI接FPGA输出、MISO接FPGA输入、SCS接片选输出、RSTn接复位输出、INTn接FPGA输入。W5500模块的供电是3.3V，FPGA的IO银行也要配成3.3V电平，这点容易被忽略，如果IO电平不匹配，SPI信号会有随机毛刺。

上电之前先用量表确认VCC对地没有短路，然后检查25MHz晶振是否起振。晶振不起振，PHY层就完全无法工作，网线插上也不会有链路灯。我再三提醒一点：有些W5500模块的RJ45座自带网络变压器，有些则是分离的变压器+RJ45，两种接法不同，参考模块原理图接，别臆测。

上电后的自检顺序是：FPGA启动完成后先复位W5500，再读版本号确认SPI通路，再读PHYCFGR确认链路状态。如果链路状态寄存器显示LINK=0，拔插网线、换网线、看交换机端口都是常规操作，但更常见的原因是晶振没起振或者PMODE引脚配置不对。

4.2 寄存器读写自测：读版本号是一个好兆头

我在FPGA里做了一个简单的调试寄存器接口，通过串口命令能触发SPI读操作。第一个测试就是读W5500的VERSIONR寄存器。

当串口打印出0x04时，基本可以确认：SPI模式正确、地址信封格式正确、W5500已经启动成功。这个“动起来”的感觉很重要，它把整套链路拆成了“已打通”和“待调试”两部分。

接下来我会继续做连读测试，比如连续读多个网络配置寄存器，确保SPI状态下数据连续性和地址递增逻辑没有bug。这一步能提前发现字节错位、丢位的问题，不用等上网之后抓狂。

注意，读寄存器时如果数据错位，往往不是数据线接反，而是SPI采样沿不对。遇到读回数据像是“整体左移一位”的情况，优先检查CPHA配置。

4.3 UDP回环的FPGA侧流程

回环测试是最快验证整条链路的办法：PC端通过UDP发送任意数据给FPGA设备，FPGA收到后原封不动返回给PC。这个功能涵盖了W5500的接收、读取、再发送全流程。

我用的流程是这样的：初始化时将socket0配置为UDP模式，绑定端口5000。主循环不断轮询Sn_RX_RSR，一旦收到数据，先读出接收缓冲区的8字节头部，从头部拿到源IP、源端口、数据长度。然后把数据原样复制到发送缓冲区，设置目标IP为目标源IP、目标端口为目标源端口，触发发送。

这里有个容易踩的坑：UDP接收头部的8字节不是载荷数据，如果不跳过就直接把缓冲区内容发回去，PC端收到的会多出8字节乱码。我当时就被这个坑绊了一个小时，后来对照手册的接收头部结构才反应过来。

为了验证数据内容是否完整，我建议PC端发送带递增序号的数据包，FPGA回环后PC校验序号连续性，这样丢包、错序问题一目了然。

4.4 上位机脚本验证与效果

上位机验证我直接用Python的socket库写了几十行测试脚本。脚本向设备端UDP端口5000连续发送1000个数据包，每包128字节，包内带序号和填充数据，然后统计回包数量和完整性。

import socket import time DEST_IP = "192.168.1.100" DEST_PORT = 5000 TOTAL = 1000 PAYLOAD = b"x" * 124 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.settimeout(1) recv_ok = 0 for i in range(TOTAL): data = i.to_bytes(4, "big") + PAYLOAD s.sendto(data, (DEST_IP, DEST_PORT)) try: r, addr = s.recvfrom(512) if r[:4] == i.to_bytes(4, "big"): recv_ok += 1 except socket.timeout: pass print(f"received {recv_ok} / {TOTAL}")

第一次跑通回环时，1000个包全部原样返回，那一刻的成就感很直接。不过等我把发包速率调高之后，突然开始丢包了，这就是下一节要说的性能问题。

4.5 性能实测与计算

W5500的吞吐上限主要受SPI时钟和帧开销限制。每次SPI事务不管读写多少数据，都要先支付3字节信封的成本，所以数据包越小，有效带宽越吃亏。

以SPI时钟20MHz为例，如果发送一个1000字节的数据包，一次事务传输的总字节数约为1003字节，总耗时约为1003×8/20MHz=0.4毫秒。换算成纯载荷吞吐，理论上限约为20Mbps量级，实际加上轮询、寄存器操作、帧间隔等开销，实测能做到12到15Mbps就算不错了。

如果换成64字节的小包，每包3字节开销占比明显增大，而且每包都要执行读指针、写数据、更新指针、发命令、等完成这一整套流程，固定开销远大于传输时间，实际小包吞吐会低很多。

实测下来，我把SPI时钟从10MHz逐步提高到25MHz，吞吐相应上涨，但再往上就遇到信号完整性问题了。所以高速应用建议在PCB上做好SPI走线，缩短连接线，调试阶段不要用过长的杜邦线。

5. 常见问题与排查技巧实录

5.1 寄存器读回全F/全0，先别急着改代码

现象是读W5500任何寄存器都返回0xFF或者0x00，看起来像是芯片没工作，但大部分时候不是芯片坏了，而是SPI通路没建立好。

按这个顺序查：先查W5500的RSTn引脚电平，如果一直拉在低电平，芯片永远处于复位状态。然后查SCLK和MOSI引脚有没有虚焊、接触不良，用手按压芯片会不会导致读数变化。再查SCS片选极性，W5500是低有效片选，如果FPGA侧片选极性配反了，所有SPI事务都会被芯片忽略。最后查SPI模式，CPOL/CPHA组合错了也会导致读回全错。

这块的经验是：读VERSIONR之前，不要急着在FPGA代码里加各种打印和分支，先用逻辑分析仪抓SCLK、MOSI、MISO、SCS四根线，对比手册时序图，往往一眼就能看出问题。

5.2 PHY链路不建立，检查顺序怎么排

另一个高频问题是：SPI通信正常，版本号能读，但网线插上后链路状态始终是断开，网卡也显示“网络电缆被拔出”。

我先检查25MHz晶振是否起振，用示波器量晶振引脚，没有波形就换晶振或检查负载电容。然后检查W5500模块的PHY模式配置引脚PMODE，不同接法对应不同PHY工作模式，接错会导致芯片内部PHY异常。再检查网络变压器部分，中心抽头是否需要接电源或接地，不同模块设计不一样。最后才怀疑网线本身。

链路建立后，PHYCFGR寄存器里的速度和双工位也会更新，通过读这个寄存器可以确认PHY协商结果。如果总是协商成半双工，检查一下网线和交换机端口配置，一般不用太纠结。

5.3 数据错位、CRC报错、偶发丢包

数据错位通常发生在SPI读数据阶段，表现为读回来的字节顺序不对或者某一位丢了。多半是采样沿设置不对，或者SCLK频率太高导致建立时间不够。把SPI时钟降下来通常能缓解，治本方案是重新计算FPGA内部SPI状态机的发送沿和采样沿时序。

偶发丢包则要区分是接收缓冲区溢出还是发送缓冲区不足。接收方向，如果PC端短时间内猛发包，而FPGA来不及读取W5500的接收缓冲区，新到的包会覆盖旧数据或直接被丢弃。解决思路是加大该socket的接收缓冲区配额，同时提高接收轮询频率。发送方向，如果应用层产生数据的速度超过W5500发送能力，发送缓冲区会满，这时应该通过反馈机制让数据源临时暂停，而不是强行往里塞数据。

我在项目里为发送FIFO加了高水位信号，FIFO超过80%满时，数据源模块就暂停产生新包，等FIFO降到低水位再恢复。这个背压机制一下子消除了偶发丢包。

5.4 TCP握手异常与连接断开

做TCP Server时，最容易出问题的环节是握手。SN_MR协议类型必须设置为TCP模式，SN_PORT绑定端口后，Sn_CR写LISTEN命令进入监听状态。PC端连接时，W5500内部自动完成三次握手，Sn_SR状态寄存器会从LISTEN切换到ESTABLISHED，之后才能正常收发。

常见错误是写完OPEN或LISTEN命令后没等Sn_CR清零就进行下一步，导致命令丢失，socket状态停留在不该停留的位置。另一种错误是网络配置里的IP地址、网关、子网掩码填错，导致跨网段时ARP解析失败，握手永远完不成。

TCP连接建立后，PC端断开时W5500会进入CLOSE_WAIT等状态，FPGA侧一定要轮询Sn_IR里的断开标志，发现断开后主动关闭socket并重新监听，否则设备端会卡在旧连接上，PC端重连不上。

5.5 快速自查清单

6. 项目心得与扩展方向

这趟FPGA + W5500的实践，给我最大的体会是：在FPGA世界里，不是所有事都要用FPGA的方式“硬解”。W5500把网络协议栈封装成一颗SPI外设，相当于把最消耗开发精力的协议部分变成了标准零件，FPGA工程师可以把精力集中在自己真正擅长的高速采集、实时控制、信号处理上。

实际项目里，我后续又基于这套方案做了两个扩展：一是用W5500的第二路socket同时跑UDP和TCP，一路做实时状态广播，一路做配置指令下发；二是把W5500的中断引脚用起来，代替轮询，中断事件触发FPGA内部的事件处理状态机，CPU占用和SPI带宽都更省。

如果接下来想继续深挖，方向可以是：把这套SPI控制器封装成可复用的IP核，方便其他项目直接调用；或者研究一下W5500的重传参数对TCP恶劣网络环境的适应能力，在工控场景下做更细的调优。总之，这趟从协议栈泥潭里爬出来的经历，让我以后遇到网络通信需求时，第一反应不再是“自己写协议”，而是先评估有没有成熟、可靠、能把复杂度挡在外面的方案。