FPGA 100G光口光模块测试实战：从GT配置到误码分析

1. 项目概述与测试目标拆解

做FPGA开发这些年，凡是和高速接口沾边的项目，最终基本都会绕到光口上来。尤其是100G这个速率档位，从数据中心到仪器仪表，从通信设备到视频传输，几乎成了标配。我这段时间正好在调试一块带100G光口的FPGA板卡，从光模块选型到GT收发器配置，从回环测试到误码分析，踩了一路的坑，也摸清了不少门道。这篇围绕“100G光口/光模块的FPGA测试实例”这个主题，把整个测试过程掰开揉碎了讲清楚，希望能帮到正在调板子或者准备入手的同行。

1.1 100G光口测试到底在测什么

先说清楚一件事：所谓100G光口，在FPGA这一侧，其实不是你想象中一根光纤插进去就能跑通那么简单。它本质上是一个高速串行收发链路，包含了光模块、连接器、PCB高速走线、FPGA内部的高速收发器（也就是GT/GTH/GTY这类SerDes）、以及上层的PCS/PMA逻辑。任何一个环节出问题，表现出来都是“链路不通”或者“误码率偏高”，但定位起来会让人非常头大。

我们这次要测的内容，拆开来无非是四块：

• 光模块本身是否工作正常，包括光口能否发光、收光灵敏度是否达标、数字诊断接口能不能读到温度、电压、光功率这些参数。
• FPGA高速收发器能否在25.78125Gbps这个线速率上稳定锁定时钟，能不能完成数据收发。
• 从FPGA逻辑到光模块之间的物理链路是否完整，包括AC耦合电容、连接器焊接、PCB走线有没有问题。
• 数据通路在跑业务流量（比如64B/66B编码后的以太网帧）时，误码率能不能达到项目要求。

说白了这个测试就是给整个100G通路做一个“体检”，体检合格了，后面跑上层业务才踏实。

1.2 什么场景会用到这个方案

这套测试方案覆盖的场景其实挺广。最常见的几类：

• 通信板卡开发：交换板、线卡上的100G上联口，板子贴完片要过老化测试、单板测试，这时候就得靠FPGA灌流量去验证光口。
• FPGA原型验证：ASIC流片前拿FPGA做原型，需要验证100G以太网MAC、PCS、RS-FEC这些IP的行为。
• 仪器仪表和测试设备：误码仪、协议分析仪的光口测试板，本质也是FPGA加光模块的结构。
• 自研高速接口方案：用FPGA做光纤传输的自定义协议，不走标准以太网，这时候光口测试更是必修课。

不管哪种场景，测试的核心路径是共通的：FPGA内部产生测试数据→高速收发器并串转换→光模块电口→光口发光→对端接收→比对数据判误码。把这条链路跑通、跑稳，项目就成功了一大半。

2. 光模块架构与选型：动手之前先搞懂对象

很多人上来就急着写代码，结果板子调不通了才回头查模块资料，这是本末倒置。光模块这个东西，看着就是个可插拔的小盒子，但内部的讲究一点不比FPGA这边少。

2.1 100G光模块的内部架构和电接口

100G光模块当前最主流的形态是QSFP28，电接口侧是4路25G差分对，每路速率25.78125Gbps（这是100G Base-R的物理层线速率，包含了64B/66B编码开销，所以不是整数25G）。

模块内部大致是这样一条链路：电接口进来4路高速差分信号→经过模块内部的驱动芯片（也就是大家常说的光模块电芯片）→调制到激光器上变成光信号发出；接收方向反过来，光信号经探测器转成微弱电信号，经过跨阻放大器（TIA）和限幅放大器（LA）放大整形，再送到电接口出去。

这里有个关键点要留意：不同档次的模块，内部DSP/CDR的处理能力不一样。有些模块（比如长距的LR4、ER4）内部带了DSP加强芯片，对接收信号有很强的均衡补偿能力；有些短距模块（比如SR4、AOC有源光缆）结构相对简单。这直接影响了你FPGA侧对信号质量的要求，以及调试时对误码的判断标准。

另外就是模块的50GHz带宽差分阻抗是100欧姆，交流耦合，FPGA到光模块连接器之间的高速线必须按100欧姆差分阻抗来设计，这是个硬性约束。

2.2 模块选型的几个关键参数

选光模块的时候，下面这几个参数一定要确认清楚，不然买回来大概率要踩坑：

