高速SerDes中CTLE为何不做背景自适应？前向自适应才是关键

1. 这个问题是怎么冒出来的我最早接触到这个疑问是在一套高速SerDes培训课程的答疑环节。当时有学员指着接收端均衡的框图问CTLE的增益系数如果随信道变化为什么不去做背景自适应导师只回答了一句“112G/224G系统里CTLE不需要背景自适应”但没来得及展开。后来我在实际调试56G/112G PAM4链路时才慢慢把这个问题真正想明白。先说结论不是CTLE不需要自适应而是CTLE的自适应应该在链路训练阶段用前向自适应foreground adaptation完成它不适合也不需要在运行期间做背景自适应background adaptation。这个结论背后涉及均衡器架构、训练协议、功率预算和误码性能等多重因素和NRZ时代的思路有很大区别。要理解这个问题得先分清两个概念前向自适应是在正式传输数据之前利用训练序列或握手阶段把系数定下来背景自适应是在正常传输业务数据的同时持续监测信号质量实时微调系数。NRZ系统里尤其是背板链路背景自适应经常用因为信道可能会受温度、电压漂移影响而且NRZ对均衡精度的冗余度相对大一些。但到了112G/224G PAM4时代情况完全不同。这篇文章我从均衡器架构角度切入结合IEEE 802.3ck/802.3df规范的训练流程、实测中的问题和量产测试思路把这个“为什么”拆开讲清楚。2. 先聊清楚CTLE到底在干什么2.1 CTLE的本质是一个模拟高通滤波器CTLEContinuous Time Linear Equalizer连续时间线性均衡器本质是一个模拟线性滤波器它通过给高频分量增加增益、压低低频分量来补偿信道对高频信号的损耗。信道就像一个低通滤波器把方波的边沿磨圆了CTLE就负责把边沿“重新立起来”。常见的CTLE实现是零点-极点对结构。比如一个零点在5GHz、极点在12GHz的滤波器它的低频增益可能是-6dB而高频增益接近0dB这样就相当于给高频信号抬升了6dB。实际芯片里的CTLE会用多级这样的结构级联起来达到目标曲线。CTLE的调节参数一般是低频增益LF gain控制低频段的衰减量高频增益HF gain控制高频段的抬升量零点/极点位置决定过渡带的形状和斜率。大多数芯片把这些参数做成分档位的寄存器配置比如4位控制LF、4位控制HF再加上零点位置选择组合出几十组曲线。2.2 为什么PAM4比NRZ更需要CTLEPAM4把两个比特打包成一个符号传输符号率降了一半但代价是信号电平从2个变成4个。电平间距只有NRZ的三分之一同样的噪声和ISI码间干扰下信噪比余量急剧缩小。CTLE的作用就是把高频损耗补回来让眼图重新打开。因为PAM4的线性度要求高CTLE的曲线如果偏了幅度失真和非线性失真会直接影响三个眼的均匀性严重时会出现某个眼完全闭上。在112G/lane的系统中信道损耗通常是30dB以上有的甚至超过40dB。这么高的损耗下单靠CTLE是不够的后面还得有判决反馈均衡器DFE来消除长拖尾再配合前馈均衡器或发射端均衡。但CTLE是第一级处理的是最严重的信道衰减它的设置是否合理直接影响后面所有均衡级的工作。2.3 CTLE的“自适应”到底自适应什么CTLE的自适应本质上是搜索一组滤波器参数使得某个目标函数最优。目标函数在各厂商实现中不太一样常见的有最大化眼高/眼宽最小化高频段与低频段的能量差最小化误码率使信号经过CTLE后的频谱接近某个目标频谱。这些目标都可以离线做也可以在线做。离线做就是训练期间用已知的PRBS序列反复试参数在线做就是边收业务数据边统计。后面这种方式就是我们说的背景自适应。3. 为什么112G/224G系统不搞背景自适应3.1 训练阶段已经把系数定下来了IEEE 802.3ck和802.3df规范里PMD物理介质相关子层的链路建立包含训练帧交互过程。链路两端的PHY会交换训练帧接收端把自己当前的均衡器设置反馈给对端对端调整发射端均衡器这个过程是协调式的。CTLE系数在训练开始后就会快速收敛到一个合理值训练完成后进入数据模式CTLE通常保持固定。关键是训练阶段里发送端发出的是已知码型的训练序列接收端可以拿已知序列做误差计算这是最干净的信道估计方式。既然训练期间就能获取足够信息把CTLE调好何必等到数据模式下用带噪的统计结果去“猜”数据模式下的统计估计不仅噪音大而且收敛速度慢还可能被业务数据的内容干扰。有人会问万一信道在工作当中变了怎么办比如温度漂移导致PCB损耗变化或者电源噪声改变了芯片内部偏置点。这个问题在真实系统里确实存在但解决方式不是让CTLE做背景自适应而是靠DFE或者发射端均衡的微调或者干脆等下次链路重训练。因为链路层本身有误码监测机制当误码率超过阈值时会触发链路重启重新训练。所以CTLE固定的时间窗口恰好覆盖了正常工作的稳定期。3.2 背景自适应用于CTLE的“硬伤”先看一个实际例子假设112G PAM4信号符号率56GBaud一个UI约17.8ps。ISI拖尾可能持续5到10个UI加上PAM4的4电平判决信噪比余量非常薄。CTLE如果要做背景自适应就要持续从数据信号中提取误差信息。但这个时候信号已经穿过DFE了DFE在CTLE后面会把CTLE残留的线性失真视为新的ISI并尝试消除。于是CTLE和DFE之间形成了一个“协作”但又有耦合的关系。背景自适应算法需要同时协调CTLE和DFE两个模块的参数这就把问题从单变量寻优变成了多变量联合寻优复杂度成倍增长。还有一个更致命的问题自适应算法的稳定性和数据传输的可靠性之间存在矛盾。自适应算法需要尝试“坏”的参数才能判断它坏但试的过程就会产生瞬间的误码。在NRZ时代偶尔一个误码可能还能被前向纠错码纠正但在112G PAM4系统里前向纠错码的纠错余量本身就吃得很紧任何额外误码都是不能接受的。此外PAM4信号的频谱信息远不如NRZ“纯净”。NRZ有明确的基频和丰富的谐波可以用来做频谱估计PAM4的功率谱密度更平坦而且不同电平组合的跳变幅度不一样这会让频谱类算法的判据变模糊。CTLE的零点极点位置需要根据信道特性估计而PAM4信号的频谱特征不足以支撑精确的在线信道估计。3.3 功耗和面积代价不划算做一个可靠的CTLE背景自适应需要片内的数字信号处理器或状态机持续采样模拟前端输出做FFT、相关计算或最小均方误差更新。这些计算单元在先进工艺节点上本身不算贵但它们要持续工作功耗就不是一个小数目。112G/lane的PHY本来就功耗敏感多一个持续运行的背景自适应模块可能增加几十毫瓦的功耗。在交换机芯片里一个芯片上有几十甚至上百个通道乘以这个功耗就是致命的。面积方面自适应算法需要存储历史数据、维护统计量寄存器和SRAM开销都不少。把这些资源用在CTLE上不如用在更“值”的地方比如DFE抽头自适应或者发射端均衡器调整。所以工程权衡的结果就是CTLE做一个静态的、可配置的模块训练时收敛一次运行中保持不动。省下来的功耗和面积用于更关键的模块这是架构上非常明显的取舍。4. 那训练时侯的自适应是怎么做的4.1 训练阶段的CTLE收敛过程这里以IEEE 802.3ck的Training模式为例具体实现细节各家略有差异。链路建立时发送端发送Training Frame帧里包含PRBS等已知序列接收端先给CTLE设一个初始系数一般是中档位置接收端用已知序列计算接收信号的误差评估当前眼图质量接收端在Training Frame的反向通道里发送“系数调整请求”发送端根据请求调整自己的发射端均衡器接收端也继续调整自己的CTLE迭代若干轮后双方收敛到一组稳定的系数组合然后切换为数据模式。在这个过程中CTLE的调整不是一次到位而是采用“先粗调、后细调”的策略。粗调是指把零点/极点的频段选对细调是微调高低频增益。很多芯片的CTLE状态机里还有一个“锁定判断”条件比如连续多次帧的错误量低于某个阈值就认为收敛完成冻结系数。4.2 前向自适应算法的典型判据不同厂商实现不太一样但常见的有模拟面积最大化、高频能量均衡、误码率探测等方式。比如有的设计会统计经过CTLE后信号在采样点的幅度直方图以此为判据调整高频增益。有的设计比较前馈均衡器或DFE系数的收敛结果反推CTLE是否留了过多残余ISI。这里要注意前向自适应可以用比较“贵”的算法因为只运行一次收敛时间长短没有那么敏感。比如可以试探不同零点位置观察DFE后续抽头系数的变化如果DFE第一抽头系数过大就说明CTLE的低频补偿不够需要增加高频增益这是一个简化的闭合控制环路。而在背景自适应场景下这种试探式搜索是不敢用的因为试探的代价是实时误码。我把一个实用的训练过程用表格整理一下阶段主要动作目标时间量级初始接入CTLE设默认系数发送端设默认均衡参数建立基本通信微秒级粗调根据频谱估计调整零点/极点频段打开眼图基本轮廓毫秒级细调微调高低频增益结合DFE系数反馈最大化眼高、降低残余ISI几毫秒到几十毫秒锁定冻结CTLE与发射端均衡参数进入稳定数据模式锁定后不再动这个流程在每根lane重训练时都会重新执行。所以看似“不做自适应”其实是在一个很短的时间窗内做了一次高强度的前向自适应之后保持固定。4.3 靠什么覆盖训练后的慢变漂移实际系统里模块温度从常温升到工作温度信道损耗确实会变化。那CTLE固定之后靠什么扛靠的是链路中其他环节的余量和机制前向纠错码提供了一部分误码容忍接收机里的DFE抽头会自动跟着信道变化做调整——这就是真正做背景自适应的模块在部分设计中如果漂移导致误码率逼近前向纠错码极限系统会触发误码率自适应调节机制先把发射端均衡器或发射摆幅微调一下再不行就链路重训重新执行一遍第4.1节里的流程。换句话说系统不是“不处理漂移”而是把应对漂移的职责分配给了更合适的模块。CTLE在整个链路里的定位更像是“粗均衡主力”它的覆盖范围有限但性价比极高。让一个模拟滤波器承担精密的自适应任务既不符合模拟电路的精度限制也会把数字控制器的复杂度推高到不合算的级别。5. 对比一下什么时候背景自适应反而有必要5.1 消费级短距接口的另一个思路要把问题看透还得对比IEEE 802.3bj/ck这种长距背板场景和消费级短距接口比如PCIe、USB等之间的差异。消费级接口往往工作速率相对较低或者链路长度短、信道相对固定但它们的首要诉求是“低成本、少调试、即插即用”。这种场景下做背景自适应是合理的因为芯片量巨大不可能每一根链路都做system-level calibration。靠一套自适应算法自动收敛在制程偏差和主板走线差异下鲁棒性更高。这些系统的自适应算法通常也是“训练模式低速后台微调”结合而且它们多半不做DFE或者DFE抽头数很少CTLE承担的责任非常重因此持续微调CTLE来应对信号质量变化是不得不为的方案。这种设计在代价上能接受因为速率低意味着算法处理带宽小功耗也低。5.2 为什么同样的办法不能直接搬回112G/224G112G/224G SerDes的核心场景是数据中心交换机和高速背板链路数量多、速率高、功耗预算紧。把消费级接口那种“每次上电自适应、运行中持续微调”的思路搬过来会遇到几个直接冲突功耗成倍增加、自适应算法收敛速度和数字逻辑处理延迟跟不上56GBaud/112GBaud的符号速率、在线统计需要的样本数量太大导致收敛时间过长。而且这类系统里不止CTLE一个均衡级DFE才是真正处理残余ISI的主力。如果CTLE做了背景自适应DFE那边就得重新收敛两套自适应互相打架轻则收敛速度变慢重则系统振荡。现实中我看到过的教训就是某些早期设计里尝试在运行期间同时调CTLE和DFE最后不得已把CTLE自适应完全关掉只留DFE自适应系统才稳定下来。6. 从实测角度看为什么固定CTLE更可靠6.1 一个真实的112G PAM4链路调试案例我调试过一块测试板PCB走线加连接器总的插入损耗在38dB左右工作速率112Gbps。刚上电跑训练时CTLE粗调选了一个高频增益较大的档位DFE系数收敛后第一抽头系数大约在-0.15左右眼高正常。但运行一段时间后温度从25度升到85度损耗增加约2到3dB误码率开始抬升前向纠错码纠正前的误码率从1e-8升到1e-6左右。这时我把CTLE高频增益往上调一档DFE重新收敛误码率又回到1e-8。从过程看好像确实是需要调的。但如果让CTLE自己做背景自适应可能出现的问题就是温度漂移是慢变的算法可能花了几十毫秒才完成一次搜索这期间不断微调CTLE每次微调都会让DFE跟着动两套环路的交互导致眼图出现周期性抖动误码率反而是先升后降。最终这个板子的量产方案是CTLE固定在工作点附近的一个“温度系数补偿表”上温度传感器读数变化时直接切换预校准的CTLE档位不需要背景自适应而是根据温度做前馈式切换。这个做法简单可靠也不会引起DFE联动振荡。6.2 测试仪器视角下的“静态CTLE”从测试角度看固定CTLE有非常大的好处眼图和误码率都可以在确定条件下复现。示波器抓眼图接收机设置固定后眼图叠加结果的一致性就很好。如果CTLE持续变化眼图的垂直张开度会不断波动测试就会很痛苦。量产测试需要的是稳定可复现的判定条件固定CTLE配合预先标定的系数表是最容易管理的方案。曾经有人尝试在量产测试中让CTLE自适应跑一遍再测发现同一个芯片在不同板卡上的收敛结果差异很大原因是训练序列长度有限、噪声相位随机收敛终点的参数不完全一样。跑一百次测试最终CTLE档位可能落在相邻两三个档位里。这对良率判定非常不友好。把CTLE固定下来只测几个固定配置下的链路指标反而更可靠。7. 那224G系统会不一样吗224G/lane系统通常采用PAM4符号率为112GBaud信道损耗可能超过45dB。表面上看信道更差是不是更需要CTLE自适应实际上224G系统的均衡架构进一步强化了“分层”思想CTLE仍然作为第一级固定粗均衡后续的DFE或基于ADC的DSP接收机承担更细腻的自适应。在基于ADC的DSP架构中CTLE的职责更“轻”了因为ADC后面的数字均衡器可以做非常多的事——前馈均衡器、判决反馈均衡器、最大似然序列检测全可以在数字域实现。模拟CTLE只需要把信号幅度压到ADC的满量程范围内别让高频段过度衰减导致ADC有效位不足。这种架构下CTLE连前向自适应都可以做得非常简单直接按信道插损预算查表。基于ADC的架构有个额外的优势数字均衡器可以持续做背景自适应而不会互相打架因为算法可以同时解所有均衡级的联合优化复杂度全部在数字域里。那么CTLE固定不动的理由反而更充分——它只是一个“模拟前端保护”的角色。8. 常见问题速查问题回答CTLE完全不做自适应吗不是。训练阶段会做一次前向自适应收敛后固定温度变化导致信道漂移怎么办优先靠DFE或数字均衡器后台微调特定方案可使用温度查表切换CTLE档位那消费级接口为什么可以做背景自适应速率低、功耗宽裕、无DFE或DFE简单算法代价可承受224G系统会重新引入背景自适应吗通常不会反而CTLE进一步简化自适应移到数字域做背景自适应会有什么实际风险与DFE环路耦合振荡、引入瞬间误码、功耗面积代价高有没有厂商真的做了CTLE背景自适应部分厂商在特定低速接口上有实现但在112G/lane以上的主流设计中非常少见9. 一些个人的实操体会我在实际调试中最大的体会是很多问题是自己“想复杂”了。新人总喜欢把每个模块都做成自适应觉得自适应高级可靠。但实际上自适应引入的交互不确定性往往比它解决的信道漂移问题还大。CTLE的静态化不是技术倒退而是系统级的取舍——把简单的模块做简单把复杂的模块做可靠。如果你在评估一款高速SerDes不妨看一下它的训练时间、训练帧交换机制和DFE更新方式。真正值得关注的不是“CTLE是否自适应”而是系统的均衡层级之间有没有清晰的职责边界。边界清晰链路就稳边界模糊再高级的自适应也会变成虚假繁荣。另外给正在调试112G链路的朋友一个建议先固定CTLE用DFE去扫残余ISI观察DFE抽头系数的分布就能准确判断CTLE应当往哪个方向调整。这比单纯看眼图更高效因为DFE抽头系数直接告诉你“CTLE漏掉了什么”。这个方法我做时序调试时用了很多次屡试不爽。