上周（9/13-15）到深圳的CIOE（China International Optoelectronic Exposition）大会参观了一下，发现有多家公司演示了其PCIe over Fibre技术。如果你对于如下几个主题感兴趣的话，那么一定要读一下本文的分析:

1. 为什么需要PCIe over Fibre技术？它解决了数据中心的哪些需要？

2. 目前PCIe over Fibre的具体实现方式有哪几种？国际上哪些大厂以及startup公司已经成功演示了PCIe Gen5/6/7 over fibre方案？我现场看到PCIe over Fibre的两种实现方式：1）CDFP AOC光缆；该实现方式为混合缆，内部除了光纤外，还有单独的多根铜缆用来传输PERST#, CLKREQ#等多个低速信号；2）基于retimer卡的光互连，即，在server的插槽里面插入一张特殊定制开发的PCIe Gen5/6 retimer 卡，CPU的PCIe信号到达该retimer卡经过retimer芯片进行信号整形后，然后经过光引擎将电信号转换为光信号，通过retimer卡外联端面的两个x8端口（一般是QSFP-DD）通过QSFP-DD AOC光缆（或者QSFP-DD光模块+MPO optical cable）传输到对端，每个x8光缆里面除了高速PCIe信号外，还需要将PERST#复位信号也调制到光信号进行传输。对面接收端使用同样的retimer卡将光信号转变为电信号后经过retimer芯片然后送到device (end point)端，例如一张GPU卡。

结合上述我现场看到的演示，我也产生了另外几个问题：

1. CDFP接口不是被OSFP和QSFP-DD接口取代了吗？为什么目前数据中心仍然有该接口在使用？为什么PCIe over Fibre实现的时候有的公司仍然还会使用CDFP接口？这个是一个临时过渡手段吗？只是为了存量市场开发的吗？

2. 上述两种PCIe over Fibre实现中，方式1使用的混合缆中的铜缆如何解决传输50米或者更长距离衰减的问题；

3. 上述两种PCIe over Fibre实现中，方式2使用的纯光缆实现是如何解决将低速信号，例如PERST#调制到光信号进行传输的呢？

最后，我们可以看一下PCIe发展和光通讯发展的对应关系，目前我看到是如下的匹配关系：

• PCIe Gen6 = 64Gbps； 基本匹配Ethernet 56G per lane;  x16 data rate （1Tbps)

• PCIe Gen7 = 128Gbps；基本匹配Ethernet 112G per lane;  x16 data rate （2Tbps)

• PCIe Gen8 = 256Gbps；基本匹配Ethernet 224G per lane;  x16 data rate （4Tbps)

也就是说，PCIe Gen7 x16 的速率（2Tbps)大概 匹配 Ethernet 224G *8 (1.6Tbps)光模块的速度；换言之，一张网卡如果ethernet采用OSFP 800G端口，那么PCIe接口必须要用PCIe 6.0 x16，例如Nivida CX-8 superNIC网卡；未来，例如明年如果ethernet采用OSFP （或者OSFP-XT) 1.6T端口，那么PCIe接口必须要用PCIe 7.0 x16。

最后，用于连接两张PCIe接口卡之间的PCIe over fibre实现的AOC光缆和用于连接两张800G/1.6T网卡之间的AOC光缆之间到底存在哪些不同呢？

PCIe Over Fibre 技术综述

为什么需要 PCIe Over Fibre？

随着数据中心内计算和加速资源的解耦和大规模部署，PCIe 总线的互连距离需求大幅增加。在传统服务器内部，PCIe 通常只能在主板上短距离传输，但在AI/HPC集群中希望跨机架连接 GPU、SSD 等设备，实现资源池化和组合架构。铜缆PCIe连接受限于距离（通常最长仅约3米），即使使用中继retimer也只能扩展到7米左右，两级retimer是规范上限。这远不能满足跨机架、大型集群的需求。采用光纤传输PCIe（即“PCIe over Fibre”）可以突破电连接的距离限制，支持数十米乃至上百米的链路，同时保持PCIe固有的低时延特性。例如，GigaIO公司的GPU集群采用光纤后，可以将多个包含32个GPU的节点跨机架相连，突破铜缆3米的束缚。另一方面，随着PCIe速率提升，长距离电连接变得更加困难和耗能，光连接提供了更好的信号完整性和功耗优势。因此，PCIe光互连被视为未来数据中心内扩展高带宽、低时延互连的关键技术

