基于Zynq SoC SOM的HSR/PRP无缝冗余网络实现指南

1. 项目思路：为什么我用Zynq SoC SOM来做HSR/PRP冗余网络

1.1 HSR/PRP到底解决什么问题

做工业以太网通信的工程师，对IEC 62439-3这个标准应该都不陌生。HSR（High-availability Seamless Redundancy）和PRP（Parallel Redundancy Protocol）是两种高可用无缝冗余协议，核心目标就是解决一个非常现实的问题：网络出现单点故障时，通信不能断，业务帧不能丢，切换时间必须接近零。

传统以太网里我们常用的STP/RSTP，包括工业现场比较流行的MRP，都遵循“故障检测—拓扑重算—流量恢复”这个流程。RSTP恢复时间能控制在几十毫秒已经很不错了，MRP能到10毫秒以内，但在数据链路发生断裂的那一瞬间，仍然会有若干帧被丢弃。对于运动控制、站间闭锁、继电保护这类对时延和丢帧极其敏感的应用来说，哪怕丢一帧都可能是事故级别的。

HSR的思路是让节点构成一个环，每个节点都有两个以太网口，发送帧时同时向两个方向各发一份，接收端根据序列号把重复的那份丢掉。PRP的思路更简单粗暴：两个完全独立的局域网，发送时一份帧同时发给LAN A和LAN B，接收端同样做去重。这两种协议都不依赖“故障发生后再切换”的机制，而是从源头做了双重发送，所以切换时间为零，也就是IEC 62439-3里强调的seamless redundancy。

这个特性决定了HSR/PRP最典型的应用场景：变电站自动化（IEC 61850过程总线）、轨道交通列车通信网络、船舶系统、大型工业控制网络。如果你正在做这些方向的产品，那标题里的Zynq SoC SOM加HSR/PRP IP核这套组合，基本就是当前性价比和灵活性最均衡的一条技术路线，这篇内容会把选型思路、硬件设计、IP核集成、联调测试和踩坑记录完整梳理一遍。

1.2 从方案对比看选型逻辑：ASIC、独立FPGA、还是Zynq SoC SOM

做HSR/PRP冗余节点，市面上大致有三条路：专用ASIC芯片、独立FPGA加外部CPU、Zynq SoC SOM加IP核。我做项目时把三种方案都认真比过，最终选了第三种，这里把对比结果整理出来供参考。

专用ASIC方案的代表有瑞萨的R-IN32M3系列，芯片内部内置了HSR/PRP硬件加速，软件栈也比较完整。优势是功耗低、代码量小、单芯片搞定；劣势非常明显——灵活性差，协议版本升级你得跟着芯片厂走，而且这颗料近几年供货时好时坏，做电力项目最怕的就是供应链出问题。

独立FPGA加外部CPU也是常见做法，比如用Kintex系列加上一颗MPU。好处是PL资源充足，坏处是板级设计复杂度高，CPU和FPGA之间通常要走PCIe或者高速并行总线，硬件和软件两头的工作量都不小。对多数中小团队来说，一板搞不好就是半年。

Zynq SoC SOM加HSR/PRP IP核的优势在于：PL部分负责线速的帧复制、冗余去重和快速转发，PS部分的ARM Cortex-A9（或者Ultrascale+的A53）跑操作系统和应用协议栈，软硬件天然协同。SOM模块则帮你把最麻烦的DDR布线、电源时序、FLASH配置、量产测试这些事提前干完了，你把精力集中在IP核集成和业务逻辑上。下面是三种方案的对比表：

我最终选SOM还有一个很重要的原因：HSR/PRP这种协议，不同项目组对功能的要求差异很大。有的人只要DANH（双口HSR节点），有的人要DANP（双网PRP节点），还有人要RedBox去兼容SAN设备。ASIC芯片一般固化好了形态，但IP核可以通过寄存器自由切换，一个硬件平台覆盖多个客户需求，这个优势在项目交付阶段实在太重要了。

