做高速接口测试时，CDR 参数到底该怎么设？

先说最实用的结论：

• 做一致性测试，先按协议

• 做系统调试，再参考真实芯片

• 规范没写清或前期摸底时，可以先用经验值：CDR 环路带宽 ≈ 数据速率 / 1667

这篇文章不想把问题讲得太学院派，只想把实验室里最常见的判断逻辑讲清楚。

先别急着调参数，先想清楚你在“模拟谁”

很多人把 CDR 参数当成仪器设置项，但它本质上是在定义一件事：

你的测试设备，想模拟的是“协议参考接收机”，还是“真实芯片里的接收机”？

这两个目标不一样，参数自然也不会完全一样：

• 协议视角：关注能不能和标准一致，能不能过规范

• 芯片视角：关注真实链路里，这颗 SerDes 到底能不能锁、能不能抗抖、能不能吃下 SSC

所以，CDR 设置永远不要脱离测试目的单独讨论。

为什么 CDR 参数会直接影响测试结果？

因为 CDR 不会把所有抖动都当成错误。

• 低频抖动，CDR 可能会跟着跑掉

• 高频抖动，CDR 跟不上，就会真正压缩眼图、推高 BER

也正因为这样，CDR 带宽 决定了哪些抖动被“滤掉”，哪些抖动被“留下来”。

图1｜课件里把 JTOL、JTRAN、JGEN 放在一起看很有帮助。做测试时要记住：CDR 不是简单“恢复时钟”，它还直接决定链路对输入抖动的容忍、对抖动的传递，以及自身会不会再生成额外抖动。

所以同一条波形，用不同 CDR 设置做后处理，测出来的眼图、TJ 甚至 BER 都可能不一样。很多“仪器 A 和仪器 B 结果对不上”的根因，不是波形不同，而是 CDR 模型不同。

第一原则：做协议测试时，先按协议设

如果你做的是 PCIe、USB、SATA、DisplayPort、Ethernet 这类标准接口，一致性测试时最重要的一条原则就是：

先按协议规定的参考接收机来设 CDR。

原因很简单。合规测试测的不是“这条波形看起来好不好”，而是：

这个发射机，能不能被协议定义的接收机正确接收。

因此：

• 协议写了环路带宽，就按协议值

• 协议写了阶数、阻尼、peaking 或 SSC 处理方式，也要跟着走

• 仪器默认值、实验室习惯值、工程师个人经验值，都不能替代协议值

一句话总结就是：

一致性测试里，CDR 不是自由参数，而是测试标准的一部分。

第二原则：做真实系统调试时，要参考芯片行为

但到了系统 bring-up、链路优化、板级调试阶段，事情就没那么“标准化”了。因为真实芯片里的 CDR，往往并不等于协议里的参考接收机。

很多实际芯片今天已经不是单纯的理想模拟 CDR，而是各种 digital / hybrid CDR 的组合，带宽、量化、更新步长、SSC tracking 策略都可能不同。

图2｜这类 practical digital CDR / hybrid CDR 结构提醒我们：真实芯片不是课本里的“单一二阶环”。同一个协议下，不同厂家的 SerDes，在带宽、跟踪能力和极限环行为上都可能有差异。

这也是为什么工程上通常会分两步：

1. 先用 协议值 看它是否满足一致性要求  

2. 再用 接近真实芯片 的 CDR 模型，看系统表现是否稳定

也就是说：

• 协议参数 决定你能不能对标规范

• 芯片参数 决定你对真实系统有没有判断力

没有明确规范时，可以先用“黄金带宽”

如果还在前期摸底，或者协议没有把行为 CDR 写得特别细，实验室里很常见的一条经验就是：

也就是大家常说的“黄金带宽”。

几个常见例子：

• 2.5 Gb/s，约 1.5 MHz

• 5 Gb/s，约 3 MHz

• 10 Gb/s，约 6 MHz

• 25 Gb/s，约 15 MHz

• 32 Gb/s，约 19.2 MHz

这个值为什么常被拿来当起点？因为它通常落在一个比较折中的区间：

• 不会窄到连正常低频漂移都跟不住

• 也不会宽到把很多本来应该留下来的抖动都“吃掉”

但一定要补一句：

黄金带宽是调试起点，不是协议替代品。

为什么带宽不能一味往大了调？

很多人第一次调 CDR，会有一个直觉：既然 CDR 是拿来跟踪时钟的，那带宽大一点，跟得更快，不就更好吗？

问题就在这里。跟得更快 不等于 测得更真实。