另外，PCIe物理层的发展已经接近铜质连接的极限，信号完整性挑战严峻，频繁使用retimer增加了系统复杂性和功耗。PCIe链路只能使用最多两个retimer（中继器），限制了拓扑扩展。相比之下，光纤链路无需多个级联的电中继即可覆盖更长距离，这对于在保持低延迟的同时实现资源池化至关重要。综上，PCIe over Fibre 能满足数据中心对远距离、高带宽、低时延互连的需求，用于CPU与加速卡/存储之间的直连扩展、跨机架的高速互联，以及未来基于PCIe/CXL的大规模组合架构。

PCIe Over Fibre 的实现方式与厂商概览

目前业内已经出现多种PCIe over Fibre的实现方案，主要分为有源光缆直连方案和基于Retimer转接卡的方案：

• 有源光缆直连（AOC）方案：通过专用的外部电缆，将PCIe总线的高速差分信号转换为光信号传输。这类方案通常使用特定封装的光收发接口（例如 CDFP 或自定义AOC）将整组PCIe通道通过一根光缆连接两端设备。在CIOE 2025上，有公司展示了采用 CDFP 有源光缆 的PCIe 5.0 x16连接方案：光缆内部包含光纤传输高速信号，并辅以多根铜线传输PERST#、CLKREQ#等低速控制信号。该方案实现了单根光缆承载PCIe x16链路。（下面的红色光缆为现场拍摄的CDFP AOC cable)

  

  
  

• Retimer光转接卡方案：在主机和设备端各插入一块定制的PCIe retimer光纤转接卡。主机PCIe插槽的信号先进入Retimer芯片进行重定时/均衡，然后通过板载光引擎转换为光信号，经由标准光接口（如双QSFP-DD端口，各承载x8通道）通过光缆传输。在对端，光信号由相同类型的Retimer卡转换回电信号并输出给PCIe设备（如GPU）。这种方案中，每根QSFP-DD光缆传输8条高速通道，并需通过特定机制在光信号中附带传输PERST#复位信号等控制信息。Microchip在FMS 2024展会上联合Amphenol和GigaIO演示了此类方案：使用两根QSFP56-DD光链路实现PCIe 5.0 x16连接。该Demo表明，通过retimer与光模块配合，可在10米乃至更长距离上稳定传输PCIe Gen5信号。

  

  
  

  
  

  
  

国际上多家大厂和初创公司已经成功演示了PCIe Gen5/6/7通过光纤传输的技术原型：

• Microchip + Amphenol + GigaIO：在2024年展示PCIe 5.0 x16经由QSFP-DD光链路的演示，成功通过两根QSFP-DD AOC实现主机到设备间的Gen5 x16连接。该方案利用Microchip的PCIe交换/retimer芯片、Amphenol的光互连技术，以及GigaIO的FabreX PCIe fabric，扩展了PCIe总线的覆盖范围。GigaIO公司还宣布推出业界首款PCIe Gen5 QSFP-DD光缆产品，可提供x8链路并可捆绑成x16使用，链路长度可达几十米。这些Gen5光缆计划于2024年中投入市场。

• Samtec：作为高速互连厂商，Samtec推出了 FireFly PCIe光缆 解决方案。在OFC 2025上，Samtec现场演示了PCIe 5.0 x4通过100米光纤环路无误码传输；以及5米光纤连接主机和SSD端点的PCIe 5.0链路（可扩展至100米）。Samtec的FireFly微型光引擎支持x4和x12通道，早在PCIe 4.0时代就已提供光飞线方案，如今正开发32GT/s（PCIe 5.0速率）版本。这类方案主要面向嵌入式和短距互连，但也证明了光传输PCIe高速信号的可行性。

