1. 项目思路为什么我用Zynq SoC SOM来做HSR/PRP冗余网络1.1 HSR/PRP到底解决什么问题做工业以太网通信的工程师对IEC 62439-3这个标准应该都不陌生。HSRHigh-availability Seamless Redundancy和PRPParallel 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核集成和业务逻辑上。下面是三种方案的对比表对比维度专用ASIC独立FPGACPUZynq SoC SOMHSR/PRP IP核组网灵活性低依赖芯片固件中高寄存器可配开发难度中软件栈成熟高软硬件协同复杂中高需掌握IP核集成协议升级能力低高高PL逻辑可改可升级量产供应链风险中高低低SOM渠道稳定典型成本较低较高中等量大后可转核心板我最终选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位DDR4PL端逻辑资源更宽裕。带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模块上如果已经通过GEMPS端内置的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工业PHYPHY的模拟电源也要单独做滤波。实测下来纹波从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到APP4.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 tagIP核识别时需要知道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初始化时关闭自动协商的重新触发配置成锁定状态只靠链路状态中断上报链路变化不重新协商。我把这个章节整理成一个排查速查表方便大家保存现象可能原因排查方法SGMII link不上时钟/PHY配置/复位时序示波器量时钟查strappingMDIO读寄存器大流量丢帧接收FIFO深度不足调大FIFO检查DMA队列ping不通链路/驱动/协议栈任一环节按物理层到应用层逐段回环定位切换瞬间丢帧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错误数通过串口周期打印出来。正常运行时这些计数器都是零或者增长很规律一旦有异常现场看一眼计数器的走势往往比远程抓包更能快速定位故障方向。 基于Zynq SoC SOM的HSR/PRP无缝冗余网络实现指南
1. 项目思路为什么我用Zynq SoC SOM来做HSR/PRP冗余网络1.1 HSR/PRP到底解决什么问题做工业以太网通信的工程师对IEC 62439-3这个标准应该都不陌生。HSRHigh-availability Seamless Redundancy和PRPParallel 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核集成和业务逻辑上。下面是三种方案的对比表对比维度专用ASIC独立FPGACPUZynq SoC SOMHSR/PRP IP核组网灵活性低依赖芯片固件中高寄存器可配开发难度中软件栈成熟高软硬件协同复杂中高需掌握IP核集成协议升级能力低高高PL逻辑可改可升级量产供应链风险中高低低SOM渠道稳定典型成本较低较高中等量大后可转核心板我最终选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位DDR4PL端逻辑资源更宽裕。带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模块上如果已经通过GEMPS端内置的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工业PHYPHY的模拟电源也要单独做滤波。实测下来纹波从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到APP4.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 tagIP核识别时需要知道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初始化时关闭自动协商的重新触发配置成锁定状态只靠链路状态中断上报链路变化不重新协商。我把这个章节整理成一个排查速查表方便大家保存现象可能原因排查方法SGMII link不上时钟/PHY配置/复位时序示波器量时钟查strappingMDIO读寄存器大流量丢帧接收FIFO深度不足调大FIFO检查DMA队列ping不通链路/驱动/协议栈任一环节按物理层到应用层逐段回环定位切换瞬间丢帧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错误数通过串口周期打印出来。正常运行时这些计数器都是零或者增长很规律一旦有异常现场看一眼计数器的走势往往比远程抓包更能快速定位故障方向。