Xilinx Aurora8b10b IP数据丢失之谜，什么问题作祟？

limanjihe

已于 2025-03-28 23:04:53 修改

阅读量826

点赞数 28

CC 4.0 BY-SA版权

分类专栏： FPGA 文章标签： aurora

于 2025-03-28 23:02:38 首次发布

本文链接：https://blog.csdn.net/limanjihe/article/details/146623538

FPGA 专栏收录该内容

23 篇文章

订阅专栏

用Xilinx Aurora8b10b IP时遇到如下图这样的问题：

用frame模式，2 lanes@1Gbps速率的条件下，发送最后一个数据时，会拉低一个时钟，然后last拉高，但是keep少了一位1，数据发生了一个字节的丢失；
用frame模式，1 lanes@1Gbps速率的条件下，完整正常；
请问会是什么样的问题导致的?

工作原理

首先，从Aurora 8b10b IP核的工作原理说，能选择frame or stream两种模式（对应framing or streaming interface），本次重点考虑frame模式下数据的传输机制。Aurora协议使用多通道（lanes）来传输数据，每个通道的数据宽度可能不同，但通常是基于字节的，配合keep和last信号来指示有效数据字节和帧的结束。

在frame模式下，User接口的数据总线宽度可以根据lane的数量而变化。例如，1个lane的情况下，数据宽度可以配置是2字节（16位，Xilinx也允许配置为4字节），在2个lane的情况下，数据宽度可能扩展为4字节（32位，Xilinx也允许配置为2字节）。每个字节对应一个keep信号位，用来指示该字节是否有效。last信号则标记帧的结束。

本次的问题出现在2 lanes的情况下，当发送最后一个数据时，last被正确拉高，但keep信号少了一个位，导致数据丢失一个字节。而在1 lane的情况下则正常。这说明问题可能与多lane情况下的数据对齐、keep信号生成逻辑以及约束等有关。先从IP的端口看：

端口

Framing interface：本次使用的是Frame mode

理想情况下的波形应该如下：

Aurora 8B/10B帧结构

TX子模块通过TX接口将每个接收到的用户帧转换为Aurora 8B/10B帧。帧的开始 (SOF) 通过在帧的开头添加2字节的SCP代码组来表示。帧的结尾 (EOF) 通过在帧结束处添加2字节的信道结束协议 (ECP) 代码组来表示。每当数据不可用时，都会插入空闲代码组。代码组是8B/10B编码的字节对，所有数据都作为代码组发送，因此，具有奇数字节的用户帧在帧的末尾附加了一个称为PAD的控制字符，以填写最终的代码组。表2-3显示了一个典型的Aurora 8B/10B帧，其数据字节数为偶数。

双lanes情况下，字节发送示意图：

名词解释：

PDU: Protocol Data Unit

SCP: Start of Channel PDU，2 Bytes Size

ECP: End of Channel PDU，2 Bytes Size

SOF: Start of Frame

EOF: End of Frame

PAD: pad byte

TX发送数据

由于需要每lane每10,000个字节需要进行时钟补偿 (2字节每lane的设计，对应5,000个时钟; 4字节每lane的设计，对应2,500个时钟)。也就是说，不能连续传输数据，也不能连续接收数据。在时钟补偿期间，数据传输将暂停六个或三个时钟周期。

RX接收数据

可能原因

有了上述的基本概念后，继续分析可能的原因。

1）数据长度对齐问题

在2 lanes的情况下，数据总线的宽度更大（例如32位），发送的数据帧的字节数可能没有正确对齐，导致最后一个周期的keep信号生成错误。

例如，检查在2 lanes的情况下，发送的数据帧的字节数是否为4的整数倍。如果不是，那么最后一个周期的keep信号需要根据剩余字节数正确设置。例如，如果总共有5字节，在32位（4字节）总线下，第二个周期传输1字节，keep应为0x0001（即最低位有效）。如果错误地设置为0x0003（即两位有效），则可能多发送了一个无效的字节，或者设置为0x0000，则丢失数据。

2）keep信号生成逻辑错误

