做芯片或FPGA相关项目的朋友一定躲不开SerDes这个话题。不管你是负责系统架构、数字逻辑、模拟版图还是做硬件测试总会在一份接口手册或一次需求对齐时遇到“SerDes IP”这个词。很多新人刚接手这类项目拿到一份几百页的SerDes规格书常常一头雾水眼图模板怎么看、CDR是什么、PMA和PCS各管哪一段、要不要选带均衡的版本……这篇文章就把这些最基础、最绕不开的概念理一遍。我会用做项目时最常用的说法和判断逻辑来拆解覆盖SerDes IP是什么、内部大体结构、一条链路从发送到接收到底经历了什么以及真正做选型和调试时该盯住哪几个关键点。不管是刚开始接触高速接口的验证工程师还是准备把高速串行链路集成进系统板的硬件工程师这篇都能给你一个相对完整的框架。我最早接触SerDes是从一块FPGA开发板开始的当时要跑一个高速数据回传的Demo板子自带SerDes接口但我其实并不清楚刚发出去的并行数据是怎么变成一对差分信号、又是怎么在收端完整恢复的。后来陆续做了好几个和高速串行接口相关的项目踩过不少坑才把这里面的逻辑串起来。这篇文章就是以一个从业者的视角聊聊我觉得新人最该先搞清楚的那几个SerDes IP核心概念。1. 为什么现在都在谈SerDes从并行总线到高速串行1.1 并行传输的瓶颈在哪里早年芯片之间传数据最直接的想法就是多拉几根线比如32位数据总线加时钟、加控制信号一齐翻转、一齐采样。这种并行接口在较低速率下很好用PCB布线也不算太难。但当速率往上提问题就接踵而至几十根线要保证相互之间等长不然信号在不同时间到达接收端采样窗口就对不齐并行总线里的时钟要精确分配到每个接收端高速下时钟偏移就会吃掉大部分时序裕量更麻烦的是几十根信号同时翻转时电源和地平面上的同步开关噪声会被瞬间放大眼图质量肉眼可见地变差。举个实际例子曾经有一版系统板尝试做32位并行DDR接口跑到几百兆赫兹结果只要跑高温老化测试就偶尔传错一个字节。排查到最后发现帧同步头老是丢在特定数据模式上——本质就是某个信号线的过冲影响了相邻线的判断而且那块板的回流路径设计也不够讲究。那之后我就特别能理解为什么行业宁可牺牲一点延迟也要转到高速串行——并行接口在速率和功耗上的天花板太明显了。1.2 串行传输用什么换取了优势并行把噩梦甩给了PCB布线和同步时序串行则把问题集中在了一对差分线上。SerDes的核心思路就是把本来并行发出的数据在发送端按位拆开通过一对或者几对差分信号高速送出去接收端再把这些比特恢复并重新拼成并行数据。这样做最直接的好处就是引脚数量急剧下降。比如一个本来要上百引脚的并行接口换了SerDes之后可能十几对差分就够了这在小封装、多通道系统里是巨大的优势。当然串行传输有代价最大的代价是接收端必须自己从数据里恢复采样时钟也就是所谓CDR还要处理长走线带来的高频损耗。为了缓解这些损耗发送端要加均衡、接收端要加均衡这些都是后话。所以与其说SerDes是对并行总线的全面替代不如说是“把工程问题集中到一个点上解决”的方案——而那一个点恰恰可以从IP层面做得非常极致。1.3 SerDes IP是怎么来的对于大多数系统公司而言很少有人真从晶体管级去设计高速收发器。串行传输涉及的模拟前端、锁相环、时钟恢复、均衡算法每一块都需要长时间工艺迭代和硅片验证。于是就有了“IP化”把经过验证的SerDes做成可复用的模块以硬核或软核方式授权给下游芯片和FPGA用户。老做FPGA的人都知道芯片手册里那一组高速收发器就是集成了厂商的SerDes IP对外提供协议无关的物理层能力而做ASIC时则往往直接选某家IP厂商的SerDes软核配参数硬核直接布局到特定位置。这种IP化对行业最大的改变是让不具备高速模拟设计能力的团队也能造出带高速接口的芯片也让系统级项目可以从算法和应用层面去创新而不是被物理层细节绑死。但反过来也因为SerDes以IP黑盒形式出现很多使用者遇到问题时往往只能对着寄存器调试反而更需要对基础概念有清醒认识。2. SerDes的核心模块构成从CDR到均衡器2.1 总体框架PCS和PMA各管哪一段如果翻开任何一款SerDes IP的用户指南大概率会看到两个高频缩写PCS物理编码子层和PMA物理介质接入子层。这两个词听起来很高大上拆开看其实很清晰。PCS偏“数字逻辑”负责编码、解码、扰码、对齐、字节打包等数据层面的处理PMA则偏“模拟硬核”负责高速串行数据的收发模拟前端、锁相环、时钟数据恢复。有些IP文档里还会细分出PMA再往上叫“PMD”之类但大致上PCS在靠近逻辑侧PMA在靠近引脚侧。调试的时候这个划分非常有用。比如链路出现误码第一步就先确认PMA端的信号质量再看PCS端有没有对齐和编码错误。如果把二者混在一起排查往往会绕远路。我见过一个项目误码率一直降不下来一开始怀疑数字逻辑修了很多天后来用示波器测PMA输出眼图发现上升沿有严重过冲原来是某组电源滤波没做好——这就是典型的把PCS和PMA问题混为一谈了。2.2 发送端并行转串行与预加重发送端的核心动作是并行转串行同时做好驱动和信号整形。低速并行数据进入PMA后经过并转串逻辑变成高速比特流。这个过程中发送端还需要一个高速时钟通常由片内PLL基于外部参考时钟产生。很多IP的发送端会在输出驱动电路上做预加重或者去加重处理目的是补偿信道的高频损耗。预加重的本质其实是在发射端人为调整不同比特序列下的摆幅。当你连续发多个相同的比特时降低一点幅度而在发生跳变的那个比特上加大幅度这样接收端看到的高频分量相对增强配合接收端均衡器就能拿到更干净的眼图。对于板级走线比较长的场景发送端必须打开一定级别的均衡否则接收端再厉害也救不回来。2.3 接收端核心是CDR接收端最核心的模块是CDR也就是从数据流里恢复采样时钟。串行数据没有独立的时钟线接收端只能利用数据本身的跳变沿来“跟踪”时钟。CDR内部一般由一个鉴相器、一个环路滤波器和一个可控振荡器组成闭环数据跳变沿不断纠正本地采样时钟的相位使之稳定锁定在数据眼图中心附近。实际调试时CDR的锁定裕量非常关键。如果数据边缘抖动严重CDR会很难稳定在最佳采样点如果上游参考时钟频偏太大CDR的相位跟踪也容易失锁。所以要评估一个SerDes通道的好坏不光看幅度、看眼高还要看抖动和CDR追踪能力。有的IP调试工具里会有CDR锁定状态和相位裕量寄存器这些参数值得重点记录。2.4 接收端的均衡器CTLE与DFE均衡器是SerDes接收端的另一大核心因为我们常面对的信道不是理想导线而是有趋肤效应和介质损耗的传输线。信号经过长距离传输高频分量衰减得很厉害码间干扰就会加重。接收端均衡器的作用就是“补偿”信道把信号恢复成接近原始的样子。最常见的两种均衡结构是线性均衡器CTLE和判决反馈均衡器DFE。CTLE相当于一个模拟高通滤波器对高频做增益提升DFE则是利用之前判决出来的比特对当前比特的干扰进行反馈消除。很多IP接收端会把CTLE和DFE配合使用CTLE先把大趋势拉平DFE再抠细节。调试时如果发现长尾干扰比较重DFE抽头数往往比CTLE的峰值增益更管用。当然均衡参数不能盲目调大DFE调节过头可能会放大噪声反而让误码率上升。3. 一个SerDes链路从头到尾的工作流程3.1 从并行数据到差分线上的比特流要真正理解SerDes最好走一遍全链路。假设发送端逻辑要发出一个32位并行数据字。在PCS层这个数据字先根据协议做编码比如常见的8B/10B编码把8位数据变成10位码字这样做可以保证数据流里有足够多的跳变沿也方便接收端做DC平衡。编码之后的数据还会经过扰码器打散频谱避免出现长串连0或连1。然后这些并行码字进入PMA被并转串逻辑按位取出最后由发送驱动器和预加重电路送上差分引脚。如果这时候用示波器接在发送端出来的一端看会看到很小的差分信号摆幅通常只有几百毫伏。很多人第一眼会怀疑这是不是信号太弱了。其实这正是高速串行链路的特点——低摆幅、高速率、差分方式靠的是整体链路、端接和接收端放大恢复而不是单靠大幅度信号。3.2 信道传输过程中信号会发生什么差分对在PCB上从发送芯片走到接收芯片会经历高频损耗、反射、串扰。损耗主要来自铜箔的趋肤效应和板材的介质损耗频率越高衰减越严重。反射则源于阻抗不连续比如过孔换了参考层、连接器阻抗不匹配甚至一只端接电阻的排布位置都会带来反射。串扰则是相邻信号之间的能量耦合尤其在高密度板卡里通道间距不够时很容易出现。这也是为什么高速设计非常强调叠层、走线阻抗和过孔回流。做系统集成时如果SerDes通道不稳定第一怀疑对象往往就是PCB走线而不是IP本身。我曾经调试一个高密度背板项目某个通道的误码率总是比别人高好几个数量级最后发现原因很简单那对差分线旁边有一条控制信号的走线高频串扰刚好落在SerDes接收频段内。重新调整布线后问题彻底消失。3.3 接收端如何恢复原始数据接收端引脚收到微弱且受损的差分信号后先经过模拟前端做放大再通过CTLE和DFE进行均衡然后送入CDR。CDR锁定后按恢复出的时钟不断采样得到一串比特。之后这些比特通过解串逻辑还原成并行数据进入PCS层做对齐、解码、去扰码最终恢复出发送端发出的并行数据字。所谓“链路建连成功”其实就是这条双向通路里的发送、传输、接收都能在误码率指标内正常工作。在调试一个真实链路时我习惯先在PMA层看信号质量再做PCS层的数据比对。只要PMA眼图合格PCS逻辑基本不会有太大问题反过来如果PCS层老是对齐失败但PMA眼图看起来没问题那就要回到时钟和协议配置上去查原因。4. 工程实战IP选型与关键参数决策4.1 先定协议还是先定速率做SerDes相关项目时我遇到最多的问题就是“到底该选哪家的IP”。一个很常见的误区是先纠结品牌再去定指标。实际上第一步永远是定协议和数据速率。你打算跑以太网、PCIe、JESD204B还是自定义协议不同协议不仅定义物理层参数还决定PCS层的编码方式和链路训练机制。比如以太网常常用64B/66B编码PCIe在较高数据速率下有专门的加扰和链路训练它们对CDR、均衡和时钟精度的要求各不相同。数据速率也决定了很多物理层细节。做10G等级的系统通常CTLE加简单的DFE就够了一旦跑到50G甚至更高各种高阶均衡、PAM4调制、前向纠错都得安排上。这里我拿某模拟项目X举例需求是传输8路ADC数据到后端FPGA每路速率不到1G。当时评估了几种方案直接用低速LVDS还得布很多对线引入协议开销又大。后来决定使用一对或多对SerDes以自定义协议跑速率压在2G左右每通道IP选型就轻量得多功耗也低整体系统成本下降很明显。4.2 通道数怎么定通道数由总吞吐量和单通道速率共同决定。假设系统需要20Gbps的有效吞吐如果用单通道10G则两个通道加上协议开销基本够用如果用单通道5G那就需要更多通道否则速率不足。但通道数不是越多越好每一对SerDes通道都对应引脚、功耗和PCB面积。而且多通道之间的串扰和电源噪声会随密度上升BER误码率测试时经常能看出来。很多SerDes IP支持通道绑定或链路聚合可以把多个通道集中起来当一个大带宽通道用。但这会引入通道间对齐问题PCS层必须做偏斜补偿。实际项目里如果单通道速率能覆盖需求尽量别为了省一个通道去搞复杂的绑定那是给自己增加调试成本。4.3 功耗和面积是硬约束SerDes IP的功耗通常和速率、通道数、均衡处理复杂度强相关。功耗估算别只看手册里的静态值一定要结合具体速率档位和均衡模式看最差情况下的数值。散热设计时多通道高速SerDes可能占据整个芯片功耗的四分之一甚至更多这在系统里必须提前算进热预算。面积方面硬IP一般按“每个通道占多大多大”来算。如果是ASIC项目还要注意SerDes放置的位置因为它需要靠近封装引脚、需要特定的电源区和模拟隔离区。很多新手拿到IP文档之后只管逻辑集成到了布局布线阶段才发现PMA的位置放不下或者和数字逻辑冲突了返工成本非常大。所以选型和面积评估一定要尽早做。4.4 参考时钟怎么选SerDes的参考时钟是整个发送和接收时钟Synth的源头对抖动特性极为敏感。一般来说需要选择低抖动、频率准确的参考时钟源。常见做法是给SerDes一个独立的干净时钟源避免和系统里别的时钟混在一起。某个项目里参考时钟来自板上一个质量一般的锁相环输出结果在误码测试时发现抖动偏大最后不得不单独加了一颗高精度晶振误码指标才恢复正常。参考时钟的频率像SerDes的“心跳基准”。具体选什么频率要看IP手册和所跑的协议有的IP可以接受几个不同频点自动做倍频。比如某IP支持从25MHz到156.25MHz多种参考频率选哪种更影响系统时钟树设计。我的经验是能用整数倍频关系尽量别用小数倍频小数PLL一旦没配好杂散往往很难处理。4.5 选软核还是硬核软核和硬核的区别体现在授权方式、使用限制和验证难度上。硬核是经过硅验证的固定布局版本性能和功耗已经确定做集成时近似当黑盒用风险相对低但灵活性有限软核则是更偏RTL的可配置实现灵活度高但模拟部分往往还得依赖某种硬核或者仿真模型实际性能需要自己验证。对于大多数系统公司高速SerDes基本都是选硬核因为模拟部分太难自己保证性能。FPGA里的SerDes就是这种模式外面给出一堆寄存器配置但底层是固定电路。即便是硬核也需要仔细读文档里的上电时序、复位序列和初始化要求这方面踩坑概率反而比较高。5. 常见疑难杂症与排查技巧实录5.1 误码率测试总是压不下去这是最典型的SerDes问题出现场景往往是一整块板子几个通道有一个或者几个通道的BER就是达不到指标。排查思路我一般分三步。第一步检查物理层用示波器测量接收端引脚处的眼图确认幅度、上升时间和眼宽是否在合理范围如果波形很糟优先看PCB走线、过孔和连接器。第二步看均衡配置试着调整CTLE或DFE的档位观察BER是否有明显变化很多情况下是均衡参数没设到位或者设太高放大了噪声。第三步查参考时钟和电源用频谱分析仪看参考时钟附近有没有杂散电源纹波是否过大——一个看起来极小的电源纹波都可能通过CDR调制到数据上。5.2 CDR失锁或频繁重锁CDR失锁的典型表现是接收端完全收不到有效数据或者链路时好时坏。先别急着怀疑IP本身看看上游数据源是否稳定——比如上游发送端的参考时钟抖动过大、数据流中跳变沿过少、数据速率偏差超限都可能导致CDR无法锁定。不少SerDes IP提供CDR锁定检测寄存器调试时可以不断读取锁定状态同时用示波器观察数据边沿抖动。如果抖动来源是电源解决方式往往是增加电源滤波甚至调整电源层叠结构。还有一个容易被忽略的点复位顺序。有些IP要求CDR必须在特定复位时序之后才能开始锁定如果软件复位序列不标准CDR状态机可能永远进不了锁定状态。5.3 协议建不了链时怎么查如果SerDes只是跑自定义回环收发都通但一上行协议就建不了链问题多半在PCS层配置或协议所需的链路训练过程。比如PCIe的LTSSM有严格状态转移要求配置错误或参考时钟偏差到一定程度都会导致卡在某个状态。调试时可以抓取PCS层错误计数器和训练状态寄存器观察它到底卡在哪个环节。以太网类协议更要留意自动协商和对端能力有些时候链路对端的均衡能力和本地不匹配也会造成建链失败。这时候即使是物理层通过协议层也可能反复重启。我的惯用方法是先用手动固定模式把链路速率定死排除自动协商干扰再用内部回环验证PCS逻辑最后再放到真实对端去联调。5.4 通道间偏斜和一致性问题多通道系统中各通道走线长度不可能完全一致PCS层需要对齐通道。出现数据乱序或者通道间错位时重点看IP是否提供了对齐标记机制比如有序集合或特殊字符这些标记就是用来做通道对齐的。调试时如果发现对齐经常失败往往不是逻辑问题而是某个通道物理信号质量太差导致对齐标记不能被识别。多通道的一致性还涉及每通道的均衡参数。即使是同一批次SerDes通道间工艺偏差和布线差异也会导致最佳均衡参数不完全相同。有些IP支持每通道独立配置建议在批量测试后记录各通道的最优参数再做统一固化这样可以显著提升量产后的稳定性和一致性。5.5 信号完整性测试的注意事项测试SerDes信号质量眼图是绕不开的。使用示波器测试时有几点经验探头尽量短避免额外负载造成失真测试点尽量靠近芯片引脚避免走线效应让波形更差示波器带宽至少是数据速率的三倍以上否则高频分量测不出来。条件允许的话使用芯片内部的回环测试功能配合软件工具读取均衡后的眼图信息往往比示波器测量更接近真实接收端视角。还有一个隐藏问题示波器探头和测试夹具本身可能引入反射测到的眼图比实际更差。很多芯片都有内置的PRBS发生器可以从发送端发出标准测试码型再在接收端统计误码这种做法配合外部示波器能把“芯片实际接收能力”和“外部信号质量”分开评估定位问题就快很多。6. 一些实战心得与补充提示6.1 不要把SerDes当成普通IO来用很多项目的坑都是从“先弄通硬件、再去了解SerDes”开始的。SerDes和普通GPIO、并行接口最大的不同在于它从设计之初就需要考虑阻抗、回流、通道损耗和电源完整性。随便拿普通IO去接高速差分信号很容易出现信号质量问题的隐患。硬件设计时差分走线通常需要精确控制阻抗过孔要尽量少且要预留足够的地回流过孔电源去耦也要格外用心。在原理图阶段就把这些问题规划好后面调试会省下大量时间。6.2 文档里哪些内容最值得精读SerDes IP手册动辄几百上千页没必要全读但有几个部分必须精读。一是上电和复位时序搞不清这一步后面跑起来可能一直行为异常二是寄存器映射里和链路测试、环回、误码统计相关的部分三是参考时钟的频率和抖动要求这是很多系统规划容易忽略的硬指标。把这些吃透基本就能应付大多数应用场景。6.3 内部回环测试到底怎么用内部回环是验证链路和排查问题的利器。所谓近端回环就是发送端数据经过一小段内部路径直接回到接收端不经过外部引脚远端回环则是数据到达对端芯片后通过它内部路径再回来。近端回环保证PCS/PMA逻辑功能正常远端回环保证整条链路和对面芯片的收发通道都正常。调试时先跑近端回环再跑远端回环一旦某一步不通过就能很快把问题收敛到具体模块。不过回环测试也有局限它绕过了外部PCB通道不能完全代替真实信号质量的测试。所以该用的场景要用但测完回环之后依然要做底层误码测试和眼图评估不能因为回环全通就认为整条链路都妥了。6.4 量产测试与一致性保障任何SerDes设计都要考虑量产可测性。测试项一般包括每个通道的误码率、参考时钟频率精度、通道间一致性和电源电流值。为了保证量产稳定性设计阶段就要预留测试点和配置接口有些IP支持通过边界扫描或专用测试模式来做快速验证。量产中如果发现某一片的SerDes通道无法锁定或者误码超标优先检查焊接质量、板材加工异常和时钟晶体如果都正常再考虑IP配置参数是否被固化错了。根据我的经验很多量产问题在样机阶段根本暴露不出来原因就在于样机阶段人工调参干预太多。尽早用测试脚本统一跑一批板卡记录每个通道的最佳参数范围再用这个数据反推设计裕量能明显降低量产后返工的风险。SerDes IP这个东西表面看是芯片设计里的一个模块实际上牵扯到协议、信号完整性、电源、时钟、PCB工艺和软件驱动任何一个环节出问题都会让最终系统表现打折。回头再看那些基础概念PCS和PMA的划分、CDR的原理、均衡器的作用其实都是为了一件事让高速比特流在真实物理信道上尽可能可靠地传输。搞懂了这些再看任何SerDes手册或者调试日志心中会有清晰得多的地图。希望这篇浅谈能对刚开始接触SerDes的朋友有点实际帮助。