对于Aurora具有Aurora8B10B和Aurora64B66B两种，对于Aurora8B10B和Aurora64B66B两者之间的主要区别就是：8B/10B编码可以平衡DC，有足够的跳变来恢复时钟，但是有25%的带宽开销。64B/66B编码的前两位表示同步头，减小的开销，但是却不能保证0/1数量的平衡，因此需要进行加扰。
可根据实际项目需求来进行选择即可。我使用的是Aurora64B66B来设计，所以本文主要对该IP进行解读，其中主要参考Xilinx提供的PG074文档来进行说明。
上图显示的是Aurora IP在通道传输的示意图，从途中可以看出，两个Aurora IP核之间存在Channel和Lane，传输通道中包含若干个Lane。通过这个模型实现数据之间的传输和交换。对于该IP核，实际上就是最基础的Serders接口的应用，所以直接对IP核进行配置然后使用Xilinx提供的官方Demo进行仿真即可。
IP核的内部框图如下所示：
Aurora 64B/66B核心的主要功能模块是：
•Lane Logic：通道逻辑模块的一个实例驱动每个GT收发器。该通道逻辑初始化每个单独的收发器，处理控制字符的编码和解码，并执行错误检测。
•Global Logic：核心中的全局逻辑模块执行通道绑定以进行通道初始化。在操作过程中，通道跟踪Aurora 64B/66B协议定义的未就绪空闲字符，并监控所有通道逻辑模块的错误。
•RX User Interface：AXI4流接收（RX）用户界面将数据从通道移动到应用程序，并执行流控制功能。
•TX User Interface：AXI4流传输（TX）用户接口将数据从应用程序移动到信道，并执行流控制TX功能。标准时钟补偿模块嵌入内核内部。该模块控制时钟补偿（CC）字符的周期性传输。
废话不多说，直接上IP的配置。
同理，在设计中，里面的速率以及Lane的数量可根据实际需求来配置，但是DRP Mode建议选择AXI4 Lite，这样方便后期数据的传输以及将该IP合并到其他工程中使用。配置完成直接打开Xilinx官方提供的demo，然后点击仿真开始IP核的仿真。
IP的Demo模型
在设计中，笔者对TX核RX进行了小部分的修改，如下图红圈的位置，红圈内被注释起来的内容为Demo中的原本连线。我进行的修改主要是为了适应上图中两个Aurora相互通信时的TX核RX交叉连接，从而实现两个IP之间的通信。即TX1->RX2，TX2->RX1，（我认为是这样，如果说错了希望大佬进行指正，事实证明我修改的部分是否修改与仿真结果都没有影响。）
直接上仿真图：
从仿真时序图可以看出，玫红色的部分主要为TX核RX的数据，可以看出，发送的数据和接收的数据实际上是一样的，这也符合传输的实际情况。对于IP核来说，其具有自己的校验信号，通过蓝色信号可以看出，其中Channel_up需要Lane_up全部锁定后，才能判断通道正常通信，这也符合传输逻辑。其中Channel_up为1表示验证序列成功，Lane_up为1表示收发器之间的通信链路训练成功。而绿色部分与蓝色部分的Channel_up功能一致，只是为了表示通道正常传输。
当然，还可以通过下面几个信号对仿真结果进行判断：
| 接口名称 | 描述 |
|---|---|
| core error signals | Aurora 64B/66B核心状态和控制接口的错误信号被带到示例设计的顶层并注册，表示核运行时错误信号标志 |
| core lane up | |
| signals | 核心的通道向上状态信号被带到示例设计的顶层并被注册。核心对于他们使用的每个GTX和GTH收发器都有一个通道上行信号。 |
| core channel up signals | 核心的通道上行状态信号被带到示例设计的顶层并被注册，表示核运行时通道内信号是否UP上 |
| data_err_count[0:7] | frame_CHECK接收到的与预期值不匹配的帧数据字数的计数 |