文章目录概要整体架构流程功能特点测试调试过程中遇到问题概要随着数据中心、高性能计算HPC、人工智能训练集群和分布式存储系统对网络带宽需求的爆炸式增长10G/25G 以太网已难以满足新一代应用对吞吐量和延迟的要求。40G/50G/100G 高速以太网已成为数据中心主流互联标准而在 FPGA 中以纯硬件逻辑方式实现 TCP/IP 协议栈TCP Offload EngineTOE相比传统软件协议栈和软核处理器方案具有以下显著价值1、线速吞吐能力纯 FPGA 硬件流水线实现 TCP 协议处理数据通路位宽达 256-bit在 156.25MHz/322.26MHz 网络时钟下可实现 40G/100G 线速收发彻底消除 CPU 协议栈处理瓶颈单链路吞吐较软件方案提升 10 倍以上。2、超低延迟硬件逻辑处理 TCP 状态机、滑动窗口、重传控制等机制端到端处理延迟在微秒级较软件 TCP 协议栈毫秒级降低 2-3 个数量级满足高频交易、RDMA 替代、存储 NVMe-oF 等对延迟敏感的应用场景。3、CPU 卸载将 TCP/IP 协议处理从主机 CPU 完全卸载至 FPGA释放 CPU 算力用于业务计算。在 100G 线速下可释放 CPU 数十核心的处理能力显著降低系统 TCO总拥有成本。4、确定性时延硬件逻辑处理具有确定性的处理时延不存在软件协议栈因中断调度、上下文切换、缓存未命中等导致的抖动适合实时系统和确定性网络应用。5、灵活可定制提供源码级别 IP用户可根据应用场景灵活调整连接数、缓冲区大小、MSS、窗口规模等参数并可在 FPGA 内部直接与用户逻辑如 AI 加速器、数据压缩、加解密无缝对接避免 PCIe 总线往返开销。6、高集成度将 MAC、PHY 接口、ARP、ICMP、UDP、TCP 协议栈、DDR 缓冲管理集成于单颗 FPGA减少板级器件数量提高系统可靠性支持 40G/50G/100G 多速率自适应7、生态兼容实现标准 TCP/IP 协议与现有网络设备、操作系统Linux/Windows、应用软件iperf、NVMe-oF、iSCSI完全兼容无需修改上层应用即可加速。整体架构流程下图为本 IP 核的整体架构框图以 network_stack.sv 为顶层集成 TOE、UDP、ARP、ICMP、网络控制器及 DDR 内存管理单元功能特点该 IP 具备以下功能特点1、对外PHY接口采用Xilinx CMAC100G/50G/40G Media Access Controller或 XXV Ethernet MAC通过内部 AXI-Stream 接口对接应用层接口采用标准 AXI-Stream AXI-Lite 接口易操作2、支持可配置连接个数默认最大支持 65535 条 TCP 会话受哈希表资源限制典型配置为 1024-16384 条并发连接3、所有连接共享 DDR 发送缓冲区每个连接具备独立的接收缓冲区缓冲区大小通过 DDR 容量动态配置4、支持256-bit宽带数据通路单周期可处理32字节数据配合156.25MHz 时钟实现 40G/100G 线速5、支持 TCP 与 UDP 双协议栈并行工作可同时进行 TCP 协议卸载和 UDP 数据收发6、支持标准以太网帧和巨帧Jumbo Frame巨帧大小可选择配置最大 9000 字节。测试QSFP光口FPGA开发板需要至少拥有1路QSFP光口且单Lane线速率至少支持25G bps此外还需要QSFP光模块和光纤用于连接40网卡我的FPGA开发板QSFP光口连接如下调试过程中遇到问题1、Ping 通TCP 握手失败SYN 包丢失ICMP ping 正常TCP SYN 发出收不到 SYN‑ACKWireshark 大量 TCP Retransmission 重传 SYN 包PAD 缺失场景下对端抓包完全看不到 SYN。抓包可见多条[TCP Retransmission] SYN无 SYN‑ACK 应答。根因SYN 短帧缺少 PADIP/TCP 校验和错误ARP 解析异常。解决方案增加 PAD 补齐最小帧保证输出到 CMAC 报文≥64 字节校验 IP、TCP 校验和TOE 硬件卸载打开或软件完成校验和计算2、stat_rx_bad_fcs 持续 / 随机上报FCS 校验错误现象CMAC 收到帧直接丢弃下游 TCP/IP 收不到报文Wireshark 无对应报文AXIS 输出 payload 错乱根因SerDes 物理误码AXI‑Stream 握手时序错误TX 短帧缺少 PAD 填充40G CMAC 不会自动补 PAD。解决方案自环测试区分是物理层还是用户逻辑问题校验 AXI‑Stream 握手禁止帧截断、非法 tlast用户逻辑必须手动补 PAD保证目的 MAC~FCS 总长度≥64 字节检查发送端 FCS 生成逻辑。3、TOE 作为客户端关闭连接的时候不会发送最后ACK根因 rx_engine.cpp 的 ACK 处理中缺少 FIN_WAIT_1 → FIN_WAIT_2 的状态转换导致客户端不会发送 ACK 响应。原设计将 CLOSE_WAIT 和 FIN_WAIT_2 合并了客户端收到 FINACK 时ACK 和 FIN 是分开处理的 1. ACK 部分进入 case 1 但缺少 FIN_WAIT_1 → FIN_WAIT_2 的转换2. FIN 部分进入 case 4 但客户端仍处于 FIN_WAIT_1 状态转换逻辑错误4、ARP不解析现象板卡经过多次建立连接、断开连接操作后主机可学习到板卡 ARP 表项并向板卡发送 ARP 请求报文但ip_handle模块不再将 ARP 报文分发至 ARP 处理模块ARP 报文无法被解析处理。根因根因为 TOE IP 核输出TREADY反压信号持续拉低造成数据通路死锁ARP 报文处理链路被阻塞。死锁链路过程TOE IP 核产生反压m_axis_TCP.TREADY为低TCP 报文滞留于ethDataFifo该 FIFO 深度仅为 4短时间内被占满detect_eth_protocol模块无法向已满的ethDataFifo写入数据模块逻辑挂起detect_eth_protocol模块停止从s_axis_raw接口读取报文上游输入通路整体阻塞后续到达的 ARP 报文无法送入ip_handler模块ARP 请求直接被丢弃。交流与合作如果您对100G TOE技术细节感兴趣、想进一步讨论FPGA高速网络设计或需要成熟的IP核授权与定制开发服务可通过以下方式交流3185283616qq.com
