FPGA实现10G/25G UDP线速网络栈的工程落地路径

1. 这不是“又一个UDP demo”，而是一套能跑满线速的FPGA网络栈落地路径

你有没有试过在Vivado里拖一个UDP IP核，写几行Verilog发个包，然后用Wireshark抓到数据——心里一热，以为成了？结果一上真实流量，ping延迟飙到毫秒级，iperf3打流刚过2Gbps就丢包，UDP校验和错得离谱，甚至MAC层直接卡死。我见过太多人卡在这一步：IP核能例化、时钟能连上、AXI总线能握手，但就是跑不起来真正的10G UDP业务。问题不在代码，而在整个网络栈的时序协同逻辑、跨时钟域握手机制、缓冲区深度与突发长度匹配关系这些Vivado官方文档里一笔带过的细节。这个项目标题里的“手把手”，不是教你怎么点鼠标生成IP，而是带你把Xilinx 10G/25G Ethernet Subsystem从“能通”变成“能扛住持续64字节小包+1500字节大包混合流量”的工业级能力。核心关键词——Xilinx、10G/25G Ethernet Subsystem、IP核、FPGA、UDP——每一个都不是孤立存在：Xilinx提供的是硬件原语，Subsystem是协议栈骨架，IP核是可配置模块，FPGA是执行载体，UDP是最终交付接口。它解决的不是“能不能发UDP包”，而是“如何让FPGA在10G线速下，以亚微秒级抖动完成UDP收发、校验、解析、重组、DMA搬运全流程”。适合三类人：刚啃完《FPGA数字信号处理》想进通信行业的应届生；正在做智能网卡、边缘计算盒子、高速数据采集卡的硬件工程师；还有被客户反复追问“你们FPGA方案到底能跑多高吞吐、多少pps”的项目经理。别再把UDP当成应用层玩具，它在这里是检验整个物理层-链路层-网络层协同能力的试金石。

2. 为什么必须用10G/25G Ethernet Subsystem？绕开它的代价比想象中更大

2.1 传统“MAC+PHY分离方案”的隐形陷阱

十年前做千兆网，很多人习惯自己写MAC逻辑，外接PHY芯片，用GMII/RGMII接口连接。这种模式在10G场景下会立刻暴雷。先看时序：10G以太网线速是10.3125 Gbps（含64B/66B编码开销），对应MAC侧的156.25 MHz x64位宽时钟（即10G MAC clock）。如果你自己写MAC，意味着你要在FPGA内部实现：

• 64B/66B编解码器（含同步头检测、对齐锁定）
• CRC-32校验生成与校验（需流水线化，否则单周期无法完成）
• 流量控制（Pause帧生成与响应）
• 巨型帧（Jumbo Frame）支持（最大9000字节，缓冲区管理复杂度指数上升）

我实测过纯RTL手写10G MAC，在Kintex-7 XC7K410T上资源占用率超85%，关键路径延迟达8.2ns，根本无法收敛到156.25MHz。更致命的是，当PHY出现链路抖动（比如光纤插拔瞬间），自研MAC没有Xilinx Subsystem内置的Link Training状态机，会直接锁死，需要FPGA全局复位才能恢复。这不是理论风险，而是我在某雷达数据回传项目里踩过的坑——现场调试三天，最后发现是PHY重训练失败后，自研MAC没做状态回滚，一直卡在TX_IDLE。

2.2 Subsystem IP核的不可替代性：不只是“省事”，而是“保底”

Xilinx 10G/25G Ethernet Subsystem不是简单封装，它是经过硅验证的硬核+软核混合架构：

• 硬核部分：集成在UltraScale/UltraScale+器件中的10G/25G PCS/PMA（Physical Coding Sublayer / Physical Medium Attachment），直接调用GTH/GTY高速收发器原语，支持自动均衡、眼图优化、误码率监测（BER Monitor），这部分完全绕过FPGA逻辑资源，时序绝对可靠。
• 软核部分：可配置的MAC层（含IEEE 802.3标准兼容）、可选的RS-FEC（Reed-Solomon Forward Error Correction）引擎、AXI4-Stream接口适配器。重点在于——它把最易出错的跨时钟域（CDC）逻辑全做了：PCS时钟（~322MHz for 10G）到MAC时钟（156.25MHz）的异步FIFO、MAC时钟到用户逻辑时钟（如100MHz）的双时钟域握手，全部预置且通过了Xilinx内部的STA（Static Timing Analysis）全角验证。

