点击进入高速收发器系列文章导航界面
1、配置GTX IP 相关参数
前文讲解了64B66B编码解码原理,以及GTX IP实现64B66B编解码的相关信号组成,本文生成64B66B编码的GTX IP。
首先如下图所示,需要对GTX共享逻辑进行设置,为了便于扩展,与8B10B编码一致,将共享逻辑放在IP外部的示例工程中。
之后将发送通道和接收通道的线速率均设置为10Gbps,参考时钟频率选择156.25MHz(开发板提供给高速收发器的参考时钟频率)。由于线速率大于5.5Gbps,因此接收通道和发送通道的时钟只能来自QPLL输出。其余设置与8B10B编码保持一致。
设置“Encoding and Clocking”界面时,根据前文可知,GTX的发送通道可以由用户逻辑提供变速器的计数器,也可以使用IP内部自带的计数器,因为GTH等高速收发器内部变速器没有自带计数器,为了与其余高速收发器设计保持一致,1处发送通道选择使用外部计数器的64B66B编码方式。
此处可以计算出PCS内部并行数据传输时钟userclk和用户接口时钟userclk2的频率,首先userclk等于线速率除以内部数据位宽,线速率为10Gbps,内部数据位宽(Internal Data Width)32位,计算得到userclk为312.5MHz。而用户接口数据位宽为64位,为了保持带宽恒定,用户接口时钟频率应该是内部时钟频率的一半,即userclk2等于156.25MHz。
数据位宽选择64位,降低用户时钟频率,有利于时序稳定。接收通道不需要用户提供计数器,直接选择64位数据位宽的64B66B编码即可。
在接收通道和发送通道依旧使能内部Buffer对数据同步,将发送通道和接收通道的时钟来源均设置为TXOUTCLK,而TXOUTCLK来源于TXPLLREFCLK,如下图所示。
即使经过前面8B10B的讲解,有部分读者还是会疑惑,为什么发送通道和接收通道内部就必须使用buffer同步数据,以发送通道为例,此处在此说明。
首先要清楚buffer两侧的时钟域分别是什么,各自时钟域的来源是什么,是否真的存在相位差,然后就知道为什么必须要同步了。
如下图所示,发送通道的buffer两侧的时钟分别是TXUSRCLK(PCS内部传输数据时钟)和XCLK(PMA的并行时钟),TXUSRCLK和TXUSRCLK2都是TXOUTCLK通过同一个锁相环生成的,因此不存在相位差,他们之间也不需要同步。
在此之后,需要知道TXOUTCLK与XCLK的来源。下图是发送通道内部的时钟结构,前文也进行过详细分析。
根据图3的设置可知TXOUCLK来源于TXPLLREFCLK,而高速收发器的PLL应该就是CPLL或者QPLL,因此下图中TXOUCLK的来源应该是3(CPLREFCLK)或者4(QPLLREFCLK)。
再看XCLK来源,5处选择QPLL或者CPLL的输出时钟(与其参考时钟相位相同)作为PMA的输入时钟,然后经过内部的相位调节模块(Phase Interp)调节时钟与PMA数据的相位关系,再经过分频得到并串转换的时钟信号。因此PMA的并行时钟信号就是TXOUTCLKPCS,即XCLK。
TXOUTCLKPCS的相位经过Phase Interp调节后,很可能与QPLL或者CPLL的参考时钟相位已经不同了,那么XCLK与TXUSRCLK的相位也就不同,因此需要同步,个人的理解就是这么多了。
至于上图中的分频系数如何设置,含义是什么,前文已经详细讲解过,本文不再赘述。接收通道的原理类似,只不过是将Phase Interp换成了CDR而已。
回归正文,如下图所示,配置“Comma Alignment and Equalization”界面,由于64B66B没有K码相关内容,因此不能设置K码对齐,需要用户去控制同步头实现手动对齐,后续代码设计时进行讲解。
由于10Gbps线速率比较高,接收通道选择DFE均衡模式,将发送端的加重和极性控制等选项勾选。
之后设置“PCIe,SATA,PRBS”界面,如下图所示,只需要勾选回环控制即可,其余保持不变。
下图是设置通道绑定和时钟纠正的界面,其中通道绑定只能在设计中存在多个高速收发器时使用。启用时钟纠正功能,每发送5000字节数据会发送一个时钟序列,用于时钟纠正。
最后来到IP设置的汇总界面,如下图所示,其中USRCLK位312.5MHz,USRCLK2为156.25MHz,与前文计算结果一致。
2、模块分析
打开IP的示例工程,主要关注下图几个重要模块,多数与8B10B编码的模块类似。首先时QPLL、复位、用户时钟生成的相关模块。与8B10B编码不同的是多了一个手动同步的模块。
同步模块通过判断接收的同步头是否正确,来拉高Slip信号调节开始转换的位置,来达到接收数据同步的目的,RTL视图如下所示。
官方示例工程的手动同步模块写的比较繁琐,经过前面讲解可知,在正常传输数据时,64B66B编码会有控制码和数据码两种,同步头分别是2’b01和2’b10。
因此接收端在上电后,可以根据接收到的同步头的状态判断接收的数据是否同步了,如果接收到的同步头不是2’b01或者2’b10,则把Slip信号拉高一个时钟,等待一段时间后继续检测,直到连续检测32个时钟接收的数据均正常时,把同步成功信号拉高。
数据同步与ISERDES的原理类似,后文的自定义64B66B协议时,会自己设计同步模块,比较简单,本文就不讲述官方该模块的设计了,有兴趣的可以看看。
运行示例工程的仿真,QPLL仿真结果如下所示。
发送通道的用户接口时序如下图所示,帧头和帧尾的控制帧数据对应的同步头为2’b10,而纯数据帧的同步头为2’b01。当外部想GTX中连续输入32个数据(计数器txsequence计数到31)时,txdata_in需要暂停输入数据,清空内部变速器中的数据。
当接收通道复位完成后,接收端需要对接收数据进行同步,如下图所示,多次拉高rxgeraboxslip,直到接收到的同步头正常为止。
如下图所示,接收到的同步头数据txheader_out并不全为2’b01或者2’b10,说明接收的数据并没有同步成功,因此将rxgeraboxslip拉高一个时钟,过一段时间后继续检测txheader_out状态,直到持续32个时钟接收到txheader_out的状态均正常时,认为同步完成。
仿真采用回环设计,如下图所示,发送数据经过IP收发后,接收端仍然能够接收到数据,证明该IP的使用没有问题。
注意该IP并不具备64B66B编码和解码的能力,64B66B编码和解码是通过示例工程的两个模块完成的,对应的RTL视图如下图所示。
后续用户在设计自己的工程时,可以直接使用这两个模块,对发送数据加扰,接收数据解扰。
由于本文只使用了一个高速收发器,因此不对示例工程上板,后续在自定义的64B66B工程中进行上板测试。
如果对文章内容理解有疑惑或者对代码不理解,可以在评论区或者后台留言,看到后均会回复!
如果本文对您有帮助,还请多多点赞👍、评论💬和收藏⭐!您的支持是我更新的最大动力!将持续更新工程!