特别提醒一点：100G光模块的功耗不低，一个QSFP28模块典型功耗在3.5W左右，带DSP的长距模块可能到5W以上。板卡设计时散热风扇和电源余量都要考虑进去，不然测试过程中模块温度过高，会出现莫名的误码甚至断链，这也是我实际调试中遇到过的真实教训。

3. FPGA测试系统整体设计：方案选型与回环策略

测试系统怎么搭，直接决定了调试效率。我的经验是：不要一上来就追求“完整业务流量”测试，而是把测试拆成多个层级，每一层都先证明自己OK，再叠加下一层。这样出了问题能快速定位到底在哪一段。

3.1 硬件组成与连接方式

一个典型的100G光口FPGA测试系统包括以下部分：

• FPGA板卡：需要集成支持25G速率以上的高速收发器。Xilinx UltraScale/Ultrascale+系列的GTY、Intel的E-Tile收发器都支持这个速率档。
• 光模块QSFP28：根据项目需求选择，测试环境建议备几种——短距多模SR4、单模LR4、甚至DAC铜缆。
• 光纤跳线：多模配MPO/MTP跳线，单模配LC跳线，注意模块的光口类型要匹配。
• 对端设备：可以是另一块同样的FPGA板卡，也可以是商用交换机、误码仪。
• 时钟源：给FPGA提供参考时钟，100G Base-R常用的参考时钟频率是161.1328125MHz或者156.25MHz。

如果手头只有一块板子，最常见的做法是对光模块做外部回环，或者直接在FPGA内部做回环。这一点在后面详细展开。

3.2 回环测试方案：从内部到外部的四级递进

回环测试是高速链路调试的利器。我一般把回环分成几级，逐级递进：

第一级：FPGA内部数字回环（Near-End PCS Loopback）

在FPGA逻辑侧直接把发送数据环回到接收通路，不经过GT收发器。这一级验证的是你自己的用户逻辑和数据通路对不对。这级都过不了，就别往下查了。

第二级：GT收发器PMA回环（Near-End PMA Loopback）

在GT收发器内部，串行数据经过并串转换后直接在芯片内部环回，不经过外部引脚，也不发光。这一级验证GT的PMA配置、时钟恢复、以及和PCS之间的接口是否正常。通常用IBERT或者自定义的逻辑就能跑。

第三级：外部线缆回环

用一根光纤跳线把光模块的TX和RX口短接，或者如果有多个口，用DAC线缆环回。这一级把光模块、连接器、PCB走线全部串了进来，是最接近真实链路的一种测试方式。

第四级：点对点对测

两块板卡用光纤直连，各自发各自的PRBS，然后统计对端收到的误码。这是最接近真实业务的验证方式，通常用来做最终的误码率认证和长时间老化测试。

回环层级的概念，可以说贯穿了光口调试的整个过程。你在QA报告里写“回环误码率”的时候，一定要写清楚是哪一级回环下的结果，否则数字没有可比性。

3.3 为什么强调用PRBS做压力测试

PRBS（伪随机二进制序列）是高速链路测试的标配信源。原因是它能在统计特性上模拟真实数据流，同时又是可预测的——接收端用同样的PRBS发生器对接收到的数据做比对，就能逐比特判断有没有出错。

100G以太网物理层规范里明确提到了PRBS31作为系统级误码测试的激励。PRBS31的特征多项式是x^31 + x^28 + 1，序列长度2^31 - 1，足够长，能很好覆盖到低频和高频分量。实际测试中我还常用PRBS15、PRBS23做快速粗测，因为PRBS31要跑完一个完整周期才更有意义，几分钟的短测虽然也能发现问题，但理论采样面不够。

4. 核心逻辑实现：GT收发器配置与数据通路

这块是FPGA工程师真正要写代码和调配置的地方。很多人一看到GT的配置界面就懵，其实核心就是三件事：时钟对不对、复位顺序对不对、数据接口有没有对齐。

4.1 参考时钟与GT位置规划

100G光口在FPGA上通常占用一个Quad中的4个连续GTY lane。参考时钟一个关键参数是频率。对于25.78125Gbps的线速率，参考时钟有两种常用选择：161.1328125MHz（线速率除以160）和156.25MHz（常用于带FEC的场景，配合内部的时钟倍频关系）。

在Xilinx Vivado里，GTY的线速率、参考时钟、QPLL/CPLL配置是通过 wizard 生成的transceiver IP来管理的。选线速率25.78125G，参考时钟156.25M，其他参数保持默认，一般能直接出配置。但有一个容易忽略的点：