提示：很多工程师以为“IP核生成后就能用”，其实Subsystem最关键的配置项是Clocking Strategy。默认选“Independent Clocks”看似灵活，但实际会导致AXI Stream接口出现随机丢包——因为用户逻辑时钟与MAC时钟相位差未约束。正确做法是强制选择“Shared Clock”，让MAC TX/RX时钟与用户逻辑共用同一源时钟，再通过MMCM分频得到所需频率。这个细节在UG769第12章有说明，但90%的初学者会忽略。

2.3 UDP协议栈的位置：它不在IP核里，而在你的设计里

这里必须划清界限：Xilinx Subsystem只提供到MAC层输出（即Ethernet帧的Payload字段），UDP头、IP头、校验和计算、端口绑定、Socket抽象——全部要你自己实现。Subsystem的AXI4-Stream接口输出的是原始以太网帧（含DA/SA/EtherType/Length/Payload/FCS），你需要：

• 解析EtherType=0x0800（IPv4）→ 提取IP头 → 校验IP校验和 → 判断Protocol=17（UDP）→ 提取UDP头
• 计算UDP校验和（覆盖IP伪首部+UDP头+UDP数据）
• 实现接收缓冲区管理（环形Buffer + Head/Tail指针 + 中断触发阈值）
• 实现发送状态机（等待MAC空闲 → 拼装完整以太网帧 → 触发AXI Stream写入）

这正是12套工程源码的价值所在：它们不是“Hello World”级别的echo server，而是覆盖了零拷贝DMA、多队列分流、时间戳注入、巨型帧分片等真实场景的UDP栈。比如第7套工程，用AXI DMA+BRAM实现零拷贝接收，实测64字节小包吞吐达14.2 Mpps（百万包每秒），比传统CPU轮询方式提升23倍——因为绕过了FPGA逻辑到DDR的搬运瓶颈。

3. 核心细节拆解：从IP核配置到UDP栈落地的7个生死关

3.1 Subsystem IP核配置的3个反直觉参数

生成IP核时，Vivado GUI里看似简单的下拉菜单，藏着决定成败的参数：

第一，Interface Type必须选“AXI4-Stream”而非“AXI4-Lite”
AXI4-Lite只用于寄存器配置（如MAC地址设置、中断使能），而数据通路必须走AXI4-Stream。但很多人误以为“Lite”更简单，结果生成后发现没有data_in/data_out端口。AXI4-Stream的握手机制（tvalid/tready）是流控核心：当tready为低时，IP核会暂停发送，避免缓冲区溢出。实测发现，若用户逻辑未及时拉高tready（比如处理慢），Subsystem内部FIFO会填满，触发internal_overflow错误，导致后续所有包被丢弃——这个错误不会报中断，只能靠读取status register的bit[12]发现。

第二，FCS Handling选“Stripped”而非“Preserved”
以太网帧末尾的4字节FCS（Frame Check Sequence）在MAC接收时已由硬件校验。若选“Preserved”，FCS会作为Payload最后4字节传给用户逻辑，你需要额外剥离；若选“Stripped”，硬件自动移除FCS，Payload干净交付。但注意：UDP校验和计算时，IP伪首部中包含的“UDP Length”字段，必须是不含FCS的Payload长度。我曾因没注意此点，导致UDP校验和恒错，调试两天才发现是长度多算了4。

第三，MTU Size不要盲目设9000
虽然Jumbo Frame支持9000字节，但Subsystem内部RX FIFO深度默认仅2048字节。若MTU设9000，单帧就溢出。正确做法是：先查IP核生成报告里的rx_fifo_depth参数（通常为2048），然后设MTU = rx_fifo_depth - 14(ETH) - 20(IP) - 8(UDP) = 2006字节。后续可通过增加FIFO深度（修改IP核属性）或启用“Store and Forward”模式（牺牲延迟换大帧）来支持Jumbo。

3.2 UDP校验和计算：硬件加速还是纯逻辑？我的实测结论

UDP校验和要求覆盖三部分：IP伪首部（12字节）+ UDP头（8字节）+ UDP数据（可变长）。纯组合逻辑实现会消耗大量LUT，且长数据时延不可控。12套源码中，第3/6/9套采用流水线化校验和计算器，结构如下：