2. 硬件选型和SOM模块的关键点

2.1 选Zynq哪一颗：资源估算和余量

确定了Zynq SoC SOM这个方向之后，第一步是选具体型号。市面上最常见的Zynq-7000系列SOM，比如XC7Z020和XC7Z045，以及Ultrascale+系列的ZU3EG、ZU7EV，都有人在做HSR/PRP方案，选择依据主要是资源用量和扩展需求。

HSR/PRP IP核本身占的资源并不算离谱。以我实际用过的商业IP核为例，双口线速处理、内置MAC和DMA，大致消耗在15000到25000个LUT、25000个FF左右，BRAM大概需要30到60块，这取决于你配了多少FIFO和缓存。XC7Z020级别的SOM集成一个这样的IP核完全没问题，剩余资源还能放Modbus TCP网关、IEC 61850 GOOSE解析之类的逻辑。

但如果你的产品不只是做HSR/PRP，还想同时跑万兆网口、TSN、硬件时间戳、多路串口扩展，那Zynq-7000的GTH资源就有点挤了。这种情况建议直接上Ultrascale+的ZU+系列SOM，它的GTY高速收发器速率更高，PS端能跑64位DDR4，PL端逻辑资源更宽裕。带VCU的ZU7EV还可以顺带做视频处理，有些轨道交通项目会同时要PIS屏幕显示和网络冗余，就喜欢这种一板多用的方案。

选型号时还有一个容易忽略的点：确认SOM上有没有给你引出足够的GTX/GTH参考时钟。HSR/PRP如果走SGMII，参考时钟用125MHz，这个频率很多SOM默认就有。但如果你的IP核要走光口（SFP/SFP+），需要一对独立的GTX参考时钟，建议在选SOM时就直接确认它有没有把MGTREFCLK引出来，否则后面在设计上很被动。

2.2 双网口的PHY和时钟设计，别在SGMII这里翻车

HSR节点有Port A、Port B两个网口，PRP节点需要分别接入LAN A和LAN B。无论哪种，板级都需要两个物理以太网接口。这里涉及PHY芯片选型、接口模式、时钟设计三个关键判断。

接口模式上，100M速率用RGMII足够，但工业主控板一般会顺带支持千兆，所以我建议直接用SGMII。SGMII在PL端需要通过GTX或者专用的SGMII IP核桥接，SOM模块上如果已经通过GEM（PS端内置的Gigabit Ethernet MAC）引出网口，那一般就是走RGMII到外部PHY。这里有一个常见分歧：HSR/PRP IP核要接管两个网口，这时候数据面不经过PS的GEM，而是直接由PL侧的MAC/SGMII模块接到PHY。所以你得确认IP核自带的MAC接口是支持SGMII还是RGMII，再选对应的PHY。

PHY芯片选择方面，我先后用过Marvell 88E1512、瑞昱RTL8211FD、裕太微YT8531，总体感受是88E1512的稳定性和工业级文档最完善，但近两年价格偏高；YT8531工业级版本性价比不错，国内供应链也稳，只是它的寄存器手册有些细节写得比较模糊，需要自己踩坑。选型时务必确认支持工业温度范围（-40到+85），并且留意PHY的strapping配置，引脚上下拉电阻决定了它工作在哪种模式，很多SGMII“起不来”的问题最后都发现是PHY配置脚接错了。

时钟这一块是HSR/PRP项目里最容易出问题的环节。SGMII接口需要125MHz的参考时钟，PHY也需要对应的125MHz，两边必须同源或者做同步。如果时钟抖动指标不好，长时间跑会出现偶发CRC错误，这种问题在实验室短时间测试根本测不出来。项目早期我用过普通晶振直接给PHY供时钟，后来出现了几台设备在高温运行几小时后偶发丢包的现象，换用低抖动的钟振才彻底解决。如果你在SOM上看到了LMK04828这颗芯片，它做的是整个系统级的低抖动时钟分配，专门给GTX、SGMII、PHY提供干净的参考源，这不是什么玄学，是稳定时间同步和低误码率的基础。

