新闻详情

新闻详情

首页 / 资讯中心 / 详情

112G/224G SerDes中CTLE为何放弃背景自适应?模拟与数字均衡分工演进

发布时间:2026/9/25 14:59:46来源:尧图网络
112G/224G SerDes中CTLE为何放弃背景自适应?模拟与数字均衡分工演进
这几年的高速互联圈里有个很有意思的变化很多刚接触112G/224G SerDes设计的工程师拿到芯片手册时会发现接收端CTLEContinuous Time Linear Equalizer连续时间线性均衡器这一栏的参数几乎都是寄存器直接配置的根本没有背景自适应Background Adaptation的控制位。问前辈前辈往往丢过来一句“现在速率太高做不了自适应”然后就没有然后了。我当年也是带着这个疑惑去啃了大量白皮书、测试报告和IP手册又在实验室里反复测过好几轮板卡才逐渐把这件事的前因后果理顺。今天这篇就把这个问题彻底讲透112G/224G系统里CTLE为什么不再需要背景自适应这背后涉及的是模拟均衡和数字均衡的分工变化、超高速率下的物理约束、以及链路训练机制带来的架构调整。不管你是做信号完整性仿真的、做芯片验证的还是调硬件板卡的把这条逻辑线捋清楚对做高速链路设计都会有直接的帮助。1. 先说结论CTLE在112G/224G里不再当“主力均衡器”了1.1 传统接收机的均衡架构CTLE是绝对主力要看懂现在的变化得先回到十多年前的经典接收机架构。那时候的SerDes接收端一般由线性均衡器CTLE、判决反馈均衡器DFE、时钟恢复电路CDR组成。CTLE是模拟域的滤波器负责补偿信道的高频插损DFE在判决之后反馈消除残余的码间干扰ISICDR负责恢复时钟。在那个架构里CTLE起到了承上启下的作用输入信号经历背板或PCB走线之后高频分量衰减严重眼图几乎闭合必须靠CTLE先把高频分量抬起来让后级的DFE和CDR能正常“看到”信号。如果CTLE的增益和零点频率设得不对后级再怎么努力都是白搭。所以早期系统对CTLE的依赖性非常高也催生了CTLE自适应的需求板卡插入不同长度的背板走线不同材质、不同过孔数量的信道插损曲线千差万别接收机没法预先知道信道长什么样只能靠一个自适应算法来寻找合适的CTLE参数。那时候的“背景自适应”怎么做呢大致思路是接收端在正常接收数据的同时用额外的采样器或判决误差信息估计当前眼图张开的程度、误码率或者均方误差再通过梯度下降之类的算法缓慢调整CTLE的高频增益和零点位置让目标函数收敛到最优。这个过程是持续进行的贯穿整个正常工作状态所以才叫“背景自适应”Background Adaptation意思是它一直在后台跑不占用正常数据通道。1.2 ADCDSP架构下CTLE变成了“前置放大器”到了112G/224G时代主流的SerDes接收机架构几乎都换成了ADC DSP。简单说接收端把模拟信号经过CTLE预处理、AGC自动增益控制之后直接用高速ADC采样成数字信号后续的所有均衡、判决、时钟恢复都在数字域用DSP算法完成。在这种架构下CTLE的角色发生了质变它不再负责把眼图“打开”到最终状态而是变成一个相对简单的前置信号调理模块。它的主要任务有两件事。第一提供一个可控的低频增益和高频补偿使信号的幅度范围落在ADC的输入动态范围之内别让ADC饱和也别让小信号淹没在量化噪声里。第二对信道做一个粗略的高频预补偿减轻ADC后面数字均衡器的压力但不能过度整形否则会把ADC的动态范围浪费在无谓的频段上。也就是说CTLE从“主力”变成了“辅助”。后续真正负责精细均衡的是DSP里的前馈均衡器FFE、判决反馈均衡器DFE甚至最大似然序列检测MLSD。这意味着CTLE即使固定在一个合理的配置上也不用担心均衡效果不好因为后面还有一大串数字信号处理手段来兜底。1.3 自适应没有消失它搬到了数字域很多人听到“CTLE无需背景自适应”第一反应是系统没有均衡能力了其实恰恰相反。均衡自适应的核心工作已经从模拟的CTLE挪到了数字域里FEE/DFE的系数自适应上。数字域做自适应的优势非常明显算法可以用硬件的数字逻辑实现精度高、收敛快、重复性好而且不会像模拟电路那样受工艺、电压、温度影响出现参数漂移。更重要的是数字域对误差信号的提取非常自然因为数据经过ADC之后本来就是一个个量化的数字样点直接就可以计算出眼高、眼宽、信噪比等信息用来驱动自适应系数更新。相比之下模拟域的自适应需要额外的高频模拟采样器、误差比较器又费功耗又难设计在400G/800G这种集群规模下完全不划算。所以你会看到112G/224G SerDes的接收端往往有一个非常强大的DSP均衡引擎能够在前几微秒内完成信道估计和均衡器收敛。而CTLE的配置只要在链路训练时定下来后面正常传数据的阶段完全可以固定不动。2. 为什么模拟CTLE的背景自适应在超高速率下“玩不转”了2.1 UI时间太短自适应环路的扰动根本没法容忍这是最直观的一个原因。112Gbps PAM4链路的符号率是56GBaud一个UI单位间隔大约是17.9ps224Gbps PAM4的符号率到112GBaud一个UI只剩大约8.9ps。要知道决定链路能不能跑通的核心指标之一就是接收端的抖动预算里那几十ps的眼宽裕量。传统背景自适应需要持续调整CTLE的反馈网络比如通过开关电容阵列、可调电阻或者电流源扫描来实现调节。这些模拟开关在切换瞬间会产生毛刺、电荷注入和参考电压扰动直接反映到输出波形上就是相位抖动和幅度抖动。在10G/25G时代一个UI有40到100ps切换毛刺只要控制在几ps以内睁一只眼闭一只眼也就过去了。但在112G/224G下一个UI连9ps都不到模拟开关切换引起的毛刺可能直接吞掉大半的眼宽裕量这是系统没法接受的。所以从设计上就干脆放弃持续的自适应CTLE设置好之后整个数据链路工作期间不再切换任何模拟调节开关让信号路径保持完全静态尽最大努力降低扰动源。2.2 模拟自适应环路的稳定性与功耗成本另一个根子是模拟反馈环路的稳定性和带宽矛盾。背景自适应要跟踪信道变化环路带宽不能做太低但CTLE本身是一个高频模拟放大器在数十GHz带宽下反馈环路稍微增加一点增益相位裕量就迅速恶化容易引起振荡。为了避免振荡就得把环路带宽降得很低结果就只能去跟踪非常缓慢的变化比如温度漂移。可既然只跟踪缓慢变化其实用一次性校准加定期重训练就够了真的没必要常年在后台跑一个模拟环路。再看成本。一个完整的高速CTLE背景自适应需要额外的误差检测采样器、模式开关、状态机、环路滤波器和相关校准DAC。这些电路在56GBaud甚至112GBaud的速率下每一路的偏置电流和匹配要求都相当高占用不小的面积和功耗。对于一张会集成几十甚至上百条SerDes lanes的大规模交换芯片来说每一条lane省掉这些开销带来的面积和功耗收益非常可观。这也是为什么商用112G IP的CTLE大多只保留寄存器配置和一次性校准而不是带上完整的后台自适应回路。2.3 PAM4调制对增益稳定性的要求更苛刻了NRZ时代信号只有高和低两个电平判决门限在0附近CTLE增益漂移一点顶多是眼高变小一些容忍度其实比较高。PAM4则不同它把同一个符号间隔里塞进了4个电平相邻电平之间的间距只有NRZ信号的三分之一。这意味着接收端对信号通路上的增益波动极其敏感。CTLE自适应过程中如果高频增益或其他参数发生了哪怕零点几个dB的波动PAM4四个电平之间的相对间距就会改变直接表现为判决裕量下降、误码率上升。也就是说在PAM4系统里自适应带来的“好处”可能还没它引入的“参数波动副作用”大。与其冒着风险去动态调CTLE不如把CTLE固定在一个经优化验证的档位上把剩余的微调交给数字DSP去做——DSP的系数更新是纯数字运算没有模拟域的毛刺和漂移问题。这就像你戴了一副度数固定的眼镜后面还跟了一套随时可以变焦的数字摄像头算法你没必要让眼镜本身一遍遍地变度数那只会让你头晕目眩。3. “不需要背景自适应”不等于“不调CTLE”链路训练与一次性校准3.1 背景自适应和前景校准别搞混了要准确理解“无需背景自适应”首先得区分两个概念背景自适应Background Adaptation和前景校准Foreground Calibration。背景自适应是正常传输数据期间不间断地调整参数系统没有任何专门用来校准的窗口。前景校准则是在一段时间里暂停或暂时不关心业务数据流利用已知的训练序列来测量信道、配置均衡器完成后恢复正常传输。112G/224G系统里CTLE并不是靠运气“猜”一个固定值就用一辈子而是通过链路训练Link Training机制在链路建立的初始阶段就完成一次前景校准。IEEE 802.3ck、OIF CEI-112G等规范里都有明确的链路训练流程训练期间收发双方会发送预定义好的训练序列接收端用这些已知信号对信道进行测量然后更新接收端各均衡模块的配置参数。3.2 一次典型的112G链路训练中CTLE是怎么被定下来的我以比较常见的以太网背板/铜缆场景为例把CTLE配置的过程拆开讲。第一步物理层进入训练模式。发送端发出连续的训练信号这个信号在一个副载波频率上带有已知的调制图案例如重复的PRBS或者其他标准定义的训练帧。接收端的CDR先恢复时钟从信号中获取链路的基本同步信息。第二步接收端的DSP或者模拟前端辅助电路测量信道特性。设计者通常会利用训练信号计算接收信号的眼图质量、频响估计或冲激响应。根据测量结果预估信道插损在高频处的衰减量以及低频损耗的差距。第三步CTLE参数设定。接收端会根据信道估计结果在预先设计好的一系列CTLE配置档位里选择一个在目标误码率下综合表现最优的组合。这些配置档位一般包括低频增益、高频提升量Boost、零点位置、极点位置等每个参数都有数字寄存器来控制。第四步锁定配置。训练完成后CTLE的寄存器直接锁定整个正常数据传输阶段保持不变。后续如果链路因为温漂等原因出现轻微劣化DSP的均衡器系数会去自适应调整而CTLE纹丝不动。为了更直观我用一个简化表格罗列一下CTLE里常见的可配置项和它们影响什么配置项对信号的影响典型范围示意低频增益DC Gain决定信号的基准放大倍数0 ~ 6 dB高频增益/Boost补偿信道高频插损抬升高频分量0 ~ 14 dB零点频率Zero控制补偿从哪个频段开始抬升2 ~ 10 GHz极点频率Pole限制高频增益继续上升避免放大噪声20 ~ 40 GHz不同芯片的实现会略有差异有的还会把增益和零点耦合在一起用统一的EQ index档位来表达。你只要记住所有这些参数都支持在训练阶段被写入和锁定就可以了。3.3 训练过程中怎么判断哪个CTLE配置“最好”实际工程里“最好的CTLE配置”不是靠主观感觉拍脑袋而是有一个明确的目标函数。最常见的一类是最大眼高和眼宽发完训练序列之后DSP会统计接收信号在采样点位置的电平分布算出一个三维眼图然后以眼图张开高度和宽度作为评估指标。另一类是直接以误码率或信噪比为目标选择能让后级DSP均衡器输出信噪比最高的配置。一个容易忽略的细节是CTLE的配置不能孤立地看必须考虑它和AGC、DSP均衡器的联动。比如CTLE的boost设得太高信号高频噪声和串扰也被一起放大ADC输入端的有效信噪比反而下降设得太低高频分量衰减严重ADC采样出来的信号可能已经淹没了量化噪声。所以在链路训练里系统往往会把AGC固定到一个合适的值然后对CTLE档位做扫描选出一个“CTLEDSP”联合信噪比最高的点。这个点才是真正的最优工作点。仿真阶段我建议可以用IBIS-AMI模型配合通道S参数做完整链路仿真把CTLE所有档位扫描一遍事先确定整个温度范围内的推荐配置。到了实验室再用实际板卡做验证通常能提高不少效率也可以避免在实验室里毫无头绪地翻寄存器。3.4 校准完成之后凭什么CTLE能长期不动有人会问温度升高、PCB损耗变化信道特性会漂移啊CTLE一直不动后面不就偏了吗这个问题需要从两个维度看。第一信道特性在正常工作范围内的变化幅度其实没有想象中那么大。优质的高速板材如Megtron 6/7在温度变化下的插损漂移是有限且缓慢的通常只有零点几dB到一两dB级别。而DSP里面的FFE和DFE本身就具备跟踪这种细微变化的能力它们会在后台自适应地更新系数不需要CTLE跟着动。第二CTLE的设计余量已经覆盖了一部分变化。链路设计工程师在做预算时目标误码率下的眼图/信噪比裕量会留出足够的margin这个margin足以吸收长期温漂、老化和不同批次板卡差异。换句话说固定CTLE并不是对信道变化视而不见而是预测到变化在可控范围内然后把修正任务交给了更擅长持续调整的数字模块。这就像你先把大方向对准了剩下的细微晃动交给自动驾驶去修总比自己不停地拨方向盘要稳定。4. 但有些地方CTLE还是会“动一动”边界与例外既然是工程问题就一定有边界条件。说“无需背景自适应”是指主流112G/224G片上SerDes的接收端因为后面有强大的DSP兜底。但如果换一个场景这条规则并不总是成立。4.1 重定时器、光模块DSP里的均衡器仍会自适应重定时器Retimer工作在两条链路之间它既要接收一端信号并均衡也要把信号重新发送给另一端。在一些重定时器芯片内部接收端的均衡架构如果不完全是ADC-DSP而是保留了较多模拟均衡成分那么它仍然可能在后台做适应。原因很简单重定时器两侧的链路是不同板卡、不同线缆、不同标准定义的信道不确定性比固定背板大得多没法只靠一组固定CTLE覆盖。类似的情况也出现在光模块的DSP里。光模块内部的DSP通常叫DSP DimRed处理的是经过光电转换后的信号信道的特性与PCB背板完全不同而且模块插入的交换机端口、对端设备不同光路衰减差异也大。这类应用中的均衡模块往往会保留自适应的机制。不过很多情况下它们的自适应也是在数字域完成的真正在模拟CTLE上做连续背景自适应的方案已经越来越少见。4.2 多速率、多协议切换时的档位切换不是“背景自适应”有的芯片需要同时支持不同的速率档位比如同一颗PHY在10G/25G/50G/100G之间切换或者同一lane在PCIe和以太网协议之间复用。不同速率下信道的相对衰减特性不同CTLE当然不能一个档位打天下。因此芯片内部会预定好几组CTLE配置在模式切换时一次性写入对应的寄存器值。这种操作本质上还是“前向校准/档位切换”不是数据流运行期间的连续背景自适应。它的特点是切换动作发生在速率协商阶段链路还没有开始传业务数据即使切换过程有一些毛刺或非线性也不会造成误码因此工程上是安全的。4.3 极端温度环境下靠什么兜底最后说一个工程里比较精妙的点如果在高温环境下链路余量告警我们该怎么办很多资深工程师都会告诉你不要等误码率已经爆了再去动CTLE而是应该在链路余量下降到某个门限时做一次“重新训练”Retraining把CTLE和DSP参数重新校准一遍。重训练的触发机制可以用BER监测、SNR监测或者温度传感器来实现。一旦触发链路会短暂中断或进入训练状态再重复一遍第3章说的流程重新找一组CTLE配置。这种方式既避开了数据流中的连续自适应又能应对大范围的环境变化逻辑上更干净实现上更简单。毕竟只要你对重训练的频率没有苛刻要求就不需要为了让CTLE每时每刻都完美而付出巨大的模拟硬件代价。5. 落实到工程固定CTLE配置的开发与验证心得讲了这么多原理最后分享一些我在项目里亲测有效的经验和踩过的坑。5.1 选定一组CTLE配置的标准流程第一步收集所有可能用到的通道S参数。包括背板不同走线长度的最差情况、各种跨接连接器的组合、以及不同温区下的实测或仿真S参数。把通道模型建好这是后续所有工作的基础。第二步使用IBIS-AMI仿真工具做CTLE档位扫描。每个档位跑一遍全链路仿真统计目标误码率下的眼高、眼宽和SNR。特别注意要把发送端Tx FFE的设置一起纳入扫描得到一张“Tx系数CTLE档位”的二维性能表而不是单独看CTLE。第三步根据最差通道选配置。工程上要选一个在大多数通道、大多数温度条件下都能达到目标误码率的配置而不是在某一条漂亮短走线上性能最好的配置。同时留出足够的锁存裕量和温漂裕量。第四步拿着这个配置去实验室做极限测试。换不同板卡、不同模块、高低温箱用BERT误码率测试仪验证实际链路余量。如果室温下余量充足但高温下掉了就要回到仿真结果里重新调整选档。5.2 固定CTLE配置最容易踩的三个坑我见过不少团队在CTLE固定配置上栽跟头反复出现的坑主要就是下面这三个。第一个坑是过补偿。为了让眼图“看起来”很open把CTLE的boost调得过高高频噪声和串扰被同步放大结果误码率反而更差。这个现象在长走线和串扰严重的通道上尤其明显。调CTLE的时候不能只看高频补偿得好不好还要看整体SNR和浴缸曲线。第二个坑是把AGC和CTLE割裂开来调。CTLE的高频boost会影响信号总功率如果AGC的参考电平是固定的boost一加大ADC输入信号就可能削顶AGC一自动变化CTLE的相对效果又被削弱。这两个模块必须联合起来理解。我的习惯是先调AGC到一个不上不下的状态再动CTLE最后再微调AGC来回迭代两次就能找到稳定工作点。第三个坑是忽视电源噪声和耦合路径。CTLE是模拟放大电路它的性能高度依赖供电的干净程度。固定配置之后如果电源域的开关噪声落在CTLE的工作频带附近哪怕CTLE本身设置完全正确输出眼图的抖动也压不下去。因此CTLE的电源引脚、去耦电容、参考电压的PCB布局跟CTLE参数设置一样重要这一点经常被新入行的工程师忽略。5.3 固定CTLE之后链路优化重心应该放到哪里既然CTLE不再参与后台调节链路的在线优化重心就转移到了发送端Tx FFE和接收端DSP上。实践下来优先调整发送端的Tx FFE通常比调接收端要更高效因为发送端的信号经过信道后同样会影响接收端眼图而且Tx FFE的调节会直接改变信道入口处的信号频谱形状。我在实际项目中比较推荐的做法是先保持CTLE为推荐配置不动然后通过Tx FFE的预加重把高频分量适当补偿一部分再观察接收端DSP的均衡系数是否收敛到一个偏离默认较远的位置。如果DSP的系数明显偏到边界说明整体均衡预算分配不合理这时候再回过头去调整CTLE档位而不是在DSP上硬拉。把CTLE当一个粗调旋钮、Tx FFE当一个中调旋钮、DSP系数当精调旋钮三层搭配好了链路余量通常都能比较健康。我个人的体会是CTLE在112G/224G时代去背景自适应化不是功能缩水而是模拟和数字分工演进的必然结果。做高速系统设计最忌讳的是抱着原来某一代产品的惯性思维去硬套新一代架构。CTLE从一个智能均衡器变成一个可配置的前置放大器看起来很“退化”实际上是整个系统变得更强之后把最不擅长在超高速下工作的环节简化到了它最擅长的位置。理解了这个思路你再去看未来224G甚至448G芯片的手册就会更从容看到CTLE只有几个寄存器配置位不会再惊讶也不用慌。
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

