Aurora核使用中tx_dst_rdy信号拉低问题

目录

 

前言

问题分析

解决方案

后记


前言

最近在使用Aurora核进行数据传输时遇到了如下问题:

1、Aurora核输出的tx_dst_rdy信号会不定时的拉低,拉低之后不定时进行恢复。tx_dst_rdy信号拉低后,Aurora将不再接收数据。如图1所示。

图1 tx_dst_rdy不定时拉低

2、环境:本文所述的测试环境为数据经过位宽转换FIFO之后,输出给Aurora核。

问题分析

因为tx_dst_rdy信号会不定时拉低在之前的工程中也遇到过,所以再次遇到这个问题的时候,采用和原来处理方法相同的方式,但是出现了如图2所示的问题。

图2 

由图3可以看出,虽然我对FIFO的读使能进行了相应的控制,但是在tx_dst_rdy拉低之后,仍然将数据读出,导致整个数据帧的发送错误。经过对信号的分析,最终检查到如图3所示的问题:

tx_dst_rdy信号与其产生的时钟clk_rd之间有100ps的时延(此处FIFO的读时钟即为Aurora输出的use_clk,下文统称为clk_rd)。如图3所示。

图3 tx_dst_rdy与时钟信号相差100ps

由于tx_dst_rdy信号和clk_rd信号都是由Aurora核内部产生的,在这块产生了100ps的延迟,应该为其内部时延造成的。因此,我对tx_dst_rdy信号进行进一步的追踪,发现其在Aurora核内部产生中进行了1ns的延迟,如图4所示:

Aurora核使用中tx_dst_rdy信号拉低问题_第1张图片

图4 tx_dst_rdy产生加入了1ns的时延

 那么,为什么在这里要进行1ns的延迟呢?有什么理论支持呢?为了寻找理论支持,我把Aurora协议又看了一遍,最终在时钟补偿这块找到了相应的理论支持。

时钟补偿序列由6组时钟补偿指令/CC/组成,至少每隔10000个字码组发送一次,而不顾当前是否有其他的数据包或者码组在传输。当发送时钟补偿序列时,Aurora核将自动中断数据传输。每发送10000个字节,时钟补偿序列在每个线路(lane)上加12个字节的额外开销。时钟补偿应用于系统收发端使用独立的参考时钟资源的情况,它允许收发端使用的参考时钟频率的不同最大为100PPM。

Aurora核使用中tx_dst_rdy信号拉低问题_第2张图片 图5 Aurora中对时钟补偿的描述

 由此可以得知,tx_dst_rdy信号拉低的原因是:Aurora核内部需要发送时钟补偿序列,所以需要中断链路数据的传输。至于为什么要进行1ns的延迟,我的猜测如下:因为Aurora内部允许收发端的参考时钟频率不同最大为100PPM(PPM为时钟精度单位,是百万分之一),根据Aurora和最低工作频率计算出来的由于时钟频率不同造成的时延不超过1ns,故在tx_dst_rdy信号产生时,对其进行1ns的延迟,从而适应频率不同的情况。

 为什么要延迟1ns的事情搞清楚之后,又遇到了另外一个问题,既然在这里延迟了1ns,为什么在用户接口那块延迟又变成了100ps?再次对该信号进行追踪,最后发现在AXI转LL模块中,输出的时钟延迟由1ns变化为100ps,为什么会出现这个结果,我暂时还没有考虑到,如果有大佬知道这个问题,希望能够告诉我。

解决方案

针对对时延产生的原因分析,最终我采用将Aurora核输出的时钟,人为进行1ns的延迟,然后用延迟之后的时钟再去进行数据的读取,这样就可以解决该问题。

图6 对时钟进行1ns的延迟
图7 测试结果

 

后记

虽然采用将时钟信号延迟1ns,最终解决了这个问题,但是解决方法仍然缺乏理论研究的支持,并不知道这种解决方法是否正确,是否会对数据的正常传输产生影响。这些仍需要后续验证。如果有人对这方面有更深入的研究,希望能够和您进行探讨。我的联系方式:邮箱[email protected],QQ:179212934(备注CSDN,谢谢!)。

你可能感兴趣的:(FPGA,接口)