• Marvell + TeraHop：Marvell在OFC 2025上与初创公司TeraHop合作展示了业界首个PCIe Gen6光纤延伸方案。演示通过集成Marvell Alaska P Gen6 retimer的TeraHop光学转接卡，将PCIe 6.0信号转换为光，在长达10米的 OSFP-XD有源光缆 上实现主机到设备端的稳定连接。同时他们预展了PCIe Gen7 SerDes以128 GT/s经由TeraHop线性驱动光模块传输的能力，预示支持未来PCIe 7.0的升级路径。Marvell作为高速接口芯片大厂，此举展现了其在PAM4高速SerDes和低误码率光传输方面的领先地位。

• Cadence：EDA/IP厂商Cadence在PCI-SIG DevCon 2024上率先展示了PCIe 7.0（128 GT/s）光连接的原型。该演示采用Cadence自研的PCIe 7.0 控制器/PHY IP，通过非Retimer的线性光链路成功收发128 GT/s PAM4信号，预FEC误码率达到3E-8，优于PCIe 7.0规范要求。这证明了在标准光连接上跑PCIe 7.0的可行性。值得一提的是，PCI-SIG已于2023年8月成立光互连工作组，推动制定光纤PCIe的标准。Cadence的演示作为概念验证，显示了超前的技术储备。

• Synopsys 与 OpenLight：Synopsys亦宣布实现PCIe 7.0速率光链路的演示，其博客称与硅光子公司OpenLight合作，展示了PCIe 7.0 PAM4在光介质上的传输。这类演示主要证明其PHY IP在128 GT/s下的性能，为未来Optical PCIe做好准备。

• Alphawave Semi + InnoLight/Amphenol：高速IP公司Alphawave在2024年PCI-SIG DevCon上展示了PCIe 6.0/7.0子系统在光纤和高速线缆上的互通。其中包括：使用InnoLight的线性光OSFP模块实现64 GT/s PCIe 6.0链路，以及与Amphenol的OSFP-XD直连线缆结合，实现PCIe 6.0延伸。此外还有128 Gbps PCIe 7.0 SerDes的测试。这些展示表明IP供应商也在验证光通信介质对下一代PCIe的支持。

综上，国际大厂（如Microchip、Marvell、Cadence）和创业公司（如GigaIO、TeraHop）都在积极探索PCIe通过光介质传输的技术，涵盖了当前的Gen5、Gen6以及未来的Gen7代际。这些方案有的已经接近商用（如GigaIO的Gen5光缆、Samtec的FireFly），有的还在实验验证阶段，但都预示着PCIe总线的光互连将成为未来数据中心的重要组成部分。

CDFP接口的历史与现状

CDFP（Cube, Dual ~ port, Fifteen millimeter pitch）接口最初是为400Gb Ethernet开发的一种大尺寸光模块封装。大约在2014-2015年，CDFP MSA制定了该规格，采用 16个收发通道，每通道25 Gbps 的NRZ速率（总带宽400 Gbps）。当时CDFP是首批400G光模块形态之一，可用于16x25G并行光（如400G-SR16）和DAC线缆等，并支持多模100m、单模2km等目标。然而，CDFP模块体积较大、功耗也较高，面板密度有限，随后更紧凑的400G封装（QSFP-DD、OSFP 等）迅速兴起。业界发现使用8通道50G PAM4（如QSFP-DD）或8通道50G/100G（OSFP）即可实现400G/800G，且兼具更小尺寸和功耗优势。因此在以太网领域，CDFP和另一早期方案CFP8一样，逐渐被QSFP-DD和OSFP所取代，未大规模部署。

尽管如此，CDFP并没有完全销声匿迹。在PCIe总线外部互连的特殊场景下，CDFP反而重新获得关注。这是因为CDFP独特的16通道设计非常适合承载PCIe x16链路于单一端口，而QSFP-DD/OSFP仅有8通道，需要两只模块才能传输x16。根据TE Connectivity的资料，CDFP已被PCI-SIG选定为 PCIe Gen5和Gen6的外部电缆接口 之一，并在SNIA的SFF-TA-1032规范中定义。CDFP连接器针对PCIe应用进行了优化，例如特性阻抗采用85Ω以匹配PCIe通道，并保留了必要的PERST#等边带（sideband)信号引脚。CDFP还能支持x8、x4配置以适应不同链路宽度，具有一定的灵活性。目前一些超大规模数据中心和OEM已经在评估或采用CDFP作为PCIe光纤/铜缆延伸方案的接口。因此，虽然在以太网模块市场CDFP早已边缘化，但在PCIe over Fibre领域它扮演着过渡和支撑角色。考虑到现有服务器/存储生态中需要一种成熟的x16高速连接器，CDFP作为标准化的PCIe外部互连接口填补了空白，并非仅针对存量市场，还是有现实需求驱动的选择。展望未来，随着OSFP-XD这类新型模块（可能支持更多通道或专为PCIe设计）出现，CDFP或许会被更优化的方案取代。但就目前Gen5/Gen6而言，CDFP提供了一种可靠的单端口x16光缆互连实现，因而仍然在数据中心一定范围内使用。