2.3 电源和EMC，被很多人忽略的隐形坑

做Zynq SOM方案，电源这块其实省了很多心，因为SOM把PS端的DDR、PLL需要的电源树都已经处理好了，你只需要给SOM提供一组干净的输入电源。但PL端如果把GTX跑起来，对电源纹波仍然非常敏感。RFSoC这类带ADC的器件有严格电源纹波指标，其实Zynq的高速收发器也一样，只是没到ADC那么夸张而已。

我的经验是：SOM输入电源至少用DC-DC加二级LDO的组合，DC-DC负责降压，LDO负责滤掉高频开关纹波。如果你在SOM旁边还放了HSR/PRP工业PHY，PHY的模拟电源也要单独做滤波。实测下来，纹波从50mV压到20mV以内之后，SGMII链路的误码率明显下降，长时间老化的稳定性高了一个台阶。

EMC方面，工业级产品如果过不了IEC 61000-4-2静电放电和IEC 61000-4-4电快速瞬变脉冲群，后面现场部署会非常痛苦。RJ45连接器要选带变压器隔离的，或者外接隔离变压器再接PHY，这样共模干扰才不会灌进SOM。网口到变压器之间的共模电感、终端电阻，不要为了省成本省掉，我在实际项目里见过的SGMII信号不稳定，有一大半和布局布线、共模处理有关。

3. HSR/PRP IP核集成实操：核心环节详细拆解

3.1 理解IP核的三个平面：数据平面、控制平面、管理平面

拿到一个HSR/PRP IP核，第一件事不要急着连线，先把它的内部结构搞清楚。这类IP核一般可以分成三个平面。

数据平面负责真正的高速报文处理：两个网口各收各的帧，判断是不是重复帧，查MAC地址表决定丢弃还是转发，再根据协议要求完成HSR Tag或PRP RCT的插入和剥离。这个平面的核心是去重表（Duplicate Discard Table），通常用哈希表实现。IP核寄存器的可配置项里，有一个“Node Table Depth”或“Hash Table Size”的参数，说的就是这个去重表的容量。在你配这个参数时，需要考虑环网上实际可能同时存在的节点数量，以及网络里广播帧的密度，建议留出至少两倍余量，否则高负载下哈希冲突会导致丢帧。

控制平面一般通过AXI4-Lite接口访问，用来配置IP核的工作模式。主要寄存器包括：使能HSR还是PRP、节点角色（DANH、DANP、RedBox）、本节点MAC地址、是否支持VLAN标签插入/剥离、管理帧处理策略等。重点说一下节点角色选择：如果你做的是双口终端设备，选DANH或者DANP；如果你做的是把普通单口设备接进冗余环网的网关，那必须选RedBox。RedBox的逻辑比DANH复杂不少，它会模拟SAN设备（Single Attached Node）的存在，以太环转发等细节都要处理清楚。

管理平面就是IEEE 802.1D风格的管理帧处理，以及节点学习、链路监控帧（Supervision Frame）的发送和接收。PRP中每个DANP节点会周期发送PRP_Supervision帧，HSR中也有类似的节点状态帧。这类帧的发送周期、使能开关一般也通过控制平面的寄存器配置。如果测试时发现对端节点列表里看不到本节点，九成是这个管理平面的配置没打开。

3.2 关键配置和Vivado集成步骤

下面拿一个典型的集成流程来演示。假设你选的IP核是Vivado里可以双击添加的图形化IP，或者是通过网表文件引入的第三方核，集成步骤大概是这样的：

