点击进入高速收发器系列文章导航界面
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工程中进行上板测试。
如果对文章内容理解有疑惑或者对代码不理解，可以在评论区或者后台留言，看到后均会回复！
如果本文对您有帮助，还请多多点赞👍、评论💬和收藏⭐！您的支持是我更新的最大动力！将持续更新工程！