混合光缆中铜线长距离传输的问题

在 方案1（CDFP混合光缆） 中，AOC线缆内部除了光纤传输高速数据，还包含若干铜线用于传送 PERST#、CLKREQ# 等低速边带（sideband)信号。这些铜线在长达50米甚至更长的距离上传输低频数字信号，面临信号衰减和完整性挑战。为克服此问题，工程上采用了多种措施：

• 使用低速、高容限信号设计：边带（sideband)信号如PERST#（复位）通常是低频或单稳态信号（如上电时拉低一次）。这类信号对时延和波形锐度要求相对不高。因此可以以近似直流的方式传输，避免高频损耗。极低频信号在铜线上主要面临电阻压降而非高频衰减，只要线缆选用合适的导线规格，50米范围内仍可可靠拉低/拉高电平。通常系统将PERST#设计为开漏/Open-drain形式，由接收端拉高、电缆线缆传递拉低动作，从而在长线上保持稳定的逻辑电平。这种设计允许主机端通过FET将远端设备的复位线拉低，即使线路有一定电阻和分布电容，也能在需要时把电平拉到有效阈值。

• 增大导线线径与屏蔽：为了减小长距离直流电阻和噪声干扰，混合光缆中的铜线通常选用较粗的线径（更低AWG号）和良好屏蔽/双绞。这降低了信号沿途的压降和干扰耦合，使即使50米外仍能检测到清晰的高低电平转换。此外，低速信号可接受较缓慢的上升沿，因此线缆的分布电容并不会造成逻辑错误，只是稍许延迟信号转换时间。

• 必要情况下的有源驱动：有些设计会在长距离铜线两端加简单的缓冲/驱动电路。例如在AOC模块的端口处，加一级晶体管或缓冲器放大边带（sideband)信号，以确保经过50米传输后电压电平仍达标。这些缓冲电路功耗很低，却能补偿掉长线的压降。在高可靠性要求下，也可能采用差分传输低速信号再在末端恢复单端，以提高抗干扰能力。不过对于PERST#这样低频信号，一般不需要高速差分，简单单端传输已足够。

需要指出，通过铜线传输边带（sideband)信号会增加线缆复杂度和成本。但在当前阶段，这是实现完整PCIe链路不可或缺的部分，特别是对于暂未实现完全光传输控制信号的方案来说。混合光缆采用铜线传输PERST#等的做法属于一种折衷：在距离可控（如50米以内）时，设计和验证表明这些低速线路仍然有效可靠。例如PCI-SIG的研究指出，可以通过并行的边带（sideband)线缆传输复位/时钟等信号，只是会让接口设计变得不对称且成本上升。因此50米这个级别通常被视为上限，再远的距离可能就需要改变方案（例如把复位等通过其他方式传输，而非直连铜线）。总的来说，混合AOC中的铜线能够支持数十米距离，靠的是低速信号的宽裕裕量、精心挑选的线材，以及必要的缓冲措施来对抗衰减。

纯光缆方案中低速信号如何光传输

在 方案2（Retimer卡+纯光缆） 中，没有并行铜线来直接传递PERST#等控制信号，那么这些边带（sideband)信号需通过光链路调制或其它机制传送到对端。这通常采用以下方法：