Atlas 300V 24G跑YOLO实战:环境搭建到性能调优 2026/9/25 15:26:15

Atlas 300V 24G跑YOLO实战:环境搭建到性能调优

关于Atlas 300V 24G,网上问得最多的两个问题我天天能看到:它到底是不是一张正经的运算加速卡,以及它跑YOLO到底行不行。不瞒你说,我拿到这张卡的第一反应也是先翻规格书再上机实测。这卡在名称上确实有点迷惑性,看着像…

阅读更多 →
【洛谷P1001】 2026/9/25 15:26:15

【洛谷P1001】

题目背景与要求本题是洛谷(Luogu)的入门题 P1001 AB Problem,旨在帮助初学者熟悉算法竞赛的输入输出格式。题目本身非常简单:输入两个整数 a 和 b,输出它们的和。关键注意事项:输出中不能包含任何多余的提示…

阅读更多 →
用 Metaflow Client API 搭建流程监控仪表盘:07-worldview 教程全解 2026/9/25 15:26:02

用 Metaflow Client API 搭建流程监控仪表盘:07-worldview 教程全解

MLOps工作流自动化数据工程 【免费下载链接】metaflow Build, Manage and Deploy AI/ML Systems 项目地址: https://gitcode.com/gh_mirrors/me/metaflow 点击查看 免费下载 本教程对应仓库中 metaflow/tutorials/07-worldview/README.md 及配套的 worldview.ipynb…

