PCIe Gen6 上光纤这个说法放在两年前还像实验室里的概念但现在已经不是新鲜词了。我们这边做长距离PCIe扩展实测时链路从主机端拉到10米外的设备机箱64 GT/s的Gen6速率下铜缆方案怎么留预算都留不够换成光纤之后链路很快就跑起来了。第一反应当然是“通了就好”可实际上后面半个月的活全在测试上。真正难的不是“通”而是怎么测。这篇文章我就把PCIe Gen6上光纤后10米以上链路的测试思路、工具搭配、踩坑过程完整捋一遍给正在或准备碰同样项目的朋友做个参考。1. 先说清楚Gen6的物理层为什么逼着链路上光纤1.1 64 GT/s 的 PAM4性能翻倍的代价是噪声预算如果只看速率数字PCIe Gen6比Gen5翻了一倍从32 GT/s来到64 GT/s。但物理层并没有把信号频率也翻一倍而是从NRZ换成了PAM4调制——以前一个信号周期表达一个bit现在用四个电平表达两个bit。这个设计的好处很明显每通道波特率还是32 GBaud没有继续往上推。坏处同样明显信号电压范围被切成四份每一个电平“眼睛”的垂直开度比NRZ时代小得多。说得直白一点同样的噪声在Gen5的NRZ下可能就是波形有点毛刺到Gen6的PAM4里就可能直接误码。为了把这条链路的误码率压住Gen6引入了前向纠错FEC。行业里普遍把FEC输入端的误码率目标定在1e-4量级经过RS(544,514)这类纠错码处理后输出误码率可以被压到极低。这里先记住一个关键结论Gen6的物理层允许一定程度的错误存在只要FEC能兜住上层感知不到。这也是后面所有测试矛盾的根源——FEC就像一层很厚的缓冲垫它让链路更容易“通”但也把物理层的真实健康状况藏了起来。1.2 铜缆的极限10米不只是“衰减大一点”聊光纤之前先把铜缆为什么出局这件事说透。很多人有个误解以为Gen6上光纤是因为铜缆衰减太大。实际上Gen5和Gen6的符号率都是32 GBaud高频段的插损并没有本质差别。真正的差别是PAM4对信噪比的需求比NRZ苛刻得多同样的插损预算下噪声容忍度低了一截。所以工程上的结果就是Gen6的有源铜缆或者重定时器方案能覆盖的距离通常也就一两米再往上走要么均衡器调无可调要么功耗和延迟高到不可接受。10米这个距离无源铜缆完全出局有源方案也基本到了物理极限。光纤方案在这种场景下几乎是唯一解。玻璃介质的损耗低、带宽高10米距离对光路来说简直就是“跳线级”难度。问题在于光路引入之后工程上原来熟悉的那套“哪里都能拿探头点一下”的测试方法全变了。1.3 换光纤不只是换介质更是换测试参考点传统PCIe链路测试工程师习惯了把链路分成几个参考点发送端芯片引脚附近、连接器后端、接收端引脚附近。铜缆时代这些点都裸露在PCB和连接器上示波器探头随便接哪里有问题一眼就能看出来。上了光模块以后链路变成了“电-光-电”的结构。主机侧的PCIe信号先进电口到模块里转成光信号通过光纤传到远端设备再在远端模块里变回电信号。问题来了光模块内部有CDR、驱动器和DSP输入端的电信号经过模块内部处理之后已经不是你原本想测的那个原始PCIe波形了。而光口和光纤之间又没有一个像RJ45那样方便你“挂个仪器上去围观”的测试点。换句话说参考点被模块“吞掉”了半截你想测也未必找得到合适的位置。所以准备测光PCIe的第一件事不是买仪器是把脑子里那张“电链路测试图”换成“三段式光链路测试图”——电口段、光模块内部段、光纤段每一段用什么工具、怎么切出来都得重新规划。2. 链路划分一条光PCIe通道至少能拆成三段来测2.1 电口段、光口段、中间光纤段参考点怎么找做链路排查时我最常跟团队说的一句话是别把一条光PCIe链路当成一个黑盒它至少有三段你必须知道自己现在测的是哪一段。第一段是主板/设备侧的PCIe电口到光模块的电引脚。这一段理论上还能用差分探头去测但Gen6是32 GBaud的PAM4信号探头本身要支持足够带宽而且光模块通常是插在笼子里的电信号测试点藏在连接器里实际很难下手。更现实的测法是利用PCIe自身的环回功能或者BIST模式直接把误码仪挂在协议层面。第二段是光模块内部。这一段你碰不到物理信号只能靠模块的寄存器、状态位、数字诊断监控DDM去了解它的情况。比如模块是不是锁定了信号、有没有告警、温度是否超限、启动过程中发生了多少次LOS事件。第三段是光纤本身。这一段反而是最好测的光功率计、端面检测仪、光时域反射仪都能派上用场。常见问题是大家下意识觉得中间这段“就是一根线”往往跳过了检查结果问题恰恰出在连接器端面或者跳线内部。三段分开以后排错就可以按段排除电口段出问题查主机端和设备端的链路训练状态光纤段出问题查插损和端面模块内部出问题查DDM和误码率分布方向。2.2 分段工具怎么配光功率计、端面检测仪、误码仪测试工具上我的基础配置是三样光功率计。最好是支持双波长的手持式或者台式设备测试时直接读模块发射功率和接收端功率分辨率到0.1 dBm级别就够用。端面检测仪。这东西便宜但前期我们吃过亏没有它的时候连接器脏没脏全靠猜。一个带放大摄像头的端面检测仪配上对应接口的适配头几秒钟就能看出插芯端面是不是有灰尘或划伤。误码仪。如果条件允许上一台支持PAM4光口和电口的误码仪做收发环路测试非常方便。预算不够的话至少也要会用PCIe控制器自带的BIST和错误计数器功能。还有一个偏门工具是光时域反射仪OTDR但10米这种短链路我不是很推荐。OTDR存在测试盲区短距离下它给出的插损结果往往不够准而且一次打光还要算折射率、绕好几道弯。10米链路更靠谱的做法是用双端插损法打光测两端功率计算差值精度足够还便宜。2.3 手动算一笔光功率预算别全信模块的告警很多人拿到光模块习惯直接看DDM里的收发功率只要没告警就觉得链路没问题。但DDM的告警阈值一般设得相对宽松它告诉你的更多是“有没有物理断开”而不是“链路还有多少余量”。建议在项目一开始就手动算一次光功率预算。举例来说如果模块标称发射功率最小值是-3 dBm接收灵敏度是-9 dBm那么可用链路预算就是6 dB这里说明具体数值以你拿到的模块数据手册为准不同模块差异不小。然后把这6 dB预算拆出去中间光纤12米的插损大约0.3到0.5 dB四个连接器一对一对地对接每个适配头的插损就算0.5 dB总共就要吃掉2 dB加上预留的波长色散和DSP链路代价余量其实非常紧张。实际工程里哪怕一个连接器端面污染导致插损多出1到2 dB整条链路的余量就会掉到临界区。这个预算表应该作为项目文档的一部分存档每次排错都拿出来对照而不是等系统报“信号丢失”了才开始慌。3. 最难的不是“通”FEC把错误吞了怎么把误码钉在段上3.1 为什么应用层非常干净物理层其实已经很糟链路训练能进L0、系统能枚举出设备、跑个压力测试也没报错这套状态很容易让人放松警惕。但真正做过Gen6物理层测试之后我得到的教训是上层越干净越说明FEC在默默干活而默默干活不等于链路很健康。有个实测数据可以说明差异。我们在一条光链路上连续跑了几小时压力测试业务进程没有任何报错看起来一切正常。但把主机的AER寄存器里的可纠正错误计数拉出来一看FEC纠正过的符号数已经相当可观。这些错误对用户无感对工程质量却是实打实的信号——链路余量可能正在临界区徘徊。所以验证一条光PCIe链路是否合格标准动作应该是先看FEC纠正计数再看误码率趋势最后才是跑业务流量。如果业务跑完而FEC计数一颗都没涨那才叫健康。3.2 三种环回法做分段误码电环回、远端环回、光回环定位误码到底出在哪一段我比较推荐用“分段环回误码仪”的组合拳。这里有三种环回路径可以搭电环回在主机端不经过光模块直接把PCIe控制器的发送和接收短接或者利用控制器内部的环回模式。这一步用来验证主机端电口本身是否干净作为整条链路的基准。远端环回设备端把接收到的数据环回给主机端主机持续发送特定pattern并检查返回的数据。这相当于把整条“电口模块光纤远端模块远端电口”的链路都测了一遍能发现链路中的任何明显劣化点。光回环在某一侧模块的光口上用短跳线把TX口接到RX口让光信号不经过远端设备直接折返。这种测法能把光纤和连接器的影响包含进去又排除了远端设备电口的问题。实际测试时我会先跑电环回确认基准无误然后跑光回环最后跑远端环回。哪个环节的误码明显升高就用它反推故障段。需要注意这三种环回测法会产生不同的链路延迟和参考时钟行为跑之前最好把环回方式和期望值都写进测试记录里不然前后对比的数据没有可比性。3.3 DDM数据要配合场景看不能只看RX功率光模块的DDM数据是排错时最容易被误读的信息。看到RX功率偏低就怀疑模块坏了看到RX功率在正常范围就认为光路没问题这两种都是典型误区。正确姿势是把DDM当“场景信息”来读。比如RX功率正常但FEC计数上升问题大概率不在光功率而在反射、连接器端面质量或者模式噪声。RX功率恰好压在告警阈值附近同时伴随偶发链路重训练那就要优先怀疑某个连接器插损偏高或者跳线弯曲半径过小。另外多模和单模模块的敏感度不一样。多模模块对连接器端面污染相对迟钝但这对排错是坏事——脏端面可能要到后期才体现为随机误码。单模模块则往往更早暴露回损问题。所以读DDM之前先确认你手里模块的波长和链路类型再决定对哪些参数敏感。4. 10米链路的排错实录忽通忽断最后问题出在端面4.1 现场现象与第一轮误判说一个我们实际遇到的案例。一台设备放在10米外光纤连接Gen6链路跑起来。刚开始一切正常设备枚举成功数据读写都没问题。但跑了一段时间后开始出现间歇性链路断开有时候是几个小时一次有时候十几分钟就一次。系统日志里能看到链路重新训练的事件业务进程偶发报错。第一轮排查我们犯了两个典型错误。首先怀疑是模块过热因为光模块笼子里散热条件一般功率大、频率高温度漂移会改变激光器工作点。于是加了风扇、改了气流走向结果问题依旧。其次怀疑光纤被电磁干扰虽然光纤本身抗干扰但连接器附近如果捆在一起也可能有影响。把光纤重新走了线距离拉开也没有效果。那段时间链路时好时坏恰好说明问题不是“硬断”而是某种缓慢劣化。4.2 逐步定位功率、插损、端面、模块替换被现象迷惑了两天后我们强制自己按三段检查法重新来一遍。先看光功率。用光功率计分别测了主机端模块的发射功率和设备端模块的接收功率都落在正常范围没有触发告警。只看这步链路是“健康”的。接下来检查中间光纤段。断开所有连接器用双端插损法测量结果发现有一对MPO连接器的插损明显偏大比同链路其他连接器高了差不多1 dB。1 dB听起来不多但对本来就紧张的链路余量来说可能就是压垮骆驼的最后一根草。我们用端面检测仪检查这对连接器果然发现其中一个插芯端面有污染看起来像一小片油渍边缘还有几点灰尘。清洁后复测插损恢复正常链路断开事件彻底消失。事后复盘我们对模块发热和电磁干扰的第一轮怀疑全是误导真正的根因就是连接器端面污染导致的插损劣化温度一波动、链路余量一紧张问题就间歇性暴露。4.3 清完端面后FEC计数才是“稳定”的判决依据这里要补一个关键细节链路断开会重新训练训练成功后业务恢复很容易让人误以为问题消失了。但我们要的不是“恢复”而是“没有劣化”。清洁端面并重新插好连接器后我特意没有立刻恢复业务而是先在主机端读了一遍FEC纠正计数确认归零或者稳定在很低的水平然后才开始跑压力测试。跑完再拉一次计数如果错误数没有持续上涨链路才算真正稳定。从这之后我给自己定了一条规矩凡是光PCIe链路稳定性的判决依据以FEC纠正计数趋势为准不以上层业务跑没跑报错为准。5. 测多了之后我给自己定的几条光PCIe测试规矩5.1 示波器排最后功率计和端面仪排第一以前做高速电接口拿到链路第一反应是上示波器看波形、看眼图。但光PCIe链路恰恰相反示波器应该排在工具箱最后面。原因前面说过光模块内部的DSP已经把信号重新整形过了你在光纤上测到的光眼图和模块内部的电处理结果不完全是一回事而链路是否健康最直接的数据来自FEC计数、光功率和插损。我在项目里的第一动作永远是光功率计打一遍、端面检测仪扫一遍所有连接器、DDM读一遍模块工作状态。这组数据读完之后心里基本有数了然后再决定要不要上误码仪、要不要上采样示波器。5.2 测试设备本身也会成为链路的瓶颈这条经验说来有点反直觉。一次我们调了一条稳定链路把误码仪接上去之后怎么测怎么误码一开始以为是链路有问题折腾了一天最后发现是误码仪的光口模块本身灵敏度不够它的接收机在-10 dBm附近就开始丢数据。从那以后我习惯在正式测试前先用一条已知好的短光纤对测试设备自己做一次环回自检确认仪器本身的工作状态没问题再把它接到被测链路上。这跟用万用表之前先短路一下表笔校零是一个道理。5.3 给每段光路命名、登记插损是复用铜缆工程的习惯光链路测试还有一个容易忽略的细节标识和记录。铜缆时代每条线缆两端都有标签走线架上有标识哪条线是哪台设备的都清清楚楚。到了光纤这里很多团队反而随意了接线靠颜色跳线靠记忆排查问题全靠重新拔插试错。我现在的做法是每条光链路建立一张登记表内容包括主机端模块和端口号、设备端模块和端口号、光纤跳线编号、每段连接器的插损记录、清洁记录。每次改动链路后更新一次数据。这个习惯排错的时候节省的时间不是一点半点尤其当机柜里密密麻麻全是走线的时候一张准确的登记表比任何仪器都管用。说到底PCIe Gen6上光纤这件事技术上不神秘但它把很多工程师的测试习惯从“示波器上看波形”拉回到了“先确认物理层光路健康”这个基本功上。光纤通路里的灰尘不会主动告诉你它在哪里但系统和日志会用各种奇怪的现象暗示你。把链路拆开、分段测试、看FEC、记插损这套流程走顺了10米光纤PCIe就是一条普普通通的链路不难伺候。