第一步，在Vivado block design里例化HSR/PRP IP核，把两个网口的MAC接口分别接到对应的SGMII/GTX IP核上，通常一个口对应一个独立的MAC-PHY通道。如果你用的是带SerDes直接输出的IP核版本，那就不需要额外的SGMII桥接，直接接到GTX的transceiver接口，再通过SFP或者光模块转换器接光纤。

第二步，把IP核的配置端口和寄存器配置信息连接好。注意大多数IP核的默认配置是HSR模式，需要你显式设置成PRP模式或者双协议自动识别模式。有些IP核支持通过外部引脚在运行中切换HSR和PRP，这在产品上非常好用——硬件一套，软件切换。

第三步，把控制平面AXI4-Lite接在PS端的M_AXI_GP端口上，数据平面通过AXI DMA把去重后的帧搬到PS的DDR里。有些IP核本身就带DMA和描述符，这种就更省事。如果你用的是PS内置GEM和IP核做数据交互，需要把IP核的收发接口连接到GEM的MII接口上，这种模式下IP核相当于GEM和PHY之间的旁路加速器，PS驱动不用改太多。

第四步非常重要：设置MTU/最大帧长。正常以太网帧1518字节，加上VLAN标签、HSR Tag或者PRP RCT之后会变大。HSR Tag增加4字节，PRP RCT增加6字节，所以IP核内部至少要能处理1522字节的帧。如果你还要透传巨型帧，建议把最大帧长配到2048字节，并且对应网卡的MTU也要同步调大，否则会对不上。

Vivado集成完成后，综合实现时要注意时序报告。IP核数据路径上如果有关键路径时序违例，最常见的原因是BRAM使用率过高导致布线拥塞，或者GTX和相关时钟的约束没有加好。编译前务必在XDC里把HSR/PRP IP核涉及的时钟域约束写清楚，尤其是多个GTX通道的时钟关系，不要偷懒只用create_clock，要把fifo的跨时钟域约束也用set_clock_groups处理一下，否则实现后跑出来的网表稳定性全凭运气。

3.3 用ILA加Wireshark做协议级验证

IP核配置好、硬件也能link起来之后，接下来的重头戏是验证协议行为是否正确。我的方法是“板内ILA看信号，板外Wireshark看报文”，两边互相印证。

第一步，先在FPGA工程里把ILA（集成逻辑分析仪）接在IP核的接收数据通路上，触发条件可以设成“收到任意帧”。让对端设备往环网里发一个已知的测试报文，观察ILA抓到的数据是否存在HSR Tag或者PRP RCT。如果IP核内部开了剥离功能，那ILA抓到的应该是剥离后的裸MAC帧；如果没开剥离，抓到的就是带冗余附加信息的原始帧。这一步能快速判断IP核的编解码逻辑是否正常工作。

第二步，在实验室搭一个最小的HSR环，用两台支持HSR的工业交换机，或者直接用两块SOM板互相环起来，形成A-B-A-B的环路。用PC或者另一块开发板在环网上发UDP报文，然后用抓包工具在交换机镜像口上抓包。如果你用的是Wireshark，新版默认能识别HSR Tag和PRP RCT并做解析。检查三个关键字段：序列号是否连续、LAN ID是否正确、LSDU size是否和帧长度匹配。序列号乱跳或者重复，说明去重表工作不正常；LAN ID错误说明PHY链路选择有问题。

第三步，做故障注入测试。HSR环网里随便拔掉一根网线，环网变成线型拓扑，此时业务帧仍然应该从另一个方向到达接收端，整个过程抓包工具看到的序列号不能出现跳跃。这个测试做十次、二十次，如果每次都是零丢包，那IP核核心功能就算通过了。

4. PS端驱动与整机联调：数据怎么从PL到APP

4.1 数据通路设计：DMA、中断和缓冲

IP核通过了协议验证，接下来就是让它和PS端软件协作。这时整个系统里数据到底怎么走，直接决定了后续开发的顺畅程度。

