横幅广告banner-高速先生手机版
都说高速信号过孔尽量少,高速先生却说有时候多点反而好?

都说高速信号过孔尽量少,高速先生却说有时候多点反而好?

发布时间:2023-02-13 13:59

作者:一博科技高速先生成员  黄刚

过孔在高速领域可谓让硬件工程师,PCB设计工程师甚至仿真工程师都闻风丧胆,首先是因为它的阻抗没法像传输线一样,通过一些阻抗计算软件来得到,一般来说只能通过3D仿真来确定,另外更难的是除了阻抗外,高频的损耗也根据过孔结构的不同差异非常巨大,过孔上的很多结构参数的不同都极其影响过孔的性能,综合上面的因素,大家都不想看到一条高速链路上出现太多的过孔。从下图其实可以看到,一个过孔能优化的地方其实是不少的哈!

要是大家去看一些行业内知名公司的设计指导,在高速串行设计上大多都会有这么一条规则,那就是严格控制高速串行信号收发链路中的过孔数量,一般给出高速链路在收发芯片之间只能有2个过孔,也就是中间就换一次层。

 

然而对于见多识广的PCB设计工程师,他们可能还经历过以下这种很难拍板的情况。

例如芯片到芯片互连的高速信号,我们知道,在不背钻的情况下,应该越靠近下层走线,性能会越好(芯片都在TOP层的情况),但是如果BGA的圈数比较多,可能用完了靠下的层,只能用靠上的层去走线了,那性能怎么办?要是超高速的25G以上的信号,可能直接背钻就背钻了,额外花点特殊工艺的费用就算了,但是如果速率只是不上不下的10G到12.5G左右呢?如果同时又是一些对成本比较敏感的消费类产品呢?那怎么办?背钻还是不背钻?

 

感觉速率没有非常高,说服不了客户,甚至说服不了自己一定要背钻,怀了一丝侥幸心理,不背钻也行。的确是不能往靠下的层去走了,过孔stub的长度也的确达到了一个技术上甚至工程师自己心理上的一个临界点。说到底,就还是成本和性能之间很难去做一个选择!

 

没办法,这个问题估计只有SI出身的高速先生能够给你答案了。当然,高速先生通过仿真可以告诉你如果不背钻和背钻这两种情况下的SI性能。但是高速先生还准备了另外一个更为折中的选择方案,就是不背钻的情况下也能改善性能的做法!当然这并不是我们高速先生发明的设计哈,是行业内一家龙头公司的专利。可以看到,这是一个非常巧妙的方法,本来一个换层过孔会导致很长的stub(下图的80mil),通过在表层再转一次过孔,就变成了20mil的短stub,当然代价就是多了一个过孔。但是达到的目的是走线层不需要发生变化,更重要的是不再需要因为长stub而需要背钻的工艺了。

 

当然,本系列的话题是通过仿真来分享SI的理论,上面的理论说的差不多了,那我们继续利用我们的3D软件去建一个U-turn的case,来仿真对比下这个方法的性能。

我们分别建立三个用作对比的3D模型,分别如下:

1,原始的没有U-turn设计也没有背钻的case,过孔stub为80mil。

 

2,原始的没有U-turn设计,但是进行背钻的case:

 

3,U-turn的设计case:

 

在保证整体走线长度相同的情况下,我们通过3D精确仿真来看看三种case下的无源损耗结果,从频域的损耗曲线来看,首先就能找到性能非常差的一根曲线,也就是原始设计不背钻的曲线,它在14GHz左右的时候有非常巨大的谐振点,在这个频点上,基本上和开路就没什么区别了。

 

然后我们重点来看背钻和U-turn的效果,从我们把频段缩小到10GHz的范围去看,发现U-turn的损耗的确会比直接背钻的case要差一点,但是仅仅是差一点点,对比不背钻的还是好了非常多!

 

恩,那这好一丢丢到底是好多少呢?不背钻的差很多又到底差了多少呢?很多朋友都对频域的损耗曲线看得不是很懂,那我们就换成时域的眼图角度给大家再对比下咯!

我们分别对三个case的链路发送一个12.5Gbps速率的随机码,然后经过链路后我们去看接收端的眼图,从眼图的指标上去看看它们在时域上的差距!

 

好,唰的一声,我们就把三个case的眼图结果仿真出来了,从眼图的结果对比来看,不背钻的情况的确眼图的结果差,不仅是眼高差了一截,还有眼宽也差。而对比背钻和U-turn的结果,发现两者仅仅是眼高上有微小的差异,眼宽指标几乎相同。

 

通过上述我们对U-turn方法的介绍和仿真结果对比,U-turn的确是在5到10G这个频段解决stub偏长的一个很好的方法。因为在这个频段的信号处于对过孔stub开始变得敏感的阶段,但是又没到一定需要背钻的更高频段的信号,这个时候如果遇到一些对成本控制比较严格的产品,U-turn无疑是个很好的选择,但是它也并不是信手拈来般那么好做,首先空间上需要额外的一段走线和一个过孔的空间,更重要的是这个多加的过孔也是需要一定的优化的哦,并不是说随便打个过孔就ok,因此使用U-turn时也必须要有一定的设计功底,甚至仿真能力才可以,大家如果真遇到了上述的情况的话,也可以考虑下这个方法哈!