阅读更多 →
WeiXinMPSDK 微信支付 V3 Native 支付实战:扫码下单、QR 码生成与异步回调实现 2026/9/25 15:26:02

WeiXinMPSDK 微信支付 V3 Native 支付实战:扫码下单、QR 码生成与异步回调实现

后端即时通讯金融科技 【免费下载链接】WeiXinMPSDK 微信全平台 .NET SDK, Senparc.Weixin for C#,支持 .NET Framework 及 .NET Core、.NET 10.0。已支持微信公众号、小程序、小游戏、微信支付、企业微信/企业号、开放平台、JSSDK、微信周边等全平台。 …

阅读更多 →
Atlas 300V部署YOLO全流程:从硬件安装到模型转换与推理实战 2026/9/25 15:26:02

Atlas 300V部署YOLO全流程:从硬件安装到模型转换与推理实战

1. 项目概述:Atlas 300V 到底是一张什么卡最近后台收到不少朋友在问同一件事,热搜词条里“atlas部署yolo”“atlas 300v 24g 是运算加速卡吗”反复被顶上来。看来很多做视觉算法、做边缘计算的朋友,都对这张卡动了心思,但又不确定…

阅读更多 →
简单的命令行 MCP 客户端 2026/9/25 15:25:43

简单的命令行 MCP 客户端

用于测试和调试 MCP 服务器的, 是基于 Model (MCP) 的 MCP 客户端, 乃交互式客户端。功能, 其中包括**工具调用**, 即要去罗列出、挑选并施行服务器工具;还有**提示词管理**, 也就是去查看以及运用服务器提示词;再者是**资源查看**, 即浏览服务器资源内容…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