最常见的方式是IP核内置或者外接AXI DMA，把去重后的以太网帧直接搬到PS的DDR里。DMA描述符一般用环形队列，收包和发包各维护一套。如果IP核本身不带DMA，那就在IP核的出口接一个Xilinx AXI DMA IP核，把流式接口转换成Memory Map接口。数据送达DDR后，由DMA的中断告诉CPU有新的包到达，软件再轮询描述符取包。

这里有一个设计上的选择：PS侧到底是跑裸机还是Linux。如果你做的是电力保护装置这类硬实时设备，裸机加轻量协议栈可能更合适，双向GOOSE和SV报文要求确定性的时延，Linux调度会带来不确定性。如果你的产品是一台工业网关、PLC或者数据采集器，Linux生态更丰富，开发效率高，我项目里大部分情况是跑Linux，配合PREEMPT_RT补丁可以在一定程度上缓解实时性焦虑。

无论裸机还是Linux，都要注意DMA缓冲区的对齐问题。以太网帧头部如果做缓存对齐，对软件处理效率很关键。有的IP核可以通过寄存器设置是否让接收帧从IP头对齐（即跳过前14字节以太网头），这样上层协议栈拿到的数据直接就指向IP头，省去一次拷贝。这个功能虽小，但在大流量下对CPU占用率影响很大。

4.2 Linux下配置冗余网络口的几个坑

IP核在PL里完成了冗余处理，对Linux来说，它看到的就是一个普通的以太网口。这个逻辑口既可以是你自研驱动的接口，也可以直接绑定到PS GEM上去。下面说几个我踩过的Linux配置坑。

第一个坑是MAC地址不一致。HSR/PRP要求每个节点的两个物理口和逻辑口MAC地址必须保持一致，否则对端节点的MAC学习表会漂移。如果你用Linux自带驱动，两个物理口都绑了同一个MAC，这本身没问题，但要注意驱动会不会在上电时自动给每个口分配不同的随机MAC。解决方式是在设备树里给两个口都显式指定本地MAC地址，并且把它和IP核寄存器的节点地址配成同一个值。

第二个坑是VLAN处理。电力行业现场经常用VLAN来隔离业务网络，HSR/PRP的冗余帧如果带着VLAN tag，IP核识别时需要知道VLAN优先级字段的位置。Linux侧如果启用VLAN子接口，默认会自己加VLAN头，这会导致和IP核的VLAN剥离功能冲突。我的经验是：IP核和Linux驱动只保留一方做VLAN收发，另一方设成透传，不要两边都处理。

第三个坑是流控和巨型帧。如果现场需要传输大文件或者高清视频，网卡的MTU可能要从1500调到9000。此时必须同步检查IP核配置里的最大帧长参数是否兼容9000字节，PHY芯片是否支持巨型帧。我在项目里遇到过MTU改到9000后系统频繁丢包，查了半天发现是PHY的寄存器里巨型帧接收没打开。

第四个坑，也是运维中最常遇到的——网口ping不通。遇到这个问题不要急着查驱动，先画一条数据链路图：APP到内核协议栈，到驱动，到DMA描述符，到IP核接收FIFO，到PHY，到网线，到对端。逐段做loopback测试，可以快速定位瓶颈。硬件上，PHY支持自环，IP核一般也带数字环回寄存器，软件里可以用ethtool做该接口的回环自测。每一段都通了，问题自然就缩小到某一块了。

4.3 性能测试：用数据说话

冗余协议做得好不好，最终要靠指标说话。我在项目中会给新板卡做三组基础测试：线速吞吐测试、故障切换测试、时延测试。

线速吞吐测试用Iperf3或专业的网络测试仪。HSR/PRP双口都启用，一个口作为抓包入口，另一个口作为回环出口，测试双向同时打满的吞吐率。注意HSR和PRP的带宽占用方式不同：PRP在两个独立网络上各自占一份带宽，HSR在同一个环内会重复发送，但同一时刻只占一条链路带宽。测试结果要结合这两种协议特点来分析。

