串行接口的设计与实现

　　因5G、IoT时代的通讯具备高速率、低时延、高带宽等特点，要实现5G和IoT的连接，需要建立大量基站，这也将带来很多电源、信号、光纤等连接器及线缆的应用，因此很多高速数字接口也渐入我们眼前，目前最常见的算是PCIE，SAS和SATA之类的，当然还有10GEthernet上的XAUI协议及Thunderbolt，这个由英特尔和苹果公司共同开发，作为将DisplayPort端口组合在一起的通用高速接口等，今天我们要分享的是HighSpeedDigitalIO本身是如何设计，如何实现的！具体的PCIE，SAS之类的名次解释大家可以问度娘即可：PCIe、SAS和SATA，谁将引领存储接口

　　HighSpeedDigital通常都是串行接口，也可以说正是因为它是串行的，速度才会变得那么高，因为它把芯片内部并行总线上的数据变成串行的发送出去，比如以上提到的QSFP40G它也是通过10G＊4x达成，但是为什么一定要这样做呢？高速数字信号在PCB上的SI问题是非常复杂的，很难设计，为什么不能直接把芯片内部的并行数据直接发出来呢？我们一起来了解下！

　　这还得从摩尔定律说起，当芯片规模不断变大时，芯片封装上的pin并没有多出来，所以不可能把所有的IO都单独拉到封装上，而熟悉封装的朋友们都知道，封装pin增加得越多，封装成本越高，为了符合市场的性价比，我们也必须达成如此的要求，而少pin数对于SI（PI）其实也是有好处的，设想几十个并行IO同时翻转时，就会带来很大的SSO（simultaneousswitchingouput），电源上的稳定性就会很差，整板也会有较大的EMI，当几十个单端parallelIO变成了一对串行信号时，SSO的问题就被极大地减小了，而通常高速串行接口是差分输入、输出的，差分信号本身因为电流相反，对于drive端的IC而言，电源上的电流是稳定的！所以现在就理解啦高速接口其实主要是为了降低成本而存在的，但同时，高速接口必须解决的一个问题就是板级的同步问题，当IO的速度很慢时，板子走线带来的delay几乎可以忽略，但是当IO速度很快时，板子走线带来的delay则会差出几个周期。

　　图示了同样一段走线长度，高速IO已经翻转了几个周期了，低速IO才经历了一个上升沿

　　所以这时候我们不能再用以前那种系统级同步的方式了，因为整板用同一个clk同步，但是这个clk到各个IC的距离不同，是铁定无法同步的了，除非平稳且完全对称，走线完全等长，那我想这种板子应该完全卖不出去！

　　另一种同步方式，是驱动IC把clk和data同时向recieve端发送，再配个等长，就可以保证时钟和data是对齐的，比如说我们常见的ddr，就是这种方式，但这种方式比较麻烦的是，要传输Gbps以上的速度仍然会有非常严格的等长要求，等于又限制了布线的灵活性，这就要求ddr3和ddr4的芯片里面加入training的过程，以实现读写平衡，给我们走线留出更多的裕量。另外，当接收端收到driver端发来的clk后，还得把这个clk跟自己芯片主时钟对应上。假设一个32bit的ddr数据，每8个bit带一个clk，这样接收端就会收到4个不一样的clk，再分别搬移到芯片本身的时钟域内，这样芯片里就有5个不同的时钟域了。芯片设计上也是比较麻烦的。

　　不，这些方案都不够好，真正好的方案应该是简洁且有效的。既然同时发送clk和data也不那么灵活，那能不能只发data，然后在接收端从data里面摘出clk的信息呢？这样既不需要数据跟clk做同步，也不需要对clk进行时钟域的搬移！

　　答案是可以的，高速数字io的每一个部分，都是服务于这个目的：有效地解析出data和clk，再搬到内部的差分总线上，这些模块所增加的芯片面积，跟封装多了几十个pin的成本比起来根本不算个事，是不是觉得发明高速串行接口的人太变态了，能用钱解决的事，非要靠智慧，让我们这些普通人跟进起来多吃力！

　　简单而言，高速数字接口的结构可以简化成下面这张图：

　　发送端，首先得有一个并行转串行的结构，这可以用串联的D触发器实现，把并行总线上来的数据，以并行clk为enable信号一位一位地移动到串联的D触发器里面去。然后再把内部并行clk的相位移动一下（比如移动90度），创造出0度，90度，180度，270度四个时钟，再与起来，时钟就变成了原来的4倍，用这个时钟，把数据存在发送之前的D触发器里！接收端也是类似的方式，不过是反过来串转并。数据中的时钟恢复，是通过pll来完成的，其实这里不光恢复时钟，控制信号也需要从数据中分离出来！

　　PLL按照Rxpin上收到的信号的最快频率恢复出来，然后再跟Rx与一下，就成了内部的Rx数据！

　　现在数据和时钟都有了，是我们所谓的那些协议发挥作用的时候了。在协议里我们定义了一些databit的组合作为flag，在接收端接收到这些flag时，来判断接下来这些数据是data，还是control，还是idle！

　　这里多说一句，为什么idle也要区分出来？发送时候发一串0不就完了吗？事实上不是这样。为了能够正常的回复出clk来，要尽量保证输出的data没有长串的0和1。这就涉及到我们最常见的8b/10bencoding，64b/66bscrambling等等，也是协议里会定义的东西，要协会的协议这类的资料可以去对应协会网站下载