盐析白兔

这个屌丝很懒，什么也没留下！

热门标签

GTX示例工程分析及上板（高速收发器十）_gtx open in example design

作者：盐析白兔 | 2024-07-05 04:34:23

踩

gtx open in example design

点击进入高速收发器系列文章导航界面

前文配置生成了GTX IP，本文讲解xilinx官方提供的示例工程，获取IP使用方式，最后在仿真和上板。

1、分析示例工程各模块功能

首先选中生成的IP，然后鼠标右击Open IP Example Design生成该IP的示例工程。

在这里插入图片描述

图1 生成示例工程

之后选择示例工程存放路径，如下图所示。

在这里插入图片描述

图2 示例工程存放路径

生成的示例工程中，顶层模块gtwizard_0_exdes下包含三个模块，如下图所示。其中2号模块是GT IP相关的处理，3号模块用于生成GT IP的测试数据，4号模块将GT IP接收的数据进行校验。

在这里插入图片描述

图3 示例工程包含模块

顶层模块的RTL视图如下所示，输入包含接收数据差分对、GT参考时钟差分对、DRP时钟差分对，输出包括输出数据差分对和数据校验指示信号。

在这里插入图片描述

图4 顶层模块的RTL视图

由于该模块只使用一个收发器，因此需要使用回环模式，才能进行上板测试。

1.1、数据生成模式

设计思路是从一个深度为512的ROM中循环读出数据，作为GTX IP的发送数据。

下图是该模块的部分截图，相关代码比较简单，就是同步复位信号，生成一个地址计数器，对时钟计数，后续每个时钟从ROM中读取一个数据输出。

在这里插入图片描述

图5 数据生成模块部分代码

剩余代码如下所示，由于ROM存储的数据是80位的，因此这里读出的数据也是80位的，但是最终只使用了16位到47位的32位数据，从后文的RTL视图可以得知。

在这里插入图片描述

图6 剩余代码

注意一个问题，此处使用initial和$readmemh函数去初始化ROM是可以的，可能会有人认为这些是Verilog HDL的不可综合语法，但是这里的initial和$readmemh真的变成可综合的电路了？

有这部分理解的人应该是对“可综合”理解有问题，可综合其实是指综合成电路，比如if-else语句可以综合成数据选择器这种真实存在的电路结构。而initial和$readmemh在此处只是完成了对ROM内部数据的初始化，而这部分内容是在综合软件对工程综合时，就已经变成数字常量了，并不会对应具体的电路结构，因此虽然依旧能够完成初始化功能，但是并不是可综合语法。

从下图可知，数据生成模块输出的80位数据，只有中间的32位数据作为GTX IP的发送数据，ROM存储的4到8位数据作为K码指示信号。

在这里插入图片描述

图7 顶层例化模块

由下图可知，ROM初始化数据是一组循环的16进制数据，每16个地址循环一次。红色框中的32位数据作为GTX IP待发送的数据，蓝色框中的8位数据作为GTX IP待发送数据的K码指示信号。

由此可知32’h060504bc的低8位数据是K码，及K28.5对应的十六进制数据。

在这里插入图片描述

图8 ROM初始化数据

1.2、数据校验模块

例化接收检测模块如下所示，设定的数据位宽与IP设置的用户位宽保持一致，且规定了一帧数据的开头为32’h060504bc，且逗号为16’h04bc。

在这里插入图片描述

图9 例化检测模块

GTX IP输出的数据只是完成了字节对齐，但是没有进行字对齐，接收模块在接收数据后，需要判断一帧数据的起始位置，然后进行字对齐，之后才能与发送的数据进行对比，因此该模块的代码还是有点麻烦。

如下所示，发送端是按照字节然后转换成串行数据发送的，先发送低字节数据，接收端会将接收字节进行对齐，比如发送端发送8’hbc，接收端依旧会输出8’bc。

但是接收端可能在任何时间开始接收数据，只能保证接收的每个字节的数据正确性，并不能保证接收的32位数据与发送端是一致的。比如下图接收端可能在8’h00开始接收的数据，那么GTX IP输出给用户的32位数据为32’h0504bc00，用户拿到这个数据后，需要自己将输出的32位数据对齐。

在这里插入图片描述

图10 接收端接收数据

一般通过检测一帧数据的帧头，来调节输出数据的字对齐。由于示例工程的接收模块也考虑了数据位宽为80，64位等等，位宽越大，字对齐越复杂，导致该模块的代码很繁杂。

关于字对齐具体代码就不做讲解了，代码篇幅比较长，核心内容就是检测帧头，然后最后一个数据时需要做处理，可能有些字节是无效数据。

下图是通过对比发送和字对齐后的接收数据是否相同，从而生成错误指示信号。

在这里插入图片描述

图11 错误指示信号生成

1.3、GTX IP相关模块

主要关心的其实还是与GTX IP相关的模块，主要包含以下几部分。1号模块内部包含一个MMCM，GTX IP输出的TXOUTCLK通过MMCM生成TXUSRCLK、TXUSRCLK2、RXUSRCLK、RXUSRCLK2等时钟信号。还包含一个IBUFGDS_GTE2将GT差分时钟转换为单端时钟，作为2号模块的输入信号。

2号模块内部通过GT_COMMON原语调用QPLL，为GT IP提供参考时钟信号。3号模块是一个异步复位同步模块，生成的复位信号作为QPLL的复位信号之一。4就是生成的GTX IP。

在这里插入图片描述

图12 GTX IP相关模块

该模块的RTL视图如下所示，包括几个模块也很明显。

在这里插入图片描述

图13 RTL视图

内部模块如下所示，IBUFGDS_GTE2将差分时钟转换为单端时钟，之后再作为QPLL的输入，之后驱动GTX IP时钟管脚。

在这里插入图片描述

图14 时钟相关模块

gtwizard_0_common_reset模块很简单，就是将复位信号同步到当前系统时钟域下，就不再赘述。

gtwizard_0_GT_USRCLK_SOURCE模块用于生成接收和发送通道的用户时钟信号，以及将差分时钟转换为单端时钟信号。

如下所示，直接调用IBUFGDS完成差分转单端功能。

在这里插入图片描述

图15 IBUFGDS_GTE2调用

下图是通过MMCM生成发送通道和接收通道的用户时钟信号TXUSRCLK2和RCUSRCLK2，以及PCS并行时钟TXUSRCLK和RXUSRCLK，由于在设置IP时，接收通道和发送通道的原时钟均采用TXOUTCLK，因此此处只使用了一个MMCM。

在这里插入图片描述

图16 MMCM生成用户接口时钟信号

gtwizard_0_common模块内部只是调用了GTXE2_COMMON原语，达到使用QPLL的目的，关于该原语的具体参数，可以参考UG476手册，此处不再赘述。注意SIM_QPLLREFCLK_SEL和QPLLREFCLKSEL_IN的取值，与时钟信号所接的原语接口直接相关，可用于动态控制QPLL时钟输入。

如下图所示，参考时钟接在GTXE2_COMMON的GTREFCLK1_IN端口，那么SIM_QPLLREFCLK_SEL和QPLLREFCLKSEL_IN的值为1。由于ZYNQ7030只有一个GT bank，不存在南北bank的时钟信号，因此该模块并没有将另外四个参考时钟管脚引出。

在这里插入图片描述