注意：参考时钟的抖动指标非常关键。如果参考时钟来自板上的普通振荡器，务必确认它满足GT的参考时钟抖动要求。实际上遇到过不少“跑起来有误码、查了半天逻辑都没问题”的案例，最后发现是参考时钟源抖动超标。

另外，每个Quad的QPLL是共享的，如果一个Quad里4条lane跑同一个速率，用QPLL最合适。如果两条lane速率不同，就得用CPLL或者换Quad。这个在规划引脚分配的时候就要想好。

4.2 收发数据通路设计要点

以Xilinx Ultrascale+为例，100G Base-R的物理层数据通路大致是：

用户逻辑（64bit或者512bit接口）→ 64B/66B编码（如果跑标准以太网）→ 加扰 → 多通道分发（4条lane）→ GT TX接口 → 串行输出

接收侧反之：串行输入 → GT RX → 通道对齐（lane deskew）→ 64B/66B解码 → 解扰 → 用户逻辑

如果只用PRBS做物理层测试，可以跳过64B/66B，直接把PRBS数据喂给GT的并行接口。这也是IBERT工具内部的实现方式。

自定义测试逻辑时，有一个踩过的坑必须提醒：GT的并行数据接口位宽和时钟频率必须匹配。25.78125G的线速率，如果内部并行位宽是64bit，那么GT的用户时钟就是25.78125G/64 ≈ 402.8MHz。这个时钟频率已经不低了，跨时钟域处理务必小心。如果觉得时序收敛困难，可以选128bit位宽，用户时钟降到约201.4MHz，会从容很多。

一个简单的PRBS发生器的核心代码逻辑如下（Verilog示意，仅做参考）：

// PRBS31 generator, x^31 + x^28 + 1 always @(posedge clk) begin if (rst) lfsr <= 31'h7FFFFFFF; else begin // 每次产生一个bit，多bit时使用展开计算 feedback <= lfsr[30] ^ lfsr[27]; lfsr <= {lfsr[29:0], feedback}; end end

实际工程里，多bit并行PRBS生成需要用矩阵展开的方式，Vivado提供了PRBS GeneratorIP可以直接参数化调用，Xilinx Application Note（比如XAPP884）也有参考设计。除非是想练手，否则不建议自己造轮子——PRBS虽然是线性反馈移位寄存器，但并行展开后的逻辑很容易忽略相位关系，导致自收自发没问题、对端就比对不上。

4.3 IBERT与自定义误码统计怎么选

调试和测试阶段，工具会选择很关键。Xilinx的IBERT（Integrated Bit Error Ratio Tester）集成在Vivado里，通过JTAG可以直接配置GT、产生PRBS、统计误码、扫描眼图，是前期调试的利器。

但IBERT有一个局限：它只测物理层，不经过你用户的逻辑和PCS。你实际的业务可能还包含RS-FEC、以太网帧处理等。所以完整测试方案建议分两步走：

• 第一步：用IBERT做物理层摸底，确认GT配置无误、链路误码率满足要求（短时间测试至少低于1E-12，长时间测试更好）。
• 第二步：在用户逻辑里集成自定义的误码统计模块，加载真实的业务帧或者带包头的数据流，做端到端验证。

第二部的一个关键设计是加一个误码计数和告警寄存器。通过JTAG或者UART把误码数读出来，调试时能随时看实时状态，比用逻辑分析仪去抓信号高效得多。

// 误码检测与统计简例：接收PRBS与本地生成PRBS比对 always @(posedge clk) begin if (data_in == local_prbs) error_flag <= 1'b0; else begin error_flag <= 1'b1; error_cnt <= error_cnt + 1'b1; end end

当然这只是最简单的示意，真实的误码统计还需要考虑比特对齐（bit slip）和失步重同步的问题，否则一旦失步，误码计数器就会被淹没。一般做法是：连续检测到多个错误位时，强制进入重新同步流程，重新搜索PRBS序列的边界。

5. 光口物理层测试与信号完整性：眼图、光功率与PCB细节

调通了逻辑、跑通了PRBS，只代表“电通”了。光口光口，最终还是要落在光上。物理层的验证要做到心里有数，光功率和眼图是两个最直接的手段。

5.1 光功率测试与数字诊断

QSFP28模块自带数字诊断功能，通过I2C接口（SFF-8636）可以读到模块的温度、供电电压、偏置电流、发射光功率、接收光功率等。开发阶段我强烈建议在FPGA里复用I2C控制器，把模块的诊断信息读出来，串口打印到终端。这样调试时抬头就能看到：