故障切换测试是HSR/PRP的招牌项目。测试方法是在环网中插入一个可控的端口通断设备（或者直接设计一个用继电器控制网线通断的测试盒），每秒钟切换一次网络状态，连续跑24小时，统计丢包数。我用这种方法实测过几个IP核，真正的无缝冗余方案能做到0丢包，而有些实现虽然在正常情况下表现良好，但切换瞬间会丢几个帧，这种问题必须靠长时间压力测试才能暴露。

时延测试用硬件时间戳最准。在FPGA里打一个时间戳计数器，在IP核入口端记录帧到达时刻，在出口端记录帧转发时刻，两者相减就能得到IP核内部转发时延。如果IP核支持cut-through模式，时延可以做到几微秒；如果是store-and-forward模式，时延会随帧长增加。从实际应用角度看，电力保护报文对时延要求严格，务必选支持cut-through的IP核，或者至少确认存储转发模式下时延是否可接受。

5. 我踩过的几个坑，整理成排查清单

5.1 问题一：SGMII连不上，PHY问题还是时钟问题？

现象：PHY的link状态寄存器显示没有连接，甚至MDIO都读不到PHY ID。

排查步骤：先用示波器量PHY的125MHz参考时钟是否存在，摆幅是否达标，频率是否准确。然后确认PHY的reset引脚时序，很多PHY要求复位后等待固定时间才能访问MDIO。再检查PHY配置管脚的上下拉电阻，SGMII模式、铜缆模式、主从模式是否设置正确。最后看MDIO的地址是否和硬件一致，有时候PHY地址和板上其他器件冲突会导致总线挂死。

我遇到过一次很隐蔽的问题：PHY的电源正常，时钟正常，MDIO地址也没冲突，但死活link不上。后来发现是SOM模块的GTX参考时钟输出到PHY的时钟路径上多了一颗电容，容值选大了之后信号上升沿变缓，导致接收端时钟恢复失败。换小电容后问题消失。时钟路径上的每颗器件，都要严格按手册推荐的容值和走线处理。

5.2 问题二：PRP双网配置了，但接收端一直在丢帧

现象：两个独立网络都正常，节点之间能互相ping通，但吞吐量稍大就丢帧。

原因分析：PRP接收端需要通过RCT里的序列号去重，如果双网的帧到达时间差很大，接收端缓存设计不足就会溢出。另外，PRP要求两个LAN的拓扑结构和转发时延尽量一致，如果LAN A经过三层交换机，LAN B是直连网线，时延差会被放大，接收端FIFO深度不够就会丢。

解决办法：一是把IP核的接收FIFO深度调大，这个参数在IP核生成时就要预留好，后期改不了；二是检查IP核有没有“先到先得”的输出策略，即同一个序列号的帧，哪一份先到就放行哪一份，后到的直接丢弃，这种策略对双网时延差很敏感；三是检查两端设备的RCT格式，有些定制的RedBox产品RCT字段里的LAN ID和你设备预期不一致，也会导致去重失效。

5.3 问题三：Zynq网口ping不通，从PL到PS一步步定位

现象：SOM板卡插入网线，PC端网络图标显示已连接，但ping不通板卡IP。

这种问题我见过太多次，原因分布在从物理层到应用层的各个位置。定位思路如下：

第一步，看PHY层：PHY的link灯和寄存器状态确认物理链路正常。第二步，看IP核层：用ILA抓IP核接收端口，确认板卡发过来的ARP请求帧有没有到达FPGA内部。如果ILA能抓到帧，但PS侧收不到中断，问题在IP核到DMA之间。第三步，看驱动层：先确认网卡在Linux里有没有正常注册，ifconfig -a能否看到eth口，再查驱动中断号和DMA描述符状态。第四步，看应用层：ping不通很多时候是IP地址没配、子网掩码不对、防火墙挡了ICMP。