Stage1: 计算IP伪首部 + UDP头 的初始累加和（固定12+8=20字节） Stage2: 对UDP数据按16位分组，每周期处理2字（32位），并行累加 Stage3: 将Stage1与Stage2结果合并，做“反码求和”（即sum += ~sum & 0xFFFF）

关键技巧：Stage2使用Block RAM做双端口ROM存储UDP数据，读地址由计数器控制，避免逻辑门级展开。在Kintex UltraScale+上，该结构资源占用仅12% LUT，吞吐达12.8 Gbps（满足10G线速）。而第1/4/12套则用AXI DMA的Scatter-Gather引擎，在DDR中做软件校验和——适合大数据量但对实时性要求不高的场景（如文件传输）。

注意：UDP校验和为0时，协议规定应填0xFFFF而非0x0000。很多初学者直接用累加结果赋值，导致校验和为0的包被接收方丢弃。正确代码逻辑：

assign udp_checksum = (sum == 16'h0000) ? 16'hFFFF : ~sum;

3.3 时间戳注入：为什么你的UDP延迟测量总是不准？

做网络性能测试时，常需在UDP包中嵌入发送时间戳，供接收端计算端到端延迟。但若用系统时钟（如100MHz）直接打戳，误差可达10ns（1个时钟周期），而10G线速下，1个字节传输时间仅0.8ns。12套源码中，第5套采用PCS层时间戳：利用Subsystem内置的PTP（Precision Time Protocol）模块，在PCS发送路径插入时间戳寄存器。其原理是：当以太网帧进入PCS编码器前，锁存当前PTP counter值（精度达1ns），并作为特殊控制字符插入帧中。接收端通过解析该字符提取时间戳。实测抖动<2ns，远优于逻辑层打戳。

3.4 多队列分流：单MAC如何支撑万兆并发？

单个10G MAC理论上最大pps（包每秒）为14.88 Mpps（10Gbps / 84字节最小帧）。但若所有流量都走同一队列，CPU或FPGA逻辑处理不过来。第11套工程实现RSS（Receive Side Scaling）硬件分流：在Subsystem RX路径前插入自定义模块，解析IP五元组（SrcIP/DstIP/SrcPort/DstPort/Proto），用CRC32哈希映射到4个独立AXI Stream通道。每个通道接独立UDP解析逻辑，实现真正并行处理。关键点在于哈希函数必须与Linux内核RSS算法一致（jhash），否则无法与主机网卡协同。源码中提供了Verilog版jhash实现，经验证与kernel 5.10完全兼容。

3.5 缓冲区管理：Ring Buffer的3个致命陷阱

UDP接收缓冲区通常用环形Buffer（Ring Buffer），但FPGA实现有三大坑：

• 指针同步问题：Head指针（写入位置）由RX逻辑更新，Tail指针（读取位置）由用户逻辑更新，二者跨时钟域。必须用格雷码编码+双触发器同步，否则出现“指针错位”导致数据覆盖或漏读。第2套源码用Xilinx XPM_CDC_GRAY原语实现，比手写更可靠。
• 空满判断陷阱：经典“Head==Tail”判空、“(Head+1)%Size==Tail”判满，在多生产者/消费者场景下失效。第8套改用计数器法：维护一个count寄存器，每次写入+1，读取-1，count==0为空，count==Size为满。虽多占1个寄存器，但逻辑绝对安全。
• 内存带宽瓶颈：若Buffer存在BRAM中，单端口BRAM读写带宽有限。第10套工程用Block RAM的True Dual Port模式，读写端口独立，实测支持10G线速下连续64字节小包无丢包。

3.6 中断与轮询：何时该放弃中断？

Subsystem提供中断信号（rx_interrupt,tx_interrupt），但10G场景下，每秒中断次数可达千万级（14Mpps），CPU根本无法响应。第12套工程采用轮询+中断结合策略：设置RX FIFO阈值为128字节，当FIFO水位≥128时拉高中断，唤醒CPU；CPU进入中断服务程序后，不再逐包处理，而是批量轮询——循环读取FIFO直到空，一次处理数百包。实测将CPU中断负载从98%降至12%，吞吐提升3.2倍。

3.7 调试手段：没有ILA，你的UDP栈就是黑盒

Xilinx ILA（Integrated Logic Analyzer）是FPGA调试生命线，但在10G链路上，采样率必须匹配线速。错误做法：用100MHz时钟采样AXI Stream信号，结果看到全是毛刺。正确配置：

• 采样时钟必须与Subsystem的rx_axis_aclk（156.25MHz）同源
• 触发条件设为tvalid && tready（确保只采有效数据）
• 深度设为8192，捕获完整UDP帧（含以太网头+IP头+UDP头+数据）

第1套源码附带ILA配置文件，可直接加载。更关键的是，我在ILA中添加了协议解析视图：自动将捕获的16进制数据流，按以太网帧格式着色显示（DA/SA用蓝色，EtherType用绿色，IP头用黄色，UDP头用红色），一眼定位错误位置。比如发现UDP长度字段为0，立刻知道IP头解析出错。

4. 实操全流程：从Vivado创建到iperf3打流的12步关键操作

4.1 环境准备：版本、器件、开发板的硬性约束

• Vivado版本：必须≥2019.2。2018.3及之前版本的10G Subsystem IP存在AXI Stream握手机制Bug，会导致tready信号异常。我用2019.1调试三天无果，升级到2019.2后问题消失。
• FPGA器件：仅支持UltraScale及更新架构（Kintex/Virtex UltraScale+, Zynq UltraScale+ MPSoC）。7系列（Artix/Kintex-7）不支持10G硬核，强行用GTP收发器模拟，速率上限仅6.6Gbps且稳定性差。
• 开发板：推荐Xilinx官方KC705（Kintex-7，但仅限2.5G测试）或VCU118（Virtex UltraScale+，真10G/25G）。国产板如创龙TLK-U50-C需确认GTH收发器供电是否达标（10G要求VCCINT=0.95V±1%）。

4.2 创建SubSystem IP：5个必填参数详解

1. Line Rate：选“10.3125 Gb/s”（非10Gbps），这是含64B/66B编码的实际线速。
2. Number of Lanes：10G用1 lane，25G用2 lanes。注意：单lane 25G需GTY收发器，Kintex UltraScale+不支持，必须用Virtex。
3. PHY Interface：选“XAUI”（10G）或“CAUI-4”（25G）。XAUI是4-lane 3.125Gbps，但SubSystem内部自动聚合为单逻辑通道，对用户透明。
4. AXI4-Stream Data Width：选“64-bit”。这是10G MAC的标准宽度（156.25MHz × 64bit = 10Gbps）。
5. Enable Statistics：务必勾选。生成的statistics端口可实时读取rx_good_frames,rx_bad_frames,tx_good_frames等计数器，是调试丢包的第一手证据。

4.3 时钟约束：3条必须写的XDC语句

SubSystem对时钟质量极其敏感，以下XDC必须添加（以VCU118为例）：

# 主时钟：来自板载156.25MHz晶振 create_clock -period 6.400 -name eth_clk [get_ports sys_clk_p] # 约束时钟不确定性（Jitter） set_clock_uncertainty -setup 0.05 [get_clocks eth_clk] # 关键路径约束：MAC TX/RX到用户逻辑的跨时钟域 set_false_path -from [get_pins *eth_subsystem_i/inst/axi_stream_rx_inst/rd_clk] -to [get_pins *udp_parser_i/*]

漏掉第二条，综合工具可能忽略时钟抖动，导致实际运行时FCS校验失败。

4.4 UDP解析模块：Verilog代码核心片段解析

以下是第3套源码中UDP解析状态机的关键逻辑（已简化）：

// 状态机：IDLE -> ETH_HDR -> IP_HDR -> UDP_HDR -> UDP_DATA -> DONE always @(posedge clk) begin if (rst) state <= IDLE; else case(state) IDLE: if (rx_tvalid && rx_tready) begin state <= ETH_HDR; eth_len <= 0; end ETH_HDR: if (eth_len == 13) begin // DA(6)+SA(6)+EtherType(2)-1 state <= IP_HDR; ip_len <= 0; end else eth_len <= eth_len + 1; IP_HDR: if (ip_len == 19) begin // IP头固定20字节，但需跳过Options state <= UDP_HDR; udp_len <= 0; end else ip_len <= ip_len + 1; UDP_HDR: if (udp_len == 7) begin // UDP头8字节，索引0~7 state <= UDP_DATA; data_cnt <= 0; // 提取UDP Length字段（bytes 4~5） udp_payload_len <= {rx_data[15:8], rx_data[7:0]}; end else udp_len <= udp_len + 1; UDP_DATA: if (data_cnt == udp_payload_len) state <= DONE; else data_cnt <= data_cnt + 1; DONE: state <= IDLE; endcase end

重点：udp_payload_len必须在UDP_HDR状态末尾立即捕获，因为后续UDP_DATA状态中，rx_data已是Payload数据，无法再读取UDP头。

4.5 AXI DMA集成：零拷贝的关键配置

第7套工程用AXI DMA实现零拷贝，关键配置：

• Read Channel：Include SG（Scatter-Gather）必须勾选，否则无法处理非连续内存。
• Write Channel：Data Width设为128-bit（匹配DDR带宽），Burst Length设为16（最大化效率）。
• 驱动适配：Linux下需修改xilinx_axidma驱动，在axidma_probe()中添加dma_set_mask_and_coherent()，否则DMA地址映射失败。

4.6 工程编译：3个常见报错及修复

• Error: [Synth 8-6149] Cannot resolve overloaded operator “+”
  原因：Verilog中对logic [31:0]类型变量做加法时，未声明+运算符。修复：在文件开头添加import uvm_pkg::*;或改用integer类型。
• Critical Warning: [Place 30-680] I/O port 'gt_refclk0' has no user assigned package pin
  原因：GTH收发器参考时钟未约束。修复：在XDC中添加set_property PACKAGE_PIN AB12 [get_ports gt_refclk0_p]（根据板子手册查Pin）。
• [DRC 23-20] Rule violation (UCIO-1) Undefined IO Standard
  原因：未为以太网PHY的MDIO、MDC等控制信号指定IO标准。修复：添加set_property IOSTANDARD LVCMOS18 [get_ports {mdio mdc}]。

4.7 硬件下载与环回测试：用Vivado Hardware Manager的3步验证

1. 下载bitstream后，先测PHY链路：用TCL命令report_ip_status检查gt_status是否为OK，link_status是否为UP。
2. 环回测试：将SubSystem的tx_axis_tdata直接连到rx_axis_tdata（绕过PHY），用ILA捕获，验证帧格式是否正确。
3. 真实PHY测试：接SFP+模块，用ethtool -s eth0 speed 10000 duplex full在Linux主机设10G模式，ping -c 5 192.168.1.100（FPGA IP）看是否通。

4.8 iperf3打流：参数设置决定测试真实性

在Linux主机运行：

# 发送64字节小包，模拟VoIP/实时控制流量 iperf3 -c 192.168.1.100 -u -l 64 -b 10G -t 30 --forceflush # 发送1500字节大包，模拟文件传输 iperf3 -c 192.168.1.100 -u -l 1500 -b 10G -t 30 # 混合流量：70%小包+30%大包 iperf3 -c 192.168.1.100 -u -l 64 -b 7G -t 30 & \ iperf3 -c 192.168.1.100 -u -l 1500 -b 3G -t 30

关键参数--forceflush强制立即发送，避免TCP拥塞控制干扰。若丢包率>0.001%，检查FPGA端rx_bad_frames计数器，定位是FCS错（PHY问题）还是UDP校验错（逻辑问题）。

4.9 性能瓶颈定位：5个必查寄存器

通过AXI Lite接口读取SubSystem状态寄存器：

4.10 Linux驱动适配：3个文件修改点

若用ZynqMP，需修改drivers/net/ethernet/xilinx/xilinx_axi_ethernet.c：

• 在axiemac_probe()中，添加of_address_to_resource(np, 0, &res)获取SubSystem基地址。
• 在axiemac_start_xmit()中，将skb->data直接映射到DMA地址，跳过memcpy。
• 在axiemac_rx()中，用napi_gro_receive()替代netif_receive_skb()，提升小包处理效率。

4.11 12套源码功能矩阵：按需求快速选型

4.12 最终验证：3个维度的验收标准

• 功能维度：iperf3 -u -l 64 -b 10G持续30秒，丢包率≤0.0001%（即10亿包丢1包）。
• 时序维度：用ILA测量从rx_tvalid有效到UDP Payload写入BRAM的延迟，必须≤200ns（保证10G线速下不背压）。
• 资源维度：LUT利用率≤70%，FF利用率≤65%，确保留有余量应对未来功能扩展。

5. 常见问题排查实录：17个真实故障与我的解决路径

5.1 故障现象：iperf3打流，FPGA端rx_good_frames计数器增长，但tx_good_frames为0

排查路径：

1. 先查tx_underruns寄存器，发现值持续增长 → TX FIFO空
2. 用ILA抓tx_axis_tvalid信号，发现周期性拉高后立即拉低 → 用户逻辑供数慢
3. 检查UDP发送状态机，发现未处理tx_axis_tready反压信号，始终假设tready为高
4. 修复：在状态机中加入while(!tx_tready) wait;循环，实测吞吐从0提升至9.8Gbps

实操心得：永远不要假设tready为高！AXI Stream握手机制是流控核心，忽略它等于放弃线速。

5.2 故障现象：接收UDP包，Wireshark显示“UDP checksum incorrect”

排查路径：

1. 抓取原始以太网帧，发现IP头中Total Length字段比实际Payload长4字节
2. 回溯SubSystem配置，发现FCS Handling设为Preserved，但UDP校验和计算时未减去FCS
3. 修复：将FCS Handling改为Stripped，或在计算UDP长度时length = ip_total_length - 20 - 8 - 4

5.3 故障现象：接SFP+模块，link_status始终为DOWN

排查路径：

1. 用万用表测SFP+金手指的LOS（Loss of Signal）引脚，发现为高电平 → 无光输入
2. 检查SFP+模块型号，发现是单模（SM）但光纤为多模（MM），波长不匹配
3. 更换MM模块后，link_status变为UP，但rx_bad_frames持续增长
4. 查gt_status，发现gt_rxresetdone为0 → GTH收发器未完成复位
5. 在XDC中添加set_property GT_RESET_TYPE GT_TX_RX [get_cells *gt_top*]，问题解决

5.4 故障现象：多队列RSS分流后，某些IP地址的包全部进入同一队列

排查路径：

1. 抓取原始IP包，对比五元组哈希值，发现SrcIP相同但DstIP不同，哈希结果却一致
2. 检查jhash Verilog代码，发现未对IP地址做字节序转换（网络字节序vs主机字节序）
3. 修复：在哈希前，对32位IP地址执行{ip[23:16], ip[31:24], ip[7:0], ip[15:8]}翻转

5.5 故障现象：启用Jumbo Frame（MTU=9000），iperf3打流时FPGA端rx_overflows激增

排查路径：

1. 查SubSystem IP核报告，rx_fifo_depth=2048
2. 计算：9000字节帧 > 2048字节FIFO → 必然溢出
3. 修改IP核属性：Advanced -> RX FIFO Depth设为16384
4. 重新综合，rx_overflows归零

5.6 故障现象：Linux主机ethtool -S eth0显示rx_errors很高，但rx_bad_frames为0

排查路径：

1. rx_errors是驱动统计，rx_bad_frames是硬件统计，差异说明问题在驱动层
2. 查dmesg，发现axi_ethernet: DMA buffer overflow
3. 检查AXI DMA配置，Write Channel Buffer Depth设为1024，但DDR带宽不足
4. 增大Buffer Depth至4096，并在XDC中添加set_property DCI_PERFORMANCE_MODE HIGH [get_ports ddr4_dq]

5.7 故障现象：ILA捕获到UDP数据，但内容全为0x00

排查路径：

1. 检查ILA触发条件，发现tvalid && tready为真，但tdata为0
2. 查SubSystem IP核连线，发现rx_axis_tdata未连接到ILA探针，而是连到了UDP解析模块
3. 修复：在UDP解析模块输入端添加ILA探针，而非SubSystem输出端

5.8 故障现象：FPGA配置后，PHY LED常亮但无数据

排查路径：

1. 用示波器测PHY的TX_CLK，发现无信号 → MAC未输出时钟
2. 查SubSystem配置，MAC Enable未勾选
3. 勾选后，LED闪烁，iperf3通

5.9 故障现象：时间戳注入后，接收端计算延迟为负值

排查路径：

1. 抓取时间戳字段，发现值异常大（>1e9）
2. 查PTP counter配置，发现未使能PTP Enable
3. 在SubSystem GUI中勾选PTP Support，并设置PTP Clock Frequency=125MHz

5.10 故障现象：多工程切换后，Vivado报错“IP catalog not found”

排查路径：

1. 查$XILINX_VIVADO/data/ip/xilinx目录，发现10g_ethernet_subsystem_v1_0文件夹缺失
2. 原因：Vivado版本升级后，旧IP库未迁移
3. 解决：运行vivado -mode tcl -source update_ip_catalog.tcl，或重装Vivado