• 发射光功率是不是在规格范围内（比如LR4单通道典型值-2~+3dBm）。
• 接收光功率是否高于接收灵敏度（LR4接收端过载一般在+4dBm左右，灵敏度在-12dBm以下，取决于具体模块）。
• 模块温度是否过高（超过75℃就要警惕了）。

如果接收光功率是-18dBm甚至更低，那大概率是光纤没插好、光口污染了或者对端没发光，不用急着去翻FPGA逻辑。别小看这个排查顺序，实际调试中，我见过太多人对着误码计数器挠头，结果发现是光纤跳线插错了口——回环的两个光口都接到同一根跳线上，但TX和RX的极性搞反了。

5.2 眼图测试：用示波器看信号质量

眼图是判断高速信号质量最直观的工具。测100G光模块的眼图需要高速采样示波器，配上光口探头（模块厂家一般是往模块的测试座里插光转电模块或者用模块自带的测试模式）。

眼图能看出来什么？简单说：

• 眼高和眼宽：眼开得越大，信号裕量越足。
• 交叉点位置：NRZ信号的交叉点应该在50%左右，偏移严重说明上升沿和下降沿不匹配，通常是驱动电路的问题。
• 模板（Mask）：IEEE 802.3ba规范里定义了100G Base-R的光口发射眼图模板，用示波器的模板测试功能可以直接判Pass/Fail。

不过说实话，在产线上或者现场调试，不是所有人都有条件配高速示波器。这时候更实用的替代方案是：用光功率计测平均光功率，配合模块内部的“发射波形劣化”告警标志做粗判。如果平均光功率正常、模块也没有告警，一般说明发射端基本正常。真正要精调信号质量，那再上示波器。

5.3 FPGA到光模块的PCB连接细节

这部分是板级设计的范畴，严格说属于测试环境的“前置条件”，但测试中很多诡异问题恰恰是这里埋的雷：

• AC耦合电容：GT和光模块之间必须串联AC耦合电容，一般用0.1uF的0402封装电容。位置靠近连接器一侧，且不能有stub。
• 差分阻抗：100欧姆差分，走线要严格控制，同时注意换层时的过孔有没有足够的回流地过孔。
• 连接器焊接：QSFP28连接器是SMT封装，引脚密集，焊接不良会导致偶发断链。板卡打样回来，建议先拿一台显微镜把连接器的引脚焊点和焊盘检查一遍。
• 电源纹波：光模块的3.3V电源纹波要控制在50mV以内，最好用LDO或者低纹波的DCDC单独供电，高速模块对电源噪声非常敏感。

这中间还有一个老生常谈但总有人犯的错误：高速信号线不要打过长的stub。在调试时如果想飞线量测信号，尽量找过孔或者测试点去量，不要随便焊根线上去——一根3cm的stub在25G速率下足以把信号质量毁掉。

6. 常见问题排查与调试实录

调试100G光口，谁都会遇到几个让人脱发的问题。我把这段时间自己遇到的和同行交流中高频出现的问题整理了一下，做成一个速查表：

6.1 链路起不来的定位思路

链路起不来，是最棘手也最常见的。每次遇到，我的排查顺序基本固定：

1. 确认光模块通电并初始化完成：I2C能不能正常读写？模块的Reset是不是被拉住了？模块的IntL/RxLos等管脚电平是否符合预期？
2. 确认GT配置无误：线速率、参考时钟频率、环路带宽这些参数。这里有个小技巧：用IBERT去试，它能自动扫描可以锁定的配置，比一点一点试寄存器高效得多。
3. 确认光通路正常：断开对端，用光功率计在光口直接测有没有光。有光但收不到，那问题在前向链路或者接收端；没光，那就直接锁定在模块或发送端，和FPGA关系都不大了。
4. 确认极性（Polarity）：QSFP28模块的lane极性不一定和PCB走线对得上，做PCB时很容易因为差分对内两根线的正负交换导致整个link失败。好在GT和光模块都支持极性翻转，在配置里把RX_POLARITY或者TX_POLARITY对应位置1就能翻转。这也是回环测试时第一个要排除的嫌疑。

6.2 误码率高怎么一步步压缩范围

误码率高的时候，不要急着改逻辑，按下面的思路来：

