High Speed Digital IO是如何设计,如何实现的?

2020-08-21 aiqun 288

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

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

这还得从摩尔定律说起,当芯片规模不断变大时,芯片封装上的pin并没有多出来,所以不可能把所有的IO都单独拉到封装上,而熟悉封装的朋友们都知道,封装pin增加得越多,封装成本越高,为了符合市场的性价比,我们也必须达成如此的要求,而少pin数对于SI(PI)其实也是有好处的,设想几十个并行IO同时翻转时,就会带来很大的SSO(simultaneous switching ouput),电源上的稳定性就会很差,整板也会有较大的EMI,当几十个单端parallel IO变成了一对串行信号时,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按照Rx pin上收到的信号的最快频率恢复出来,然后再跟Rx与一下,就成了内部的Rx数据!


现在数据和时钟都有了,是我们所谓的那些协议发挥作用的时候了。在协议里我们定义了一些databit的组合作为flag,在接收端接收到这些flag时,来判断接下来这些数据是data,还是control,还是idle!
这里多说一句,为什么idle也要区分出来?发送时候发一串0不就完了吗?事实上不是这样。为了能够正常的回复出clk来,要尽量保证输出的data没有长串的0和1。这就涉及到我们最常见的8b/10b encoding, 64b/66b scrambling等等,也是协议里会定义的东西,