• 利用光模块的侧带通道：许多高速光模块（如QSFP-DD、OSFP）的规范中带有低速控制和监控通道，例如I²C/SMBus（用于DOM监控）以及一些用户定义的GPIO引脚。在定制PCIe光链路中，可以通过这些现有侧带接口转发复位信号。例如，设计一种协议：当主机端Retimer卡探测到PERST#被拉低时，通过I²C命令或模块的控制引脚通知远端模块，由远端Retimer卡上的控制电路拉低设备侧的PERST#。这种方式相当于在光模块/光缆内部建立一条低速通信信道来传递控制指令。PCI-SIG的资料也提到，许多光接口提供I2C或专用侧带信号，可用于辅助传输诸如PERST#的控制事件。

• 光信号存在性调制：另一种巧妙的方法是不直接发送复位电平，而是通过光信号的存在/中断来表达。例如，当需要复位设备时，让主机端的光引擎暂时熄灭光信号（或以特定模式闪断），远端检测到光信号丢失即可认为进入复位状态。等主机恢复光发射，远端释放复位。这类似于利用“光链路存在”作为PRSNT#或PERST#的指示。早期Avago/PLX公司就演示过类似技术，用光链路的亮灭来生成远端的插拔和复位事件。当然这种方法需要谨慎设计时序，确保区分是真正的链路故障还是有意的复位信号。

• 协议级的协调复位：在更高层次，也可以通过协议/软件协调复位。比如采用PCIe热插拔机制或CXL协议，由主机发送控制消息通知远端设备自行进入复位。这实际上绕过了物理PERST#线，而是依赖上层管理。OCP提出的PCIe扩展规范中也倾向不直接使用诸如PERST#的物理边带（sideband)，而通过管理通道处理复位等事件。在Retimer卡方案中，主机和设备端可能各自连接BMC，通过BMC通信协调复位时序。这种方案需要系统层配合，不是纯硬件链路的方法。

实际的纯光实现通常综合运用了上述方法中的一种或多种。例如，一些Retimer光扩展卡会在光模块的MODSEL/LPMode等引脚上加载特定编码，远端卡检测这些引脚电平变化后，通过板上逻辑电路在设备插槽触发PERST#。这种调制低速信号到光链路的方案在2015年前后已被Avago（现博通）和PLX等公司验证。总的来说，解决之道是要么借用光模块的管理/控制信道，要么用光链路本身的状态变化来隐式传递信息。随着标准化推进，未来可能会有统一的方法（例如PCIe标准的光链路管理协议）来处理这些边带（sideband)信号。在当前演示系统中，各厂家多为定制实现，其核心思想都是确保远端能够可靠感知主端的复位/唤醒等事件。相比混合线方案，这种方式使光缆更加简洁对称，但实现复杂度提高，需要精心处理同步和误触发，以保证不影响高速数据链路的稳定性。

PCIe发展与光通信速率的对应关系

PCIe每一代带宽的提升往往对应着同期高速通信链路速率的演进。从目前看，PCIe物理层速率约等于当代以太网单通道光模块速率的两倍，PCIe x16总带宽则大致匹配主流高速光接口的聚合带宽：

• PCIe Gen6 (64 GT/s)：采用PAM4调制，单通道裸速率64 Gbps（实际有效约~128/130编码后60+ Gbps）。这一速率等级与以太网 50G~56G PAM4 每通道速率处于同一时代。当前400G/800G以太网多用50～56 Gbaud PAM4（每通道可承载约100～112 Gbps）的光芯片。PCIe 6.0 x16链路总吞吐约可达1 TB/s（实际约 128 GB/s），恰好能支撑一款800G以太网卡的总流量需求。举例来说，NVIDIA最新的800G NIC（如ConnectX-8）要求主机至少提供PCIe 5.0 x16甚至PCIe 6.0 x16带宽才能不成为瓶颈——PCIe 5.0 x16约每秒64GB，折合512 Gbps，无法充分发挥800 GbE；而PCIe 6.0 x16可达每秒128GB（约1 Tbps），足以匹配800G端口的双向总吞吐。

• PCIe Gen7 (128 GT/s)：采用PAM4，单通道128 Gbps。以太网正迈向单通道100G/112G PAM4的时代，800G光模块多为8×100G，下一代1.6 Tbps模块可能采用8×200G（即200 Gbps PAM4，每通道约 56 Gbaud）。PCIe 7.0 x16理论带宽约2 Tbps（256 GB/s），非常接近1.6T 以太网双端口的总吞吐能力。例如未来推出的1.6 Tbps NIC（可能采用OSFP-XT 1.6T模块）将需要PCIe 7.0 x16来驱动。换言之，PCIe 7.0 x16 ≈ 2Tbps，刚好覆盖1.6T单口网卡（1.6Tbps）的单向流量需求并留有余量。