图3｜课件里这张图很适合拿来理解测试直觉：CDR 带宽和 peaking 决定了不同频率抖动会被放大、保留还是跟踪掉。带宽设太大，结果往往会变“好看”；但“好看”不一定等于真实接收机的判决压力。

工程上可以这么理解：

• 带宽太窄：低频漂移也跟不上，结果偏悲观

• 带宽太宽：很多本该暴露出来的低频抖动被跟踪掉，结果偏乐观

所以真正该问的不是“带宽越大越好吗”，而是：

这个带宽，是否和你要模拟的接收机一致？

SSC 为什么必须一起考虑？

这是实验室里最容易被忽略、但又最容易把结果带偏的点。

SSC 本质上是低频调制。很多协议里，它都落在接收机应该能够跟踪的低频范围内。也正因为这样，SSC 和 CDR 带宽从来不是两件分开的事。

实操里通常有两种错误：

• CDR 太窄：跟不上 SSC，把本来应该被跟踪掉的低频变化，当成了额外抖动

• CDR 太宽：把本不该完全滤掉的变化也一起吞掉，结果偏乐观

如果拿 PCIe 的思路来理解，会更直观一些。很多 PCIe 参考时钟分析里，都会单独把 SSC 和低频 jitter 拿出来看，因为它们本来就处在 CDR/PLL 能部分跟踪的频段，不能简单和高频闭眼抖动混在一起。

所以实际建议是：

• 做协议测试：严格按协议对 SSC 的处理方式来

• 做系统调试：确认仪器是否开启了 SSC tracking、de-spread 或类似选项

• 做结果对比：一定标明 SSC 是开还是关，否则不同设备很难对齐

一个常被忽略的矛盾：JTOL 和 JTRAN 往往不是一起变好的

很多人希望找到一个“一招通吃”的 CDR 设置，最好既有很强的 jitter tolerance，又没有 jitter transfer 问题。

现实里通常没有这么简单。

图4｜这张图最值得带回实验室的一点是：JTOL 和 JTRAN 往往存在耦合。很多单环 CDR 里，你把某一边调得更激进，另一边未必会同步变好。所以测试时不要只盯一个指标。

这也是为什么很多协议测试、芯片调试、系统联调里，最后都不只看“一个眼图”或“一条 BER 曲线”，而是要把：

• JTOL

• JTRAN

• peaking

• SSC tracking

• 实际误码表现

放在一起看。

最推荐的设置顺序

如果你在实验室里需要快速把 CDR 设起来，我更建议按下面这个顺序：

场景一：一致性测试

1. 先查协议里的 reference receiver / behavior CDR  

2. 按协议设置带宽、阶数、阻尼、peaking  

3. 按协议决定是否开启 SSC tracking  

4. 不要为了“结果更好看”去改参数

场景二：系统调试

1. 先用协议值做一遍基线  

2. 再切到更接近真实芯片的 CDR 模型  

3. 如果没有明确资料，先用 数据速率 / 1667 起步  

4. 再围绕这个值上下扫一圈，看结果对带宽是否敏感

几个常见疑问，顺手一起回答

1. CDR 带宽是不是越大越好？
不是。越大只能说明“跟踪得更快”，不代表“更符合协议”或“更符合真实芯片”。

2. 黄金带宽能不能直接拿来做一致性测试？
不能。它适合前期调试和摸底，不能代替协议定义。

3. 为什么不同仪器测出来差很多？
常见原因不是波形本身，而是 CDR 带宽、阶数、peaking、SSC 处理 没对齐。

4. 发射端测试和接收端容限测试，用的是同一套 CDR 吗？
不一定。发射端一致性测试更强调协议定义的参考接收机；接收端容限和系统调试，更关注真实接收机行为。

5. 只看 BER，不看 CDR 设置，行不行？
不行。BER 本身就受 CDR 恢复方式影响，CDR 没对齐，BER 对比很容易失真。

写在最后

如果把整件事压缩成一句话，我会这样总结：

CDR 参数怎么设，先看你要模拟的是“协议接收机”还是“真实芯片接收机”；规范不清时，再用黄金带宽 数据速率 / 1667 作为起点，并把 SSC 一起纳入考虑。

这样设，测试结果通常才既说得通，也更容易和别人对齐。

更进一步学习CDR可以参考上篇文章.

参考论文

资料来源：Howard Johnson 等相关课程材料，Tutorial 06 - Clock and Data Recovery Architectures and Circuits；以及配套 lecture12_ee720_cdrs 课件
资料题目：Clock and Data Recovery Architectures and Circuits