• 先分清是突发误码还是均匀误码。突发误码往往和电源噪声、时钟抖动有关，均匀误码则偏向信号完整性不够。
• 用IBERT把发射端和接收端分开测。只发不收，看对端误码仪报多少；只收不发，看本地误码仪报多少。哪一个高，就往哪边查。
• 尝试调整GT接收端的均衡参数（RX Equalizer，包括LPM和DFE设置）。Xilinx Vivado的IBERT里可以直接调这些参数并实时观察误码率变化，非常方便。
• 检查FEC有没有使能。100G KR4/CR4的RS-FEC(544,514)可以纠错t=15个符号，如果你的系统对误码率要求极高（比如1E-15量级），FEC几乎是必须的。但要注意：FEC会引入约十几纳秒的时延，同时对随机均匀噪声的纠错能力有限，链路本身如果质量太差，FEC也救不回来。

最初我们板子上跑PRBS31，短时间测试误码率在1E-12左右，看着还行，但长时间跑就开始偶发误码，后来一查发现是QSFP28连接器的电源Pin接触不良，导致模块供电电压不稳定。把连接器重新固定好之后，问题彻底消失。所以说，什么高级的配置都不如先把基础可靠性做好。

6.3 散热与功耗：一个容易被忽视的隐形杀手

100G光模块功耗高，发热量大，尤其是在密闭的机箱里长时间跑老化测试。模块本身有温度保护功能，过温会主动关断激光器，表现就是跑到一半，光口突然没光了，模块温度寄存器一看，90多度。

如果遇到这种问题，先不要怀疑FPGA逻辑，先把散热做好：

• 确保模块的散热片贴合到位，散热器到模块顶面之间导热垫是不是够厚？
• 风道是不是合理，模块位置有没有被其他热源烤到？
• 把模块的Temperature寄存器值打印出来持续监控，超过85℃就要警惕。

我自己在调试中踩过一个坑：测试机箱里的风扇转速是自动温控的，板子在机箱外调试时模块温度才五十多度很正常，一旦塞进机箱、周围还有别的板卡，温度直接飙到九十多度，光模块自动关断，链路断了，当时还以为是软件逻辑有Bug。后来在I2C诊断里加了温度告警打印，一眼就抓到问题了。

6.4 时钟与复位：FPGA逻辑的命门

最后再提一个通用但也最容易被忽略的：GT的复位顺序和用户逻辑的复位释放时机。Xilinx的Transceiver IP会生成一个完整的复位控制器，逻辑核心的原则是：TX复位必须先完成，直到TX Reset Done拉高，才能开始RX复位；收发通路都就绪后，才能释放用户逻辑的复位，开始数据收发。

如果这个顺序不对，会出现一种很诡异的现象：有时上电能跑，有时不能；偶尔链路断了就再也起不来。实际排查中可以在Vivado里观察GT的状态寄存器（如TXRESETDONE、RXRESETDONE），确认每个阶段是否就绪，再对照IP的复位时序图找差异。

调试中为了快速恢复现场，我给板子做了一个“软复位”按钮逻辑：按一下按键，就把所有GT和PCS逻辑复位一遍，重新走初始化流程。这个小功能在频繁调参数的时候非常管用，不用反复重新上电，节省了大量等待时间。

7. 实操体会与后续扩展

最后说点个人在实际项目中的经验总结。100G光口的FPGA测试，看着门槛高，其实拆解开就是一层一层剥洋葱：先解决逻辑，再解决电压，最后才是光信号的验证。很多人一上来就扎进GT配置和PRBS代码里，反而忽视了回环级别设计、时钟、连接器这些基础工程问题，结果绕了大弯。

我现在的调试顺序基本固定为：上电先读光模块诊断信息，再跑IBERT做物理层扫描，确认每条lane的误码底数；误码底数达标后，再加载用户逻辑做端到端PRBS或者业务流量测试；最后才做长时间老化加余量分析。每一步都有真实的数据和记录支撑，出了任何问题都能串起来排查。

另外一个体会是：好的测试工具和测试方法，能省下你一半的调试时间。IBERT、I2C诊断脚本、软复位逻辑、误码计数寄存器和串口打印，这些东西加起来可能只占了整个工程的小部分工作，但它们的价值远高于花大块时间写的业务逻辑。毕竟对测试来说，创造稳定可控的环境，比堆功能重要得多。

如果你后续要继续往这个方向深入，可以从这几个点着手：尝试自己实现完整的100G Ethernet PCS逻辑（64B/66B + RS-FEC），替代Xilinx的硬核IP，这个过程对协议理解的提升非常有帮助；还可以探索PAM4单波长的100G光模块（比如100G DR1/FR1），那是另一个物理层方向，GTM收发器和均衡策略和NRZ完全不同，会是不错的进阶课题。