• PCIe Gen8 (256 GT/s)：虽然PCIe 8.0规范尚未定型，但按照PCI-SIG一贯的倍增路线，Gen8将达到256 GT/s。如果仍采用PAM4，其每通道净吞吐可能约200 Gbps以上。届时业界以太网标准则可能进入224G PAM4每通道（或更高）的时代，对应单模块3.2 Tbps级别。PCIe 8.0 x16总带宽预计可达4 Tbps（500 GB/s量级），可以支撑下一代3.2T甚至6.4T级别网络接口或加速卡的需求。也就是说，每提升一代PCIe，总带宽大约翻倍，基本跟上了高速以太网端口速率翻倍的步伐。这种匹配关系确保了新一代服务器I/O设备（NIC、GPU等）的接口不会因总线带宽不足而“饿死”。例如，当200G Ethernet（每通道200Gbps）光模块成为主流时，只有PCIe 7.0 x16才能充分驱动；而面向未来400G Ethernet每通道的时代，则需要PCIe 8.0 x16来匹配。

总的来说，PCIe物理层演进与光通信（尤其以太网链路）呈现协同发展的态势。每一代PCIe x16的总吞吐接近同时期高速网络接口的聚合速率，从而在服务器中实现平衡：处理器<->设备总线带宽 ≈ 设备<->网络带宽。这保证了诸如800G/1.6T网卡、最新GPU等高速设备在PCIe总线不成为瓶颈。例如，当前800G网络卡通常配备PCIe 5.0/6.0 x16，而展望明后年1.6T网络卡将要求PCIe 7.0 x16才能发挥全部性能。

PCIe光缆 vs. 以太网光缆：有何不同？

用于PCIe over Fibre的有源光缆（AOC）与用于两块800G/1.6T以太网卡互连的光缆在外观和基本原理上可能类似（都是高速光纤通信），但在功能和协议要求上存在显著差异：

• 边带（sideband)信号支持：正如前文所述，PCIe链路除了高速差分信号，还有PERST#、CLKREQ#、REFCLK等边带（sideband)信号需要传递或处理。因此PCIe用的AOC通常需要额外的设计来支持这些低速信号—— entweder是在光缆内铺设铜线（混合缆方案），或者在光模块/转接卡中实现边带（sideband)信号的调制传输。相比之下，标准以太网光模块/光缆几乎没有需要远端传递的复位或低速控制线。以太网链路的控制（如链路协商）都在协议层完成，不依赖额外的线缆引脚。因此，以太网AOC设计上更简单对称，不像PCIe AOC那样需要为每对端维护对等的复位、时钟管理逻辑。在以太网模块中，一般只有模块检测（ModPrsL）和低速I2C管理，用于报告模块存在和监控——这些并不直接参与NIC间的数据协议控制。所以PCIe光缆需要解决边带（sideband)信号传输问题，而以太网光缆则基本不涉及此类额外信号。

• 协议透明度与复杂性：PCIe AOC本质上是在延伸总线，要求对PCIe协议完全透明，不引入新的握手或大的延迟。PCIe链路有复杂的训练和状态迁移过程，包括速率协商、链路宽度协商、错误恢复、L0s/L1低功耗状态、复位等。AOC必须让两端设备认为仍直接相连于同一总线，不能打破这些状态机过程。这往往要求PCIe AOC采用线性直通方式传输信号，避免额外转码/缓存，以保持超低延迟和信号实时性。很多PCIe光模块因此采用线性驱动光学（LPO）形式，没有CDR/Retimer，直接将电信号调制为光。与此对比，以太网AOC则是协议层的点对点连接，链路两端的NIC通过MAC/PHY完成帧发送，光模块内部往往有DSP和FEC处理（例如RS编码纠错）以保证链路误码率。这种设计允许以太网模块存在几十纳秒以上的DSP延迟，因为对网络协议而言这可以接受。而PCIe不能容忍过大的非对称延迟，否则会干扰链路培训和请求—应答的及时性。因此PCIe AOC通常比以太网AOC具备更低的时延需求和更高的信号透明度。简言之，Ethernet光模块多为“黑盒”式转发帧数据，内部可以重定时重打包；而PCIe光模块更像“光纤延长线”，力求不改变信号时序和内容。

