讲个反直觉的事儿同样跑10Gbps32位并行总线需要的引脚和功耗往往比一对差分串行线高出几十倍带宽却还上不去。第一次接触SerDes这个词的人多半会被Serializer/Deserializer的名头唬住以为是什么了不得的高深模块。说到底它做的事就是“并行转串行、串行转并行”但就是这一转让PCIe、Ethernet、SATA、USB、HDMI、DisplayPort这些高速接口全都站在了同一条技术路线上。这篇文章适合刚接触芯片设计、FPGA高速接口或者要做板级高速链路方案的工程师阅读。我会把SerDes IP涉及的底层概念一次讲透为什么非串行不可、链路内部有哪些模块、CDR是怎么从数据里“抽出”时钟的、信道损耗要靠什么手段抗住、NRZ和PAM4到底怎么取舍以及最后选IP核和排障时常见的几个坑。内容偏基础但会把很多文档里含糊过去的关键逻辑掰开揉碎。1. 为什么高速传输偏偏要“串行”带宽悖论背后的逻辑1.1 并行总线是怎么被逼到墙角的早年间CPU和北桥之间、设备和控制卡之间的通信几乎清一色并行。一根32位总线数据线30多根加上地址线、控制线、时钟线一个接口几十上百个引脚。低速时代这个方案毫无问题因为时钟低信号边沿缓线跟线之间的长度差异、噪声干扰都还没资格成为瓶颈。但频率一旦往上提并行总线的麻烦就集体爆发。首先是skew也就是线间偏斜。PCB上走线不可能做到完全等长信号从驱动器到接收器每根线到达的时间天然有差异。总线频率越高一个时钟周期越短这个时间差占的周期比例就越大留给数据有效窗口的余量被压得越薄。等频率涨到几百兆赫兹级别线间偏斜本身就可能吃掉大半时序预算板厂连等长约束都做到头了也无济于事。更麻烦的是串扰。并行的几十根线挨得那么近一边翻转一边静默容性耦合和感性耦合会把噪声灌进邻居线。低频时这点串扰影响不大高频时它直接劣化信号质量布线越密越严重。还有个被低估的问题是功耗同时翻转几十个引脚本来就不省油频率翻倍动态功耗跟着翻倍接口电路跑成的热量和电源噪声又把信号质量反向拖下水。1.2 串行赢在哪里一对差分线的优势改成串行之后逻辑上很简单把本来并行送出去的N根线变成用一根更严谨地说是一对差分线以N倍速率逐比特送出去。这等于用“时间换空间”付出的代价是单根线上的速率变成了原来的很多倍换来的却是几个至关重要的红利。第一没有线间偏斜问题了。所有比特都在同一对物理线路上顺序传递接收端只要盯着这一个信号恢复时钟按节奏取数不会出现A线上的bit和B线上的bit谁先到谁后到的困扰。第二差分传输天然抗共模干扰。一对线里一个走正一个走负接收端看的是两者差值外部耦合进来同时叠加在两条线上的共模噪声会被自然抵消这让串行接口容忍地弹、电源噪声和辐射干扰的能力好了不止一个量级。第三串行速率扩展更加线性。并行总线要提带宽要么涨频率撞上偏斜墙要么加线宽撞上引脚数和布线的天花板串行链路则只要把单线速率提升或者简单地把通道数从1条翻到2条、4条、8条扩展路径直接得多。1.3 从PCI并行到PCIe串行历史给出的答案看协议演变最直观。1990年代的PCI并行总线33MHz、32位数据理论带宽约133MB/s接口上数据地址控制线加起来超过60根。到了PCIe时代最早的Gen1单通道2.5GT/s一条通道一对收发差分线就是250MB/s的净带宽数据总线上约200MB/s而一个x16接口的带宽已经远非老PCI可比引脚还更少。这背后的本质是并行总线在物理层的收益早就被偏斜、串扰和功耗吃光了继续在“同时多根线”这个维度上加码边际成本爆炸式增长。而串行总线把复杂度集中到收发端电路上用更少的引脚、更少的走线把同样的甚至高得多的吞吐量交给一对线去跑。再往后看几乎所有高速协议都殊途同归这就是SerDes成为SoC和FPGA里标配模块的原因。2. 一条SerDes链路内部到底长什么样从发送端到接收端逐块拆解2.1 宏观旅程并行数据进、并行数据出从使用者视角看SerDes就是个黑盒子这边进去并行数据那边出来并行数据中间肉眼什么也看不到。但打开盖子一条完整的链路可以拆成五段旅程并行数据先被送入发送端的协议前层PCS做编码和加扰然后交给物理介质接入层PMA进入真正的串行化电路变成高速差分信号经过PCB走线、连接器、线缆这些信道到达接收端再从PMA解串回到PCS解码最后还原成并行数据。PCS和PMA的分工容易被初学者忽略。简单说PCS负责“逻辑层面的活”比如8b/10b编码、64b/66b编码、加扰、对齐标记插入、CRC这些是为了保证DC平衡和时钟恢复的跳变密度PMA负责“模拟层面的活”包括串化、驱动、均衡、时钟恢复、解串。选SerDes IP时你拿到的东西通常把PMA做成了硬核hard macroPCS有时候跟着PHY一起给有时候需要自己在逻辑里实现或者用IP里的软逻辑。2.2 发送端三件套PLL、Serializer和驱动器发送端的核心模块是三个。PLL把低频率的参考时钟常见100MHz或156.25MHz倍频到与线速率对应的比特时钟。比如跑25Gbps的NRZ如果采用全速率时钟架构PLL输出就是25GHz的时钟这是很高频的模拟电路设计所以很多实现会改用半速率甚至四分之一速率架构用时钟的上下沿甚至多相位来采样降低PLL本身的难度。Serializer负责把宽的并行数据变成串行比特流。内部通常是一棵并行移位树或者一组多选一逻辑用高速时钟逐级并转串。这里的工程难点不在结构而在数据在移位过程中不能有毛刺任何一段亚稳态传下去就是一连串误码。驱动器把串行比特流变成能推着PCB走线走的差分信号常见的是电流型current mode logicCML驱动器或电压型驱动器输出端要做阻抗匹配差分阻抗一般按100欧姆设计输出幅度也有协议规定。驱动器上还挂着发送端均衡FFE用多抽头的有限冲激响应滤波器对要发送的码型做预整形这部分后面专门讲。2.3 接收端前端放大、时钟恢复和解串接收端的旅程比发送端险恶得多。高速信号经过信道衰减到达接收引脚时幅度可能只剩发送端的几分之一甚至几十分之一。第一步是接收前端通常包含一个宽带放大器配合CTLE连续时间线性均衡做高频提升还有一级可变增益放大器VGA把信号幅度修整到ADC或判决器的最佳输入范围。然后是重头戏CDR时钟数据恢复。它从带有跳变的数据流里提取出比特时钟并且找到最佳的采样相位把每个bit从噪声和符号间干扰里“捞”出来。CDR之后是Deserializer把恢复出的串行数据按照时钟排成并行字。如果接收端还用DFE判决反馈均衡那么还要把判决器的历史结果反馈回来做非线性均衡处理。一个容易混淆的点是很多现代接收端会在CDR前加一个ADC把模拟信号变成数字域后续的均衡和判决全部在数字域完成传统做法则是纯模拟接收前端一路做到判决器。两者分别对应DSP型和模拟型接收机架构在高速率、长距离链路上DSP型越来越常见但代价是功耗和延迟。2.4 时钟架构全速率、半速率还是1/4速率SerDes的时钟架构是选型和功耗估算里绕不开的话题。全速率架构下时钟频率等于比特率比如112Gbps的PAM4链路意味着PLL要输出56GHz的符号时钟PAM4每符号2比特这是极高频的模拟电路几乎没法用常规工艺实现。于是业界普遍采用半速率或四分之一速率架构半速率下时钟是符号速率的一半用差分时钟的双沿去捕捉数据四分之一速率则使用4个相位每个相位负责四分之一的符号把单路的高频问题转化成多相低速并行问题。这带来的后果是“这个SerDes芯片主频多高”这类问题对SerDes内部其实没有统一答案。你看到IP规格书里的线速率指的是链路上的符号速率内部DSP和数字逻辑跑的时钟往往只有它的几分之一甚至几十分之一。这个区分在估算功耗、分析时钟树、做FPGA集成时特别重要因为数字侧接口时钟通常远低于线速率衔接处需要可靠的异步FIFO或握手逻辑。3. 时钟恢复CDR与训练没有时钟线也能对齐数据3.1 为什么SerDes不走一根独立时钟线有人会问既然怕偏斜那把时钟和数据一起并行送不就好了并行总线里时钟和数据各走各的高速下即使板级等长做得好时钟的到达时刻也会因为温度、电压的变化与数据偏移更糟糕的是参考时钟的抖动会直接变成时序抖动。SerDes干脆做一个极端选择不传输独立时钟把时钟信息嵌进数据码流里由接收端自己恢复。这就是CDR存在的根本理由。代价是数据码流必须保证足够的跳变密度否则接收端没有边沿可“咬住”时钟。所以SerDes链路普遍做编码8b/10b保证最长连0/连1不超过5个bit64b/66b用同步头保证每66个bit至少有两次跳变以太网的RS-FEC还会进一步做扰码。做编码另一个好处是提供DC平衡避免长串同极性导致接收端的电平判决点漂移。3.2 CDR的三条技术路线CDR实现方式大致三条路线。PLL型CDR是传统主力相位检测器比较数据边沿和本地恢复时钟的边沿产生超前/滞后信号环路滤波器把它滤波后去控制压控振荡器VCO或数控振荡器DCO构成一个锁相环路。这是一种闭合的模拟反馈系统锁定后时钟连续可调抖动性能好。相位插值型CDR则是用一个固定PLL产生多个等间隔相位比如128个再由数字逻辑根据相位检测结果选择插值点把时钟“拨”到最佳采样相位。它没有VCO直接工作在数据频率上比较容易被数字逻辑控制和集成常出现在需要数字接口的IP里。过采样型CDR更直接用N倍于数据率的时钟对数据多打几个点然后根据这些点的分布判断最佳判决位置。它结构简单早期低速SerDes常用但速率较高时功耗和时序压力都偏大。现在很多高性能SerDes更多用PLL型或相位插值型或者两者混合。3.3 抖动预算与CDR带宽的博弈CDR的环路带宽是个需要拿捏的参数。带宽高锁得快对低频抖动跟踪能力强但对高频抖动抑制差带宽低能把高频随机抖动滤得更干净但锁定慢而且会对信道的低频变化反应迟钝。工程上常用“毫UI”来标定抖动预算一个UI等于一个符号的时间宽度比如10Gbps NRZ下UI就是100ps。发射端的参考时钟抖动、电源噪声引起的周期抖动、信道的码间干扰产生的数据相关抖动都会吃掉采样裕量。协议通常会规定CDR抖动容忍曲线曲线的低频段要求CDR能跟踪大频偏高频段要求不引入额外误码。这也是为什么PCIe这些协议对参考时钟有严格的抖动和频谱要求板级设计如果图省事在参考时钟上摆了太差的晶振SerDes链路跑不起来几乎是必然的。3.4 协议训练序列链路是怎么握手起来的CDR不是上电就能锁定的。快速串行链路都有一套训练Training或握手机制。PCIe在Link Training里会依次传送不同的均衡训练序列接收端根据收到的信号质量计算并请求发送端调整预加重和发送幅度等电气参数收敛、CDR锁定、误码验证通过链路才进入正常工作。以太网的历史方案是Auto-Negotiation而更高阶的链路在启动时同样会用训练帧Training Frame交互。这部分对做FPGA或SoC集成的人来说尤其重要所谓“链路训练失败”很多时候并不是芯片坏了而是训练过程中的某个必要条件没满足比如参考时钟不稳定、差分极性接反、通道到这里损耗太大导致第一阶段信号就无法识别。理解训练的顺序能帮你快速定位排障方向。4. 高频信道不相信眼泪损耗、ISI与均衡三件套4.1 信道为什么会让信号“糊掉”PCB走线、过孔、连接器、线缆组合在一起就是一个低通滤波器。频率越高衰减越凶。衰减来源主要是两项趋肤效应让高频电流只在导体表层流动等效电阻随频率上升而增大损耗与频率的平方根成正比介质损耗则是板材分子在高频电场下反复极化产热损耗与频率成正比。一块普通FR4板材上10英寸走线在约8GHz时插入损耗常常超过20dB意味着信号幅度在接收端只剩原来的十分之一左右。损耗不光压幅度更致命的是它带来的符号间干扰ISI信号被拉长拖尾当前bit会被前几个bit的尾巴污染。一个典型的矩形脉冲通过低通信道后会变成带长拖尾的缓变波形前一位的“尾”叠在当前位上判决门槛附近的电压就会被上下拉扯。跑长串连0或连1时信号幅度还会逐渐漂移到稳态电平紧跟其后的跳变幅度更小这些都让接收端判决的难度剧增。4.2 均衡的三种手段和它们的分工要抵消信道低通效应手段就是“哪里缺补哪里”和“把尾巴剪掉”。均衡三件套是这么分工的发送端FFE前馈均衡/预加重去加重。发送端在发射前先对码型做整形低频成分压低一些高频成分抬高一些让信号经过信道衰减后接收端看到的频谱更接近原来的样子。实现上用多抽头FIR滤波器抽头覆盖当前bit前后的几个UI可以产生预置加重力度。因为发送端能处理的信号幅度是有限的压低低频频段等于削弱整个信号功率所以去加重的力度是权衡的结果。CTLE连续时间线性均衡。接收端模拟电路做高频增益提升把信道压掉的高频补回来。优点是线性、结构简单、功耗低缺点是不能区分信号和噪声高频提升的同时会把高频噪声一起放大。适合应对较短的通道和中等损耗的频段。DFE判决反馈均衡。原理是既然当前bit受到的ISI来自前面几个已经判决出来的bit那就把它们的判决结果乘以对应系数反馈回来从整个信号里减掉这几项。关键是DFE不放大噪声——它减的是确定性的码间干扰噪声没有相同的反馈路径所以不会像线性均衡那样“噪声增强”。主流高速SerDes接收端几乎都标配DFE抽头数量比如1抽头、2抽头直到更多直接影响能消除多少拖尾。4.3 接收端摊开的眼图是常态不是故障很多人第一次看高速链路“眼图全关”会吓一跳。在发送端眼图明明又大又方到了接收端引脚处由于信道损耗眼图可能完全闭合看起来跟噪声没什么区别。这不代表系统坏掉了——闭环后的判决节点眼图才是有效信号。均衡链路把信号修整、ISI抵消干净之后判决器前端的眼图会被重新“撑开”。所以判断链路裕量一定要看均衡后的眼图或者等效的误码浴盆曲线而不是接收引脚处的原始波形。这也是为什么很多芯片提供内部环回和PRBS误码测试功能它们可以在不依赖外部示波器的情况下直接告诉你判决节点上还能剩多少裕量。4.4 一张表看懂谁负责哪段均衡模块位置本质主要作用局限TX FFE/去加重发送端线性FIR整形预补偿信道削弱低频抬高频会降低整体幅度力度受限CTLE接收端模拟前端线性高通/峰化补偿高频损耗放大噪声增益不能过高DFE接收端判决前后非线性反馈抵消确定性ISI拖尾抽头有限不能消除预游标干扰CDR接收端反馈时钟恢复对齐采样相位带宽与抖动容忍需要折中这四者形成一条链FFE在源头“预弯”信号CTLE做粗补偿DFE做精细化消除CDR负责在正确的时刻采样。做板级方案时你会看到的IP配置项通常就是这几类的力度/抽头数/带宽参数但从系统角度理解它们的关系比盲目调参数重要得多。5. NRZ、PAM4与协议线速率的算术5.1 NRZ一个UI一比特的简单世界传统SerDes用NRZ调制即非归零码高电平代表1低电平代表0每个符号单位间隔UI携带1比特信息。NRZ结构简单信噪比要求直观均衡和CDR的设计成熟。它的比特率就是符号率比如32GT/s的PCIe Gen5 NRZ实际链路波特率就是32Gbaud。NRZ的软肋在于想继续提速就必须提高波特率但信道损耗随频率剧增。从10GT/s干到32GT/s可以靠先进工艺和更强均衡硬撑要做到五六七八十吉比特每秒级别的每通道速率NRZ的路径基本到头了。5.2 PAM4牺牲电压换速度PAM4在每个符号时间里用4个电平如-1、-1/3、1/3、1表示2比特。对同样的比特率PAM4的符号率只要NRZ的一半波特率减半信道损耗在等效奈奎斯特频率处大幅下降这让原本NRZ完全推不动的速率有了工程可行性。代价是判决裕量急剧收缩。NRZ在理想情况下一个符号有一个大眼眼高就是满摆幅PAM4则有三个垂直叠放的眼每个眼的垂直高度只有总摆幅的三分之一左右同等幅度的噪声、串扰、反射对三个小眼的干扰比例就大得多。工程经验上要达到相同的误码率PAM4相对NRZ需要多出约9到10dB的接收灵敏度也就是信噪比要提升约3倍。5.3 这里最容易算错波特率和比特率很多人在SerDes规格前面栽过跟头就是把“Gbps”和“Gbaud”混为一谈。以“50Gbps PAM4”链路为例它的线速率是50Gbps但电通道上跑的是25Gbaud——每个符号2比特。PCB板级工程师关心的损耗曲线、示波器看到的眼图宽度都对应25Gbaud这个数字而不是50Gbps。反过来对NRZ链路Gbps和Gbaud数值相等这给习惯了NRZ的人埋了个思维定式。这个区别在做通道预算时直接决定成败。某条走线在10GHz能扛住不代表20GHz能扛住一个标称56Gbps PAM4的SerDes其电接口的奈奎斯特频率约14GHz56/2/2而同样名义速率的56Gbps NRZ如果存在的话奈奎斯特频率就是28GHz两者对板材、连接器和过孔的要求天差地别。5.4 主流协议的SerDes选型对照协议线速率调制方式典型通道结构备注PCIe Gen38GT/sNRZx1/x4/x8/x16早期典型均衡训练机制PCIe Gen416GT/sNRZx1/x4/x8/x16每通道净吞吐翻倍PCIe Gen532GT/sNRZx1/x4/x8/x16NRZ在PCIe路径上的高水位PCIe Gen664GT/sPAM4x1/x4/x8/x16引入PAM4和轻量FEC10G/25G以太网10.3125/25.78125GbpsNRZ单通道常见于数据中心网卡/交换100G/400G以太网每通道25.78125/53.125GbaudNRZ / PAM4多通道并行100G每通道方向各有各的实现这个对照表想说明的是同一块SerDes硬核如果IP只做了通用物理层往往要靠配置来适配不同协议而协议专用的PHY把PCS、FEC、训练状态机都做成硬逻辑功耗和面积更优但灵活性差。选型时先搞清楚你要跑什么协议、哪些模式必须兼容再去对比IP规划顺序别反了。6. 选SerDes IP核时的落地考量从速率需求到集成风险6.1 先分清你要的是协议PHY还是通用SerDesSerDes IP在市场上分两大类选错方向会非常痛苦。一类是协议专用PHY比如PCIe PHY、以太网PHY、SATA/USB PHY它们把PCS、训练、FEC、链路状态机全部固化对外暴露的是协议接口而不是裸SerDes。好处是兼容性好、验证充分、设计工作量小坏处是灵活性差你不能拿一个PCIe PHY去跑自定义协议。另一类是通用SerDes只提供物理层PCS往往留给用户自己实现或者配套一个可配置的PCS核。它支持自定义速率、自定义协议适合背板互连、chiplet互连、私有高速总线这类场景。代价是几乎所有协议层面的工作都要自己扛训练、初始化、FEC、对齐方式都要自己写这是很多FPGA项目里被严重低估的工作量。6.2 硬核MACRO、测试接口和参考时钟必须提前接受一个事实高速SerDes几乎必然是hard macro也就是模拟电路版图已经固定的硬核由工艺厂或第三方IP厂商在特定工艺节点上实现。它跟数字逻辑的综合流程完全无关你拿到的是一套经过验证的GDSII或配套的物理实现文件把电源地、模拟IO、高速引脚、配置总线接好就能用。这也是为什么SerDes IP的工艺绑定极其严格在某节点合格的硬核换个工艺就得重做。这带来一个集成层面的要求模拟电源域必须单独照顾。SerDes对电源噪声极度敏感官方设计手册通常会要求独立的LDO或专用供电引脚、指定去耦电容的布局密度、限制数字逻辑翻转对模拟域的串扰。很多“IP集成没问题但链路跑不上去”的根因不是IP坏了而是电源平面布局和去耦没达标。6.3 选型清单和容易忽略的问题我习惯按这样一个清单过一遍候选IP线速率范围最低速率和最高速率是否覆盖需求有没有中间速率盲区。协议兼容模式是否需要支持PCIe/Ethernet等具体协议的电气和训练要求还是纯自定义。信道长度与损耗预算IP标称的channel reach是短距chip-to-chip还是长距backplane这决定了均衡能力的上限。参考时钟需要的频率、是否支持展频时钟SSC和独立时钟域。功耗与面积每通道功耗、待机功耗以及硬核占用的die面积和引脚布局约束。测试能力内置PRBS发生器/校验器、环回模式远端/近端、JTAG/边界扫描是否齐全有没有专门的误码监测寄存器。物理实现约束高速引脚在封装里的位置、扰流焊盘、ESD结构和你的封装/板的出线方式是否顺。容易被忽略的是最低速率约束。很多SerDes硬核不支持任意低的速率例如有的PLL锁频范围下限就是1Gbps你想用一个低速旁路模式做测试却发现硬件上做不到。这类约束通常藏在数据手册的小字里一定要在选型早期对清楚。6.4 IP验证材料怎么审IP厂商给你的验证套件通常包括功能模型behavioral model、验证寄存器说明、集成清单、以及芯片回片后的可用性报告。不要只看功能模型仿真因为行为模型再好也不代表硬核在硅片上能达到标称性能。真正有参考价值的是一份“硅验证silicon proven”记录至少包含批量回片、工艺角覆盖、误码率或眼图测试数据。没有这个证据的IP风险全部转嫁到你自己的回片验证阶段那个成本可比选型阶段大得多。还有文档完整度。手册里除了寄存器表至少要有电源时序要求、复位时序、时钟质量规格、差分走线阻抗和匹配建议、以及已知限制known issues列表。如果一个候选IP的文档连“已知问题”都不写要么它没有足够的流片经验要么它在藏问题。对落FPGA/ASIC项目而言这两条都是危险信号。7. 实测与排障链路联不通时到底先查哪里7.1 训练不上最常见的三个原因我自己调试高速链路时经历过的大多数“死锁”归纳起来就三类原因。第一是参考时钟不给力。参考时钟抖动过大、频率偏差超出允许范围比如PCIe要求100ppm以内、或者SSC开启时展频幅度和调制率超标都会让CDR在训练阶段无法锁定或反复失锁。调试时先把参考时钟的波形、频率精确度和抖动用频谱仪或者带时钟恢复的示波器量清楚再谈别的。第二是通道极性或通道顺序接反。差分对的正负极性接反或者多通道链路的lane顺序不对称链路会在物理层训练阶段一直折腾却始终无法进入工作状态。这类问题往往不是设计失误而是PCB出线时管脚映射表贴错检查时需要把原理图、封装引脚定义和IP的通道映射逐一对一遍。第三是均衡训练收敛不了。发送端能够提供的去加重范围和接收端要求的均衡力度不一致训练会不停地调整但始终达不到误码率要求。这时候可以先做外部环回确认单个芯片收发正常再用短通道验证链路本身逐步排除到底是通道损耗过大还是均衡参数配置范围不对。7.2 眼图、浴盆曲线和误码率的关系示波器测眼图是SerDes验证的基础动作。用带时钟恢复功能的实时示波器或者采样示波器选择数字通道作为触发恢复源观察采样点的眼高、眼宽和抖动直方图。眼图是“看”链路质量的第一层但要量化误码特性还得看浴盆曲线在采样相位扫描的每个位置上测误码率把误码率画成浴盆形状中央平坦区对应无误码的“安全区”两侧上翘的曲线越陡说明信号在这个链路上越脆。这里有个常见误区只测眼图“看着还行”就放行。眼图的余量其实跟误码率目标强相关很多链路目标误码率在1e-12到1e-15级别意味着上百Gbps速率的通道上一两天都得零误码简单的眼图测试不足以证明那么低的误码率。严谨的做法是在芯片自带BIST或者外部误码仪跑PRBS设好目标误码率阈值跑足够长的时间再结合浴盆曲线的外推来看余量。7.3 电源噪声模拟前端的第一杀手SerDes对电源噪声的敏感度远超普通数字逻辑。电源上的纹波会直接调制到VCO或采样电路的相位上变成周期性抖动表现为眼图的横向上出现规律的摆动。有一种经典场景某开关电源把它的开关频率纹波串进了SerDes模拟供电链路信噪比骤然恶化个别频率点上误码率明显抬升而把电源换成线性电源之后问题立刻消失。这也是为什么IP手册对模拟电源的去耦电容数量和位置往往给出硬性要求比如靠近硬核引脚放若干组不同容值的电容并且要求数字逻辑的供电平面不要与SerDes的模拟域共享同一个电源树区域。做板级或封装级设计时别为了省面积牺牲这部分布局它决定了你的链路在真实噪声环境下还有多少裕量。7.4 我的几条排障心得调试SerDes链路我的顺序始终是先内环再外环最后上板级通道。内环就是开启IP自带的远端/近端环回确认收发器的时钟恢复、编解码和数字侧接口都正常外环是把两根高速差分线外部短接或走一小段短通道回环确认物理层能锁定最后才进入到真实的长走线、连接器场景。每多一个环节就多隔离一类故障源。另有一个容易被忽略的点余量是设计出来的不是测出来的。如果链路在实验室室温下勉强跑通那么温度变化、电压波动、老化之后大概率会出问题。硬件调试时可以把供电电压压到规格下限、把温度拉高看链路还能不能扛住这比单点测试更能暴露真实裕量。做SerDes项目这么多年我最大的体会是别跟物理规律较劲。高速信号链路所有问题的根源几乎都能追溯到“信道损耗、噪声与时间裕量”这三者的平衡上。IP选型时多花一天把时钟架构、均衡能力和测试机制搞清楚比回片后熬夜看眼图划算得多。如果你正在规划一个带高速接口的项目建议先把通道预算和IP规格对齐再谈其他细节。
阅读完成 · 觉得有帮助?