轻松实现高速串行I/O

主要有三个原因:
1. 宇宙射线可以引起错误,特别是信号转变的时候。信号的速度越快,转变越多,则转变
时越可能受到宇宙射线的干扰。
2. 对于任何给定的 BER,信号的速度越快,发生错误的可能性就越大。
3.高速时钟数据恢复不够精确。抖动、ISI、以及其他的实际干扰都可能造成不好的数据判
决,从而引起错误。例如,PLL 不断尝试调整持续变化的输入信号。同时,由于振荡器
会随着温度漂移,所以也可能会引起错误。
测试的真实性
上述几个原因的影响确实存在,仔细分析并行背板、源端同步链路或者任何通信通道,就会
发现类似的问题。但是大部分情况下,还是假定 BER 很接近于零并且忽略不计。
为什么在千兆位 SERDES 中不能有同样的结论呢?因为它们的原始背景是使用各种光
学设备的通信产业。这个产业通常很关注 BER,通过测试、设计并最后具体指定 BER。这
一点极大地影响了千兆位 SERDES 链路的 BER。
部分标准,例如 XAUI 和部分版本的 SONET,会给出其可以接受的最大 BER。不幸的
是,BER 的测试十分困难、令人厌烦而且需要花费很多时间。同时改善单位 BER 的难度会
呈指数增长。BER 通常以 10-x 的符号出现,所以要把 BER 从 10-8 改善到 10-9 需要 10-x
的时间。而且从某些角度来看,测试是不切实际的。因此,多数的厂商测试只会持续到标准
中给出的最严重的 BER,而不会继续下去。
CRC
设计师还是需要设计一个稳健的系统。首先,他需要检查系统的要求,看是否能够使用常用
的方法来解决问题。
一种方法是错误检测数据重传。检查输入数据中是否有错。如果发现错误,则发送信息
给发送者要求重传数据。错误检测的首选方法是 CRC。因为 CRC 十分常用,所以许多
SERDES 内部都有 CRC 发生器和检测逻辑。通常重传请求是由上层协议定义的。如果协议
支持 CRC 和重传,或者数据要求正是其所能满足的,那么这种方法将会是最好的选择。
如果情况不是这样的话,设计师还可以有其他的选择。设计师可以建造并测试所设计的
系统,以观察其能否正常工作。SERDES 发布的 BER 可以用来确定测试需要进行到什么程
度,所以设计师还是有一些机动空间的。设计师不可能设计出一个远优于发布数据的系统。
除了持续测试直到达到发布的 BER,设计师还需要在各种极限情况下进行测试(例如,输
入抖动十分靠近容限)。如果给系统设计提供更好的输入流,那么结果会更好。
数据还提供了另一种值得考虑的选择。多数的数据流都是有模式的,和用于 BER 测试
的伪随机比特流相比,数据流更容易预测。这一点可能是好处也可能是坏处,这取决于传输
通道和均衡器适配数据流的情况。所以必须进行测试和调整。
所以建造一个系统并观察其能否正常工作,这种方法并不是十分牵强的。尽管如此,如
果这种方法会出现操作上的问题,那么前向纠错(FEC)可能会有所帮助。
技术
XILINX·53