Aurora的工程化问题解决方案
前言
针对Aurora在实际工程的例化应用问题上,本人经过以往经验进行可行性方案分享,其中有关Aurora的例化过程及不进行详细介绍,可自行查询其他博客学习,望补充指正,谢谢。
(补充:该文里的aurora默认为全双工模式)
简介
本文主要阐述Aurora协议在多通道例化上的应用问题,以及针对实际硬件的GTH通信质量较差(ibert眼图测试),如何继续利用Aurora的均衡模式补救,已达到正常通信的标准。
案例
场景一
主板卡与多个子板卡的Aurora通信,主板卡内需对Aurora进行多通道例化,其中主板卡与单个子板卡是单通道Aurora通信。
问题描述
设置好单通道Aurora的IP后,生成IP examp design工程,对顶层的端口进行修改后,进行多次例化后综合,place design 报错,如下:
分析解决
根据报错的文件位置找到如下模块:
place design error中指出驱动gt_common必须是相同的时钟或是邻近的时钟。
简单的说多次例化,导致gt_common模块被多次例化,gt_refclk(gt参考时钟)是由IBUFDS_GTE3转换来,这里对应了多个qpll1_refclk端口,这里在实际资源布线中不需要多次定义使用qpll_refclk,因此将gt_commmn模块单独放到顶层,不用和aurora一起例化多次。这里涉及到aurora64b66b用到的gt参考时钟内部采用qpll(详见https://zhuanlan.zhihu.com/p/494758359)锁相, 其中相邻的quad可以共用同一个gt_refclk,这多次例化的aurora channel 分布在相邻的两个quad,可以共用一个gt_refclk时钟资源。
顶层代码修改后如下:
该警告可以不用管,不会影响aurora的通信,若需要可以修改所指文件,将下图约束注释重新综合即可。
场景二
板卡之间的ibert测试(5Gbps下)眼图结果如下:
通过调整advanced settings里的红色红框的参数,主要是调整spread spectrum clocking(扩频时钟),具体需要同硬件工程师交流,因为导致眼图信号差的原因有很多,该方案主要是硬件上没有什么优化空间的情况下采用。
通过设置后眼图正常,如下
问题描述
问题是aurora64b66b里的advanced不支持调整扩频时钟,即便降低线速率也无法稳定通信,因此无法使用aurora64b66b,如何继续使用aurora协议。
分析解决
方法如下:
- aurora64b66b替换为aurora8b10b;
- aurora8b10b的设置里让gt子模块放到IP的外边,可供设置,此处打钩如下;
- 找到aurora8b10b_0_gt的IP,修改里面的advanced设置,其中扩频时钟就可以设置了,只需将ibert眼图测试成功的参数配置进去后更新生成IP即可。
transceiver IP
本人通过实践验证该方法可以在速率降到2.5Gbps下的aurora8b10b解决,但是由于改动了相关的参数,由于原本信道的通信质量较差,两板卡间的aurora链路可能不能自适应建立,channel_up信号不能保持置1,解决方法是需在两板卡上电后分别对aurora模块中的GT_RESET进行长约1ms以上的高电平复位(本人使用1s复位)。