在生成keep信号时，没有根据实际的剩余字节数正确设置对应的位，尤其是在多lane的情况下，计算错误导致少了一个有效位。

查看发送逻辑的代码，特别是生成keep和last的部分。例如，在VHDL或Verilog中，当检测到剩余字节数小于总线宽度时，如何设置keep的每一位。例如，在2 lanes的情况下，假设数据总线是32位（4字节），当剩余字节数为3时，keep应为4'b1110（高位在前）或者4'b0111（低位在前），具体取决于字节顺序。如果此处逻辑错误，可能导致少了一位。使用Xilinx IP方案一般不会存在这个问题。

3）时序或同步问题

在生成last和keep信号时，可能存在时序上的问题，导致信号不同步，但这种情况可能更复杂。

4）IP核配置错误

例如，在2 lanes的情况下，数据总线宽度配置不正确，导致逻辑生成的keep信号与IP核期望的宽度不匹配。

检查Aurora IP核的配置，确保lane数量和对应的数据总线宽度正确。例如，对于2 lanes，每个lane的线速率为1Gbps，那么每个lane的数据速率是1Gbps，而8b10b编码的实际数据速率是1Gbps * 8/10 = 800Mbps per lane。因此，总数据速率是每个lane的800Mbps乘以2，即1.6Gbps。对应的接口时钟是100 MHz（每个时钟周期传输16位，即2字节，对于1 lane）或者更高的频率。但具体的数据宽度需要根据IP核配置来确定。

5）数据打包的问题

例如，当数据帧的字节数在2 lanes的情况下不是4的整数倍时，最后一个传输周期会有部分字节有效，这时候需要正确设置keep信号的低位。例如，假设数据长度是5字节，那么在2 lanes（32位，4字节/周期）的情况下，需要两个周期：第一个周期传输4字节（keep=0xF），第二个周期传输1字节（keep=0x1），同时拉高last。如果在这种情况下错误地将keep设置为0x0（即仅高位有效），或者在处理时少计算了一个字节，则可能导致问题。使用Xilinx IP方案一般不会存在这个问题。

6）数据有效字节的计算存在错误

例如，在1 lane的情况下，可能正确计算了剩余的字节数，并设置对应的keep信号，但在2 lanes的情况下，计算错误，导致最后一个周期的keep少了一位。

检查是否在发送最后一个数据时，正确地在同一时钟周期拉高last信号，并且保持数据有效。例如，在最后一个周期，数据必须有效，last拉高，同时keep正确指示有效字节。如果提前一个周期拉高last，或者在数据无效时拉高last，可能导致问题。

7）物理约束存在错误

例如，在1 lane的情况下，rx/tx不存在顺序问题；但在2 lanes的情况下，rx/tx存在顺序问题，如果不能正确实现约束，会导致接收端编码混乱。

解决方案

1. 确保在发送数据时，数据长度在2 lanes的情况下正确对齐，或者在无法对齐时正确计算最后一个周期的有效字节数，并设置对应的keep信号。

2. 检查生成keep信号的逻辑，确保在最后一个周期根据剩余字节数正确设置每一位。例如，如果剩余3字节，则keep的4位中应有3个高位或低位设置为1，具体取决于字节顺序。

3. 验证Aurora IP核的配置，确保lane数量和数据总线宽度匹配，例如2 lanes对应的数据宽度是否是32位。

4. 检查时序，确保last和keep信号与数据同步，并且没有因时序问题导致信号被错误地采样。

5.检查约束，确保物理约束正确。

验证步骤

仿真测试：
在Vivado中仿真2 lanes模式下的发送逻辑，检查最后一帧的keep和last信号是否符合预期。重点关注剩余字节数为非4倍数的情况。
协议分析仪抓包：
使用ILA（Integrated Logic Analyzer）抓取发送端接口信号，确认实际生成的keep和last信号是否与设计一致。
代码审查：
检查发送逻辑中keep信号的生成逻辑，确认其动态计算是否覆盖所有可能的剩余字节情况（1/2/3字节）。

问题解决