特别提醒一句：用ILA抓信号时，触发条件不要设得太复杂，直接设“帧开始有效信号上升沿”即可。如果长时间不触发，先把万用表量到PHY的TX信号，再倒推问题。

5.4 问题四：故障切换瞬间还是有丢包，怎么处理

现象：正常通信零丢包，但拔网线的一瞬间丢了几帧。

这套冗余协议号称零切换时间，如果出现切换丢包，先不要怀疑协议本身，而是检查你的实现。可能原因有几个：

一是IP核的去重表在链路切换后需要重新学习，而学习期间收到的帧因查表失败被丢弃。这种问题取决于IP核实现的细节，有些IP核在收到“已在表中”的重复帧时直接丢弃，同时更新表项老化时间；如果表项没学到，会把唯一的一份也丢掉。

二是接收端DMA或驱动缓冲不够。切换瞬间，双份帧可能会在极短时间内同时到达接收端，如果DMA队列深度不足，硬件没有地方放这些帧，丢帧就发生了。解决方式是调大DMA描述符数量，或者确认IP核内部有没有足够深度的排队缓存。

三是PHY的自动协商状态机在链路抖动时重新协商，导致几百毫秒内端口不可用。这个问题更常见，解决方式是在PHY初始化时关闭自动协商的重新触发，配置成锁定状态，只靠链路状态中断上报链路变化，不重新协商。

我把这个章节整理成一个排查速查表，方便大家保存：

6. 产品化之前的几点提醒

6.1 从开发板到量产板，注意哪些差异

实验室里SOM加开发板能跑通，和真正做成一款可量产的产品之间，还有很长的路。第一件事是确认SOM厂商有没有提供完整的量产资料，包括生产测试固件、温度老化报告、元器件生命周期承诺。工业客户的采购周期长，一款产品可能卖五到十年，SOM核心芯片停产会带来很大麻烦。

第二件事是网口防护设计。开发板上通常只有简单的变压器和RJ45，但工业现场环境远比实验室严酷，需要在PHY前端加TVS管，加共模电感，网口金属件接地处理。注意：TVS管的结电容不能太大，否则会吃掉高速信号的边沿，导致信号质量恶化。我一般选结电容小于1pF的型号，并且做信号完整性仿真确认。

第三件事是固件升级机制。HSR/PRP的IP核是FPGA逻辑，产品交付后如果发现协议处理BUG，需要支持现场升级PL固件。最简单的方案是做双镜像：一个出厂固件区，一个运行固件区，升级时先写入备用区，校验通过后再切换。PS端的应用也要支持远程升级，OTA做好版本回滚。

6.2 测试工装与老化，别省这一步

产品量产前，如果有条件一定要建一套自动化测试工装。我的做法是：一台测试工装的PC上跑Python脚本，通过串口和被测板卡通信，自动完成PHY寄存器检查、IP核寄存器检查、MAC地址烧写验证、环网丢包测试、长时间压力测试。每个板卡出厂前至少跑2小时的满负荷吞吐测试，再跑一次故障注入测试，确保切换零丢包。这样做的目的不是测功能，而是筛掉早期失效的元器件和虚焊点，老化测试能发现大部分焊接问题和元器件不良。

另外，建议在出货固件里保留一个隐藏的诊断模式。当现场反馈通信异常时，通过诊断模式可以快速读取所有IP核寄存器的状态、PHY寄存器状态、DMA描述符状态和网络统计信息。这个功能在远程支持时是神器，能省下大量差旅成本。

最后再分享一个我自己常用的技巧：在产品上留一个调试用的串口，把IP核内部的计数器（收帧数、发帧数、丢弃帧数、重复帧数、CRC错误数）通过串口周期打印出来。正常运行时这些计数器都是零或者增长很规律，一旦有异常，现场看一眼计数器的走势，往往比远程抓包更能快速定位故障方向。