GTY 100G Aurora IP的一些问题

Vivado：2016.4FPGA：xcvu190Hello，我在两个xcvu190平台之间遇到Aurora 64B66B IP（v11.1）的一些问题。
使用x4 GTY通道将IP配置为全双工，成帧和100G。
下面描述的所有链接都是稳定的，并且这些问题与AXIS用户界面有关。
此外，当设计满足时序和使用AXIS ILA时，会观察到所有问题。
添加ILA往往会导致时序违规，因为Aurora AXIS接口的时钟频率为400MHz。首先我注意到AXIS“tlast”信号和数据包中的最后一个数据字没有传播到接收伙伴，这是
通过启用CRC错误检测意外解决。
我用过10G和40G应用程序的Aurora IP已经过去了（XC7VX690T，KU060），我从来没有观察到这种行为。
我正在使用一些自定义逻辑进行数据包成帧，但我也在利用Xilinx的AXIS IP进行宽度转换，时钟交叉和数据包模式FIFO。
在任何情况下，当启用CRC时，按预期接收AXIS数据包（tlast和最后一个dword）。
这是一个已知的问题？
我已经使用Vivado 2016.3和2016.4确认了这种行为。我的第二个问题有点复杂，可能与第一个问题有关。
我的测试应用程序涉及使用100G Aurora链接从两个平台（A0和A1）向平台B发送AXIS数据包（4x256位，3.4Gb / s）。
平台B使用AXIS互连聚合数据包，并将数据包广播回平台A0和A1。
当在任一A平台上观察收到的数据包时，我偶尔会注意到一个数据包中的数据字被删除并插入到相邻的数据包中。
有时“简化”数据包仅包含带有“tlast”的最后一个数据字，有时它只缺少1个数据字（tlast始终存在）。
我没有观察丢失的数据，因此链接层框架或Aurora IP的其他内部功能似乎存在问题。
两个Aurora IP都使用相同的参考时钟（322.265625 MHz），我正在设计相对于Aurora用户时钟的时钟交叉。
此外，我在整个平台B的设计中探测了AXIS总线，并且所有数据包在进入Aurora AXIS TX端口时似乎都被正确格式化。
平台B的数据路径类似于以下内容：
Aurora [0] RX  - > INTC  - > Aurora [0] TX
INTC  - > AXIS Broadcast  - > Aurora [1] RX  - > INTC  - > Aurora [1] TX
任何帮助将不胜感激！谢谢！



以下为原文

Vivado : 2016.4
FPGA  : xcvu190

Hello,

I'm experiencing a few problems with the Aurora 64B66B IP (v11.1) between two xcvu190 platforms. The IP is configured for full-duplex, framing and 100G using x4 GTY lanes. All links described below are stable, and the issues are related to the AXIS user interface. In addition, all issues are observed when the design meets timing and when AXIS ILA are used. Adding ILA(s) tend to cause timing violations, since the Aurora AXIS interface is clocked at 400MHz.

At first I noticed that the AXIS "tlast" signal and the last data word in the packet was not propagated to the receiving partner, which was unexpectedly resolved by enabling CRC error detection. I've used the Aurora IP for 10G and 40G applications is the past (XC7VX690T, KU060), and I've never observed this behavior. I am using some custom logic for packet framing, but I'm also leveraging Xilinx's AXIS IP for width conversion, clock crossing and packet-mode FIFOs. In any case, when CRC is enabled AXIS packets (tlast and last dword) are received as expected. Is this a known issue? I've confirmed this behavior using Vivado 2016.3 and 2016.4.

My second problem is a bit more complicated and might be related to the first. My test application involves sending AXIS packets (4x256-bit, 3.4Gb/s) from two platforms (A0 & A1) to Platform B using 100G Aurora links. Platform B aggregates the packets using an AXIS interconnect and broadcasts the packets back to Platforms A0 and A1. When observing the received packets on either of the A platforms, I occasionally noticed that data word(s) from one packet are removed and inserted into a neighboring packet. Sometimes the "reduced" packet only contains the last data word with "tlast," and sometimes it's only missing 1 data word (tlast is always present). I'm not observing data lost, so there seems to be a problem with link-layer framing or some other internal function of the Aurora IP. Both Aurora IPs use the same reference clock (322.265625 MHz), and I'm properly handling clock crossing in the design relative to Aurora's user clock. In addition, I've probed the AXIS bus throughout Platform B's design, and all packets seem to be formatted properly as it enters the Aurora AXIS TX port. Platform B's data path resembles the following:

Aurora[0] RX ->                                                INTC -> Aurora[0] TX
                           INTC -> AXIS Broadcast ->   
Aurora[1] RX ->                                                INTC -> Aurora[1] TX

Any help would be appreciated
Thanks!