• 链路层可靠性机制：以太网有完善的分组重传和FEC机制，允许一定误码率并通过上层协议纠正。而PCIe链路虽然Gen6开始引入了FEC（前向纠错），但仍需极低误码率（1e-6前纠错）和硬件级重试来保证数据可靠。因此PCIe AOC在物理层设计上要保证尽可能接近本地链路的信号质量。例如PCIe 6.0自带轻量FEC延迟很小，AOC不能引入比这多得多的延迟，否则会破坏PCIe LTSSM时序。此外，PCIe AOC要支持链路的电气级流量控制（如暂停符号等）无损通过。Ethernet光缆则无需关心这一点，因为以太网的流控在更高层实现，物理层只管把0/1发送好。所以PCIe AOC往往由专用retimer芯片+线性光模块构成，以维持PCIe链路特性；而Ethernet AOC相当于两端独立MAC/PHY之间的介质，可靠性由MAC层FEC/ARQ保障。

• 互操作性和标准化：目前PCIe光纤互连尚处于发展初期，多数实现是厂商专有或者合作开发，尚未完全标准统一（PCI-SIG正在制定中。不同厂商PCIe AOC之间的互通、兼容性还有待规范。因此在选用PCIe AOC时，往往需要成对使用同型号设备。相比之下，以太网光模块/AOC经过多年标准化，接口参数、协议均严格标准，任意厂商符合标准的800G AOC都能在交换机/NIC间互通。这个区别意味着PCIe AOC生态仍在形成，需要考虑协议复杂性和多样设备类型所导致的兼容挑战。PCIe设备类型丰富（GPU、SSD、网卡等各自实现差异），AOC需适配各种LTSSM行为；以太网设备则较为统一（皆遵循802.3标准帧交换）。因此PCIe AOC在设计上更复杂，也需要和更多生态伙伴配合验证。

• 应用场景差异：PCIe AOC主要用于机内/机架内的点对点扩展（如主机与JBOG/JBOD机箱互连），替代传统PCIe Cable或扩展箱背板。这要求即插即用，透明呈现设备给主机，不引入软协议。而以太网AOC用于网络互联（如服务器到交换机、交换机到交换机），它连的是两个主动通信端点，工作于网络协议栈下层。PCIe AOC更像把两块PCIe 卡“连成一台机器内的直连”，强调的是延伸总线；Ethernet AOC连的是两台设备，各自独立运行协商网络通信。因此在管理上，PCIe AOC可能需要与系统BIOS/操作系统协同（识别出远端设备卡），而以太网AOC对系统来说完全透明，只当作介质，不需要额外的软件支持。

综上，虽然PCIe Over Fibre与高速以太网互连都使用光纤传输高速数据，但PCIe AOC更像一条主动的延长线，需要保留总线语义和控制信号，设计难度和复杂度更高。以太网AOC则是纯粹的数据管道，依赖标准协议调控，侧重高吞吐和容错。除了边带（sideband)信号传输这一明显区别外，两者在时延容限、信号处理、标准化程度方面也有所不同。简单来说，PCIe光缆必须“骗过”主机让其以为设备仍插在本地插槽里，而网卡之间的光缆只需保证比特流无误地送达即可。这些差异使得PCIe over Fibre在近期主要面向专门场景由专业方案实现，但随着标准成熟，我们有望看到PCIe光互连像以太网模块一样实现即插即用的成熟生态。

https://pan.baidu.com/s/18_c11aeFhSBe2qa-jUFs_Q?pwd=mm9y 提取码: mm9y

如果你有其任何关于PCIe5&6.0, CXL, NVMe/NVMoF, NAND, DDR5/LPDDR5以及UFS测试方面的我问题想咨询，请访问：访问www.saniffer.cn / www.saniffer.com 访问我们的相关测试工具和产品；或者添加点击左下角“阅读原文”留言，或者saniffer公众号留言，致电021-50807071 / 13127856862，sales@saniffer.com。