SerDes 系统架构:发送端、接收端、通道、时钟域

要真正搞懂 CDR 测试,你得先清楚 SerDes 系统是怎么搭起来的。说白了,它就是一个高速数据的搬运系统。发端把并行数据打成串行包扔出去,收端再把它拆回并行。但就这么个“打包-运输-拆包”的过程,里面藏着无数坑。

我个人习惯把 SerDes 系统分成四个大块:发送端(TX)、接收端(RX)、通道(Channel)、时钟域(Clock Domain)。别看就四个词,每一个都有门道。

核心要点:SerDes 的本质是“并行转串行+串行转并行”,外加时钟数据恢复。TX 负责发,RX 负责收,通道是中间那根线,时钟域管着什么时候发、什么时候收。

发送端(TX):串行化和预加重

发送端的任务很明确:把并行数据变成高速串行流,然后推到通道上。这里面最核心的就是串行器(Serializer)和驱动器(Driver)。

  • 串行器(Serializer):也叫 PISO(并行输入串行输出)。它负责把 N 位宽的数据按位排好队,一个时钟周期送出一位。速率越高,PISO 的设计就越难。
  • 预加重(Pre-emphasis):这是我踩过坑的地方。通道在高频下损耗大,信号的上升沿会变缓。预加重的做法是:在信号跳变时故意多打一点能量出去。比如从 0 变 1,先推一个更高的电压,再回落。
  • 驱动器(Driver):它决定了信号的摆幅和阻抗。常见的差分摆幅在 400mV~1.2V 之间。电流模式逻辑(CML)是主流,因为功耗相对低、速度高。
避坑指南:我之前有个项目,发送端预加重系数设太大,结果信号在通道远端出现了过冲,导致接收端误码率飙升。后来我学乖了:预加重不是越大越好,要和通道的损耗曲线匹配。

接收端(RX):均衡、CDR、解串

接收端是“重灾区”。信号经过通道后已经面目全非,你得把它修回来。接收端主要干三件事:

  1. 均衡(Equalization):有人把它比作“信号整形”。CTLE(连续时间线性均衡器)先上场,它是个高通滤波器,专门补偿高频衰减。DFE(判决反馈均衡器)跟在后面,它用数字方式消除码间串扰。
  2. CDR(时钟数据恢复):这里没有独立的时钟线,收端必须从数据边沿中“剥离”出时钟。我习惯把 CDR 的环路带宽设成数据率的 1/1000 左右。太宽了抖动变大,太窄了跟不上频率漂移。
  3. 解串器(Deserializer):把串行数据重新拼回并行。注意!它必须和 CDR 恢复出的时钟对齐,否则会出现采样错误。
注意:解串器对位对齐极其敏感。我曾经遇到一个 bug,解串器每次复位后串行数据对齐差了 1 个 UI,导致连续 2 个字节都错位。查了整整一天才发现是并串转换的同步没做好。

通道(Channel):损耗与反射

通道就是那根物理走线。在高速 SerDes 世界里,走线不是理想的。它是有损传输线,有电阻、电容、电感。

通道特性对信号的影响典型指标
插入损耗幅度减小@Nyquist 频率 ≤ -15dB
回波损耗反射引起过冲/振铃≥ -15dB
串扰增加噪声≤ -30dB
介质损耗边沿变缓取决于 PCB 材料,如 M6G 的 Df ≈ 0.002

我见过最夸张的一个案例:某款 25Gbps SerDes,通道实际走线超过 40 英寸,中间还过两个连接器。收端的眼图完全闭合。最后不得不在 RX 端开了 3 阶 DFE,才勉强拉回误码率。

提示:通道的 S 参数模型是仿真和测试的基础。我个人习惯在测试前先拿到通道的 S4P 文件,看看 Sdd21(插入损耗)在奈奎斯特频率下的值。如果低于 -20dB,你最好提前规划好均衡方案。

时钟域(Clock Domain):PLL 与时钟分配

时钟是 SerDes 的心跳。发送端需要高频时钟来串行化数据,接收端需要干净的时钟来采样。我经常被问到:为什么 SerDes 内部会有多个时钟域?

  • 参考时钟域:外部晶振给的,通常是低频的,比如 100MHz 或 125MHz。
  • 高速时钟域:由 PLL(锁相环)锁定倍频产生。比如 25Gbps 的 SerDes,高速时钟就是 25GHz 或 12.5GHz(取决于双沿还是单沿)。
  • 恢复时钟域:接收端 CDR 从数据里提回来的时钟。注意!它和发送端时钟是异步的,存在频率偏差。

为什么要强调这个?因为时钟抖动直接决定了 CDR 的跟踪误差。PLL 的带内相位噪声越小,时钟越干净,接收端采样眼图的水平开度就越大。

重点警告:在 SerDes 测试中,参考时钟的质量往往是整个系统的天花板。我曾经遇到一个项目,测试板上的参考时钟电源纹波超标,导致 PLL 输出抖动暴增,CDR 多次失锁。后来在电源端加了一颗 100nF 电容,问题解决。很简单的改动,但不去查想不到。
SerDes系统架构图 发送端 TX 串行化 + 预加重 通道 损耗 / 反射 / 串扰 接收端 RX CTLE+DFE + CDR 时钟域 PLL 数据流向 并行数据 → TX 串行化 → 通道传输 → RX 恢复 → 并行数据输出

这张图你仔细看:数据从左往右走——从发送端出发,经过通道,到接收端解码。时钟域在最下方,像一个“隐形的手”,同时控制着 TX 和 RX 的工作节拍。注意 RX 内部的 CDR 时钟是恢复出来的,它不完全依赖于参考时钟。这里就有个关键点:异步时钟域处理。如果不处理好两个时钟域的跨域同步,数据就会丢。

一个常见误区:有人觉得参考时钟频率就是数据率。实际上,大部分 SerDes 内部会通过 PLL 将参考时钟倍频。比如 100MHz 参考时钟,可以倍频出 12.5GHz 的高速时钟来驱动 25Gbps 的串行数据。这里面的倍频比和压控振荡器(VCO)的频率范围是测试时一定要确认的。

系统架构视角下的 CDR 测试

你想想看,CDR 测试的本质是什么?是验证接收端能不能从“严重畸变的数据”里准确恢复出时钟和数据。这离不开对系统架构的整体理解。

  • 测试 TX:重点关注串行数据流的抖动和眼图。预加重有没有过头?摆幅是否达标?
  • 测试通道:S 参数测量,看插损和回损是否在 SerDes 均衡能力的范围内。
  • 测试 RX:这是 CDR 的核心。注入已知抖动和损耗的信号,看接收端能否正确恢复。
  • 测试时钟域:检查 PLL 的锁定时间、输出相位噪声,以及参考时钟的频率偏差容限。

我记得有个项目,实验室里各种测试都过了,一到系统联调就出问题。查到最后,发现是发送端和接收端的参考时钟来自不同晶振,频率差了 200ppm。CDR 的跟踪范围只有 ±300ppm,刚好能锁住,但误码率高了 10 倍。从那以后,我每次测试都会专门加一项:频率偏移容限测试。具体做法就是故意让时钟偏一点,看 CDR 会不会失锁。

个人习惯:系统架构测试我通常会列一个清单:TX 眼图是否满足模板、通道插损是否在预算内、CDR 抖动容限是否达标、PLL 锁定时间是否 < 10ms。哪个不满足,项目就亮黄牌。