目录
前言
最近在使用Aurora核进行数据传输时遇到了如下问题：
1、Aurora核输出的tx_dst_rdy信号会不定时的拉低，拉低之后不定时进行恢复。tx_dst_rdy信号拉低后，Aurora将不再接收数据。如图1所示。
2、环境：本文所述的测试环境为数据经过位宽转换FIFO之后，输出给Aurora核。
问题分析
因为tx_dst_rdy信号会不定时拉低在之前的工程中也遇到过，所以再次遇到这个问题的时候，采用和原来处理方法相同的方式，但是出现了如图2所示的问题。
由图3可以看出，虽然我对FIFO的读使能进行了相应的控制，但是在tx_dst_rdy拉低之后，仍然将数据读出，导致整个数据帧的发送错误。经过对信号的分析，最终检查到如图3所示的问题：
tx_dst_rdy信号与其产生的时钟clk_rd之间有100ps的时延（此处FIFO的读时钟即为Aurora输出的use_clk，下文统称为clk_rd）。如图3所示。
由于tx_dst_rdy信号和clk_rd信号都是由Aurora核内部产生的，在这块产生了100ps的延迟，应该为其内部时延造成的。因此，我对tx_dst_rdy信号进行进一步的追踪，发现其在Aurora核内部产生中进行了1ns的延迟，如图4所示：
那么，为什么在这里要进行1ns的延迟呢？有什么理论支持呢？为了寻找理论支持，我把Aurora协议又看了一遍，最终在时钟补偿这块找到了相应的理论支持。
时钟补偿序列由6组时钟补偿指令/CC/组成，至少每隔10000个字码组发送一次，而不顾当前是否有其他的数据包或者码组在传输。当发送时钟补偿序列时，Aurora核将自动中断数据传输。每发送10000个字节，时钟补偿序列在每个线路（lane）上加12个字节的额外开销。时钟补偿应用于系统收发端使用独立的参考时钟资源的情况，它允许收发端使用的参考时钟频率的不同最大为100PPM。
由此可以得知，tx_dst_rdy信号拉低的原因是：Aurora核内部需要发送时钟补偿序列，所以需要中断链路数据的传输。至于为什么要进行1ns的延迟，我的猜测如下：因为Aurora内部允许收发端的参考时钟频率不同最大为100PPM（PPM为时钟精度单位，是百万分之一），根据Aurora和最低工作频率计算出来的由于时钟频率不同造成的时延不超过1ns，故在tx_dst_rdy信号产生时，对其进行1ns的延迟，从而适应频率不同的情况。
为什么要延迟1ns的事情搞清楚之后，又遇到了另外一个问题，既然在这里延迟了1ns，为什么在用户接口那块延迟又变成了100ps？再次对该信号进行追踪，最后发现在AXI转LL模块中，输出的时钟延迟由1ns变化为100ps，为什么会出现这个结果，我暂时还没有考虑到，如果有大佬知道这个问题，希望能够告诉我。
解决方案
针对对时延产生的原因分析，最终我采用将Aurora核输出的时钟，人为进行1ns的延迟，然后用延迟之后的时钟再去进行数据的读取，这样就可以解决该问题。
后记
虽然采用将时钟信号延迟1ns，最终解决了这个问题，但是解决方法仍然缺乏理论研究的支持，并不知道这种解决方法是否正确，是否会对数据的正常传输产生影响。这些仍需要后续验证。如果有人对这方面有更深入的研究，希望能够和您进行探讨。我的联系方式：邮箱[email protected]，QQ：179212934（备注